XMLとUnicodeの仕様：正当な文字は何ですか？

Question

私のマネージャーはXMLStreamWriterに文字列を渡す前にjdomのcheckCharacterDataと呼んだ理由を説明してくれたので、XML仕様を参照して混乱しました。

XML 1.0とXML 1.1有効なXML文字が愚かに聞こえること「タブ、キャリッジリターン、ラインフィード、およびUnicodeとISO/IEC 10646の法的な文字」であると言う：タブ、改行、および改行がありますUnicodeの有効な文字はです。次に、U + 0000、U + D800-U + DFFFを除いたU + 0000 - U + 10FFFFを参照するようにXML 1.1で変更された、「サロゲートブロック、FFFE、およびFFFFを除くすべてのUnicode文字」があります。 U + FFFE - U + FFFF; NULは除外されています。次に、BNFによってすでに除外されている文字を含む互換文字の使用が著者に「推奨されない」という注意があります。

質問：正規のUnicode文字は何ですか？ NULは有効なUnicode文字ですか？ （私はU + 0000を除外していないようなISO 10646（第2版、2010）のpdfを発見しました）ISO 10646またはUnicodeは2000年版と2010年版の間で、以前は除外された制御文字を含むように変更されましたか？そしてXMLに関しては、BNFが厳格である一方、テキストが非常に寛大で/ゆるやかな理由がありますか？

Answer 1

質問：正規のUnicode文字は何ですか？

The Unicode Glossaryは、このようにそれを定義：

文字を。 （1）意味値を持つ文章言語の最小構成要素。特定の形状（グリフも参照）ではなく、抽象的な意味および/または形状を指すが、コードテーブルでは、何らかの形の視覚表現が読者の理解にとって不可欠である。 （2）抽象的な文字の同義語。 （3）Unicode文字エンコーディングのためのエンコーディングの基本単位。 （4）中国語起源の表意文字で書かれた要素の英語名。 [表意文字（2）を参照してください。] NULが有効なUnicode文字

---

ですか？ （私はU + 0000を除外するようには見えません）ISO 10646（第2版、2010年のPDFファイルを発見した。）

NULはコードポイントであり、それはそれので「抽象文字」の定義に該当します上記のセンス2のキャラクターです。

---

以前に除外された制御文字が含まれるように2000年版と2010年版の間でISO 10646またはUnicode変更しましたか？

NULは初期バージョンの制御文字です。 Appendix Dには変更の一覧が含まれています。

表D.2には、バージョン1からバージョン3までの65文字の制御文字が変更されていないことが記載されています。

表D-2は、Unicode規格の異なるバージョンに割り当てられた文字の数を文書化。

  V1.0 V1.1 V2.0 V2.1 V3.0 
... 
Controls 65 65 65 65 65 

---

そしてXML用として、BNFは厳しいながらテキストがずさん/とても寛大であるという理由はありますか？

完全で簡潔な記述は難しいです。テキストがBNFと一致しない場合は、BNFを信頼してください。

Answer 2

「文字」という単語の使用は、Unicode標準では意図的にあいまいですが、ほとんどは技術的な意味で使用されています。割り当てられた文字コードポイントとして指定されたコードポイント。これは文字の直感的な概念と完全に一致しません。たとえば、文字iとマクロンアクセントで構成される直感的な文字は、コードポイントとして存在しません。 Unicodeでは、2つまたは3つのコードポイントのシーケンスとしてしか表現できません。別の例として、いわゆる制御文字は直感的な意味での文字ではない。

他の規格および仕様が「Unicode文字」を参照する場合、それらは、割り当てられた文字コードポイントとして指定されたコードポイントを参照します。 Unicode文字セットは、新しいコードポイントが割り当てられるため、Unicode標準バージョンによって異なります。技術的には、UnicodeData.txtファイル（ftp://ftp.unicode.org/Public/UNIDATA/）は、コードポイントが文字であることを示します。

従来はNULと表示されていたU + 0000は、最初からUnicode文字が使用されていました。

XML仕様は、あなたが観察したように、文字に関して多くの点で不正確です。しかし、本質的な定義は "Char"のBNF制作であり、 "XMLプロセッサはCharに指定された範囲内の任意の文字を受け入れなければなりません"というステートメントです。これは、XML仕様では文字の概念がUnicode文字よりも広いことを意味します。プロダクションの範囲には割り当てられていないコードポイントが含まれていますが、実際には膨大な数になります。

