我的经理让我解释为什么在将我的字符串传递给XMLStreamWriter之前我调用了jdom的checkCharacterData，所以我提到了XML规范然后感到困惑。
XML 1.0和XML 1.1表示有效的XML字符是“制表符，回车符，换行符以及Unicode和ISO / IEC 10646的合法字符。”这听起来很愚蠢：tab，carriage返回和换行符是 Unicode的合法字符。然后是注释“任何Unicode字符，不包括代理块，FFFE和FFFF”，它在XML 1.1中被修改为引用U + 0000 - U + 10FFFF，不包括U + 0000，U + D800 - U + DFFF，以及U + FFFE - U + FFFF;请注意，NUL被排除在外。然后是Note，表示作者“不鼓励”使用兼容性字符，包括已经被BNF排除的一些字符。
问题：什么是合法的Unicode字符？ NUL是一个有效的Unicode字符吗？ （我发现了ISO 10646（2010年第2版）的pdf，似乎并不排除U + 0000.）ISO 10646或Unicode在2000版和2010版之间是否有变化，以包含之前被排除的控制字符？至于XML，有没有理由说文字是如此宽松/草率而BNF是严格的？
答案 0 :(得分：3)
问题：什么是合法的Unicode字符？
The Unicode Glossary因此定义：
字符。 （1）具有语义价值的书面语言的最小组成部分;指的是抽象的意义和/或形状，而不是特定的形状（参见字形），但在代码表中，某种形式的视觉表现对于读者的理解是必不可少的。 （2）抽象字符的同义词。 （3）Unicode字符编码的基本编码单位。 （4）中国出身的表意文字要素的英文名称。 [见表意文字（2）。]
NUL是否是有效的Unicode字符？ （我发现了ISO 10646（2010年第2版）的pdf，似乎并不排除U + 0000。）
NUL是一个代码点，它属于“抽象字符”的定义，所以它是上面第2个意义上的字符。
ISO 10646或Unicode是否在2000版和2010版之间发生变化，以包含之前被排除的控制字符？
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。
答案 1 :(得分：1)
在Unicode标准中，“字符”一词的使用是故意模糊的，但主要是在技术意义上使用：指定为指定字符代码点的代码点。这与直观的角色概念并不完全一致。例如，由带有macron和重音符的字母i组成的直观字符不作为代码点存在;在Unicode中，它只能表示为两个或三个代码点的序列。另一个例子，所谓的控制字符在直觉上不是字符。
当其他标准和规范引用“Unicode字符”时，它们指的是指定为指定字符代码点的代码点。 Unicode字符集因Unicode标准版本而异，因为已分配新的代码点。从技术上讲，UnicodeData.txt文件（ftp://ftp.unicode.org/Public/UNIDATA/）表示哪些代码点是字符。
U + 0000，通常由NUL表示，从一开始就是Unicode字符。
正如您所观察到的那样，关于字符的XML规范在许多方面都是不精确的。但基本定义是“Char”的BNF生成和声明“XML处理器必须接受为Char指定的范围内的任何字符。”这意味着在XML规范中，字符的概念比Unicode字符更广泛。生产中的范围包含未分配的代码点，实际上是大量的代码点。
最好忽略对XML规范中“Char”生成的评论。这非常令人困惑，甚至不正确。 “Char”生产只是指一组Unicode代码点（不同版本的XML中的不同集合）。该集包括您不应该在字符数据中使用的代码点，以及由于各种原因应该避免的代码点。但是这些规则与XML的形式规则和XML实现的要求不同。
在选择或编写用于检查字符数据的例程时，它取决于应用程序和目的应该接受什么以及对于未通过测试的代码点应该做什么。甚至代理代码点也可能以某种方式处理而不是被丢弃;它们可能因编码混淆而出现（或者例如，当Java字符串被天真地视为一串Unicode字符时 - 它就像一串16位代码单元一样）。
答案 2 :(得分：1)
我会忽略这个问题而只关注定义：
XML 1.0：
Char :: =＃x9 | #xA | #xD | [＃x20-＃xD7FF] | [＃xE000-＃xFFFD] | [＃x10000-＃x10FFFF]
鼓励文档作者避免使用[Unicode]第2.3节中定义的“兼容性字符”。还不鼓励在以下范围中定义的字符。它们是控制字符或永久未定义的Unicode字符：
[＃x7F-＃x84]，[＃x86-＃x9F]，[＃xFDD0-＃xFDEF]， [#x1FFFE-＃x1FFFF]，[＃x2FFFE-＃x2FFFF]，[＃x3FFFE-＃x3FFFF]， [#xFFFF-＃x4FFFF]，[＃x5FFFE-＃x5FFFF]，[＃x6FFFE-＃x6FFFF]， [#xFFFF-＃x7FFFF]，[＃x8FFFE-＃x8FFFF]，[＃x9FFFE-＃x9FFFF]， [#xAFFFE-＃xAFFFF]，[＃xBFFFE-＃xBFFFF]，[＃xCFFFE-＃xCFFFF]， [#xDFFFE-＃xDFFFF]，[＃xEFFFE-＃xFFFFFF]，[＃xFFFFE-＃xFFFFF]， [＃x10FFFE-＃x10FFFF]。
XML 1.1：
Char :: = [＃x1-＃xD7FF] | [＃xE000-＃xFFFD] | [＃x10000-＃x10FFFF]
RestrictedChar :: = [＃x1-＃x8] | [＃xB-＃xC] | [＃xE-＃x1F] | [＃x7F-＃x84] | [＃x86的＃x9F]
鼓励文档作者避免使用Unicode [Unicode]中定义的“兼容性字符”。还不鼓励在以下范围中定义的字符。它们是控制字符或永久未定义的Unicode字符：
[＃x1-＃x8]，[＃xB-＃xC]，[＃xE-＃x1F]，[＃x7F-＃x84]，[＃x86-＃x9F]，[＃xFDD0-＃xFDDF] ， [#x1FFFE-＃x1FFFF]，[＃x2FFFE-＃x2FFFF]，[＃x3FFFE-＃x3FFFF]， [#xFFFF-＃x4FFFF]，[＃x5FFFE-＃x5FFFF]，[＃x6FFFE-＃x6FFFF]， [#xFFFF-＃x7FFFF]，[＃x8FFFE-＃x8FFFF]，[＃x9FFFE-＃x9FFFF]， [#xAFFFE-＃xAFFFF]，[＃xBFFFE-＃xBFFFF]，[＃xCFFFE-＃xCFFFF]， [#xDFFFE-＃xDFFFF]，[＃xEFFFE-＃xFFFFFF]，[＃xFFFFE-＃xFFFFF]， [＃x10FFFE-＃x10FFFF]。
答案 3 :(得分：0)
这听起来很愚蠢，因为它很愚蠢。第一版XML（1998）读取＆＃34; Unicode的合法图形字符。＆＃34;无论出于何种原因，单词＆＃34; graphic＆＃34;从2000年第二版中删除，可能是因为它不准确：XML允许许多不是图形字符的字符。
Char制作中的定义确实是正确的选择。