XML 1.0で「制御」文字が不正なのはなぜですか？
XML 1.0で法的にエンコードできないさまざまな文字があります。 U+0007（ 'ベル'）およびU+001B （'逃れる'）。興味深いもののほとんどは、非空白の「制御」文字です。
（例） この質問 などから明らかである 問題となっているXML仕様 -誰でもについて説明できるなぜXML仕様はこれらの文字を禁止していますか？
エスケープでエンコードする必要があったようです。なので およびそれぞれ、しかし、キャラクターがエスケープされる必要があるというよりむしろ禁止されたという実際的な理由があるのでしょうか？
回答者は、伝送制御文字を避けるための動機付けがあると示唆していますが、ユニコードには多くのother制御のような文字が含まれています（U+200C「ゼロ幅の非ジョイナー」）。私はこの振る舞いに正当な理由がないかもしれないことを認識していますが、それをより良く理解したいと思っています。
特にイライラするのは、これらの文字の値が他の エンコーディング データ形式では、これをエンコードする必要がある新しいXMLドキュメントを「ダブルエスケープ」することになります。
私の理解では、この範囲は、マークアップ言語が伝送およびフロー制御文字をサポートする必要がなく、それらを含めるとバイナリ変換のエディターおよびパーサーに問題が発生するという理由で禁止されているということです。
しかし、これについてはティム・ブレイらからカテドラル以外のものを見つけるのに苦労しています。
編集： somediscussion 制御文字と漠然とした承認のそれは正確に過剰に設計されていませんでした：
00/06/00 AM 09/06/27 -0500に、Mark Volkmannが書いた：
ほとんどのASCII制御文字（フォームフィードなど）がXMLドキュメントで許可されない理由についての議論を見たことはありません。その決定の背後にある理由を教えてもらえますか。それを説明する仕様に？
もう一度やるのと同じ方法でやるかはわかりません。彼らが実際に害を及ぼすとは思わない。明らかに、高度に相互運用可能なコンテンツマークアップ言語（およびXML）向けに最適化する場合、vertical-tabやbackspaceのようなものを疑うことは正当ですなど...しかし、その後、\ nやDELなどを残すことはどのように一貫性がありますか？ -ティム
それはかなり前のことでしたが、私の一番の思い出は、グラフィカルな表現も同意されたセマンティクスもないということでした。ランダムにカップルを選ぶと、U + 0006 "Acknowledge"またはU + 0016 "Synchronous idle"が表示されます。それらはどういう意味ですか？ Unicodeは言っていません。誰もがASCIIをサポートすると主張したときでさえ、このジャンクの周りに相互運用性はありませんでした。 XMLは相互運用性に関するものであると想定されています。
これらのことを使用したい人はバイナリデータをXML要素にジャムしたいという経験があります（そして次に望むのはU + 0000 NULLを含めることです）。 1.数字の0x6または0x16を表現したい場合、「キャラクター」の概念を曖昧にしない良い方法がたくさんあります。
XML 1.1の観点からも、おそらく要約する時です。
Unicodeにはどの制御文字コードポイントがありますか？
U+0000からU+001fまで、ASCIIから継承。U+007F、ASCIIから継承U+0080からU+009F、Latin-1から継承- unicode用に明示的に標準化されたさまざまな特別な目的の範囲。特にマークアップのないコンテキストで特に役立ちます。それらは ここで説明 ブロックごとに、それらを使用する理由と方法、またはXMLでそれらを使用しない理由、とにかくそれらに遭遇した場合の対処方法を含みます。
XMLはこれらの制御文字をどのように見ますか？
これは別の分類です。
- タブと改行（改行とはプラットフォームの依存関係に関係なく）は適切です。誰もがそれらを使用します。誰もが彼らが何を表すべきかを知っています。ほとんどすべての既知の形式で許可され、多くの場合、マークアップ自体のきれいな印刷でも許可されます。
U+0000は悪です。ヌル文字？文字列ターミネーター？バイナリノイズ？相互運用性とマークアップの両方に対するアンチテーゼ。すべての形式で禁止されています。- 他に何か？ほとんど使用されていない、問題のある相互運用性ですが、「制御」するものについて多くを知らなくても、それらを許容する方法があります。
ここで、最後のカテゴリのみに注意を向けましょう。制御コードは適切です。つまり、次の概要はタブと改行には適用されません：U+0009、U+000a、U+000D、U+0085、U+2028。
XML 1.0では、U+0000からU+001fを除く上記のすべての範囲の制御文字を、テキスト（直接含まれる文字）、および 数値参照 として使用できます。 U+007FをU+009Fに許可することは 明らかに 省略であり、この不整合はXML 1.1で修正されましたが、逆の場合もありました。彼らは標準の内部で詳細な理論的根拠さえ与えました：
最後に、XML文書で任意のUnicode文字の標準表現を定義することはかなりの需要があります。したがって、XML 1.1では、制御文字＃x1から＃x1Fへの文字参照を使用できますが、そのほとんどはXML 1.0では禁止されています。ただし、堅牢性の理由から、これらの文字をドキュメントで直接使用することはできません。文字エンコード検出の堅牢性を向上させるために、XML 1.0ドキュメントで自由に許可されていた追加の制御文字＃x7F〜＃x9Fも、文字参照としてのみ表示されるようになりました。 （もちろん、空白文字は除外されます。）下位互換性の軽微な犠牲は重要ではないと見なされます。 APIに潜在的な問題があるため、＃x0は直接および文字参照として禁止されています。
UnicodeとXMLが、いくつかの「継承された」範囲を除いて、マークアップのような制御文字を自由に使用できるのはなぜですか？人々はそれらのためにマークアップを使用する必要があります。
Unicodeは、マークアップ以外のコンテキストでも使用され、現在も進化を続けている文字セットです。非制御文字のセットが移動するターゲットである場合、適合XMLプロセッサを実装するのは非常に困難です。
OK、ユニコード固有の制御文字と比較して、継承された範囲の何が問題になっていますか？
標準化の欠如。 Unicodeコンソーシアムは、実際にそれらの「キャラクター」に割り当てる番号を選択することも、典型的な視覚的表現や意味を選択することもできませんでした。 ASCII（エンコードされたUTF-8レベル））およびLatin-1（コードポイント割り当てレベル）との完全な下位互換性により、さまざまな特殊な意味やオーバーロードされた意味に関係なく、これらのコードポイントがそのまま含まれることがしばしばありましたさまざまなテキスト処理コンテキストでそれらに添付されます。
待ってください、XMLはUTF-8とは異なり、ASCIIと完全に後方互換性があることを意図していないのですか？
うん。そのとおりです。ドキュメント要素が必要です。生の<や&を入れることもできません。では、なぜ生の制御文字を入れる必要があるのでしょうか？
XMLは、Unicode（具体的にはUTF-8およびUTF-16）およびISO/IEC 10646を中心に特別に設計されており、どちらも（quite ISO 10646について肯定的ではありません）伝送/フロー制御文字を含んでいますASCIIと文字ベースの端末の時代から残ったものです。これらの文字はまだ使用されていますが、XMLのような形式には属していません。
これらのコードを他の何かに使用するこれらの新しいエンコーディングについては、XML仕様を適応させる必要があるようです。
なぜそれらを二重エスケープするのですか？これは＆bell;に適した場所のようです。および＆escape;。 （未定義、パーサーからコードへのコールバックによって処理されます）