XML仕様での "Char"生成に対するコメントは、無視することをお勧めします。それは非常に混乱し、間違っています。 "Char"の生成は、Unicodeコードポイントのセット（異なるバージョンのXMLでは異なるセット）を単に参照します。このセットには、文字データで決して使用すべきではないコードポイントと、さまざまな理由で避けるべきコードポイントが含まれています。しかし、そのようなルールは、XMLの正式な規則やXML実装の要件とは異なるレベルにあります。

文字データをチェックするためのルーチンを選択または書き込むときは、アプリケーションと目的に応じて何を受け入れるべきか、そしてテストに失敗したコードポイントで何をすべきかによって異なります。サロゲートコードポイントでさえ、単に破棄される代わりに何らかの方法で処理される可能性があります。エンコーディングとの混乱のために表示される可能性があります（たとえば、Java文字列がUnicode文字の文字列として扱われていない場合 - それはちょうど16ビットコード単位のシーケンスです）。

Answer 3

私はverbageを無視して、定義に焦点を当てる：

XML 1.0：

シャア:: =＃X9 | #xA | #xD | [＃x20-＃xD7FF] | [＃xE000-＃xFFFD] | [＃x10000-＃x10FFFF]

文書作成者は、[Unicode]のセクション2.3で定義されているように、「互換文字」を避けることを推奨します。次の範囲で定義されている文字も使用しないでください。彼らは、制御文字または恒久的に未定義のUnicode文字のいずれかです：

[＃x7F-＃X84]、[＃x86ベース＃x9F]、[＃xFDD0-＃xFDEF]、 [＃x1FFFE-＃x1FFFF]、[＃ [＃x5FFFE-＃x5FFFF]、[＃x6FFFE-＃x6FFFF]、 [＃x7FFFE-＃x7FFFF]、[＃x7FFFE-＃x7FFFF]、[＃x3FFFE-＃x3FFFF] x8FFFE-＃xBFFFF]、[＃xCFFFE-＃xCFFFF]、 [＃xDFFFE-＃xDFFFF]、[＃xDFFFE-＃xDFFFF]、[＃xDFFFE-＃xDFFFF] xEFFFE-＃xEFFFF]、[＃xFFFFE-＃xFFFFF]、 [＃x10FFFE-＃x10FFFF]。

XML 1.1：

シャア:: = [＃X1-＃xD7FF] | [＃xE000-＃xFFFD] | [＃x10000-＃x10FFFF]

RestrictedChar :: = [＃x1-＃x8] | [＃xB-＃xC] | [＃xE-＃x1F] | [＃x7F-＃x84] | [＃x86-＃x9F]

文書の作成者は、Unicode [Unicode]で定義されているように、「互換文字」を避けることを推奨します。次の範囲で定義されている文字も使用しないでください。

[＃x1-＃x8]、[＃xB-＃xC]、[＃xE-＃x1F]、[＃x7F-＃x84]、[＃x86]のいずれかの制御文字または未定義のUnicode文字です。 ＃x1FFFE-＃x1FFFF]、[＃x3FFFE-＃x3FFFF]、 [＃x4FFFE-＃x4FFFF]、[＃x5FFFE]、[＃x9FFE0-＃xFDDF] - ＃x5FFFF]、[＃x6FFFE-＃x6FFFF]、 [＃x7FFFE-＃x7FFFF]、[＃x8FFFE-＃x8FFFF]、[＃x9FFFE-＃x9FFFF]、 [＃xAFFFE-＃xAFFFF]、[#xBFFFE ＃xFFFF-＃xFFFF]、[＃xFFFFE-＃xFFFFF]、[＃xFFFFE-＃xFFFFF]、 [＃x10FFFE-＃x10FFFF]のように、

Answer 4

愚かなので馬鹿に聞こえる。 XMLの第1版（1998年）は、「Unicodeの法的なグラフィック文字」を読みました。何らかの理由で、2000年第2版から「グラフィック」という言葉が削除された可能性があります。これはおそらく、XMLはグラフィック文字ではない多くの文字を許可しているからです。

Charプロダクションの定義は、実際に見るには適切な場所です。