XML和Unicode规范：什么是合法字符？

Question

XML和Unicode规范：什么是合法字符？

3

我的经理要求我解释为什么在将字符串传递给XMLStreamWriter之前调用jdom的checkCharacterData，因此我参考了XML规范，但是感到困惑。

XML 1.0 和 XML 1.1 声明，有效的 XML 字符包括“制表符、回车、换行以及 Unicode 和 ISO/IEC 10646 的合法字符”。听起来很愚蠢：制表符、回车和换行 已经是 Unicode 的合法字符了。然后还有这个注释：“任何 Unicode 字符，除了代理块、FFFE 和 FFFF”，在 XML 1.1 中被修改为指 U+0000 – U+10FFFF，不包括 U+0000、U+D800 – U+DFFF 和 U+FFFE – U+FFFF；请注意 NUL 被排除在外。还有一个注释说，作者“不鼓励”使用兼容字符，其中包括一些已经被 BNF 排除的字符。

问题：什么是/曾经是合法的Unicode字符？NUL是否是有效的Unicode字符？（我找到了ISO 10646（第2版，2010年）的pdf，似乎没有排除U+0000。）在2000版和2010版之间，ISO 10646或Unicode是否更改以包括先前排除的控制字符？至于XML，为什么文本如此宽松/松散而BNF则很严格？

- yonran

4个回答

1

“字符”一词在Unicode标准中是有意模糊的，但大多数情况下它被用于技术意义上：指定为已分配字符代码点的代码点。这并不完全符合字符的直观概念。例如，由字母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位代码单元序列）的情况下。

- Jukka K. Korpela

1

我会忽略掉言辞，只关注定义:

XML 1.0：

鼓励文档作者避免使用“兼容字符”，如[Unicode]第2.3节中定义的那些字符。以下范围内定义的字符也不建议使用，它们要么是控制字符，要么是永久未定义的Unicode字符： [#x7F-#x84]、[#x86-#x9F]、[#xFDD0-#xFDEF]、 [#x1FFFE-#x1FFFF]、[#x2FFFE-#x2FFFF]、[#x3FFFE-#x3FFFF]、 [#x4FFFE-#x4FFFF]、[#x5FFFE-#x5FFFF]、[#x6FFFE-#x6FFFF]、 [#x7FFFE-#x7FFFF]、[#x8FFFE-#x8FFFF]、[#x9FFFE-#x9FFFF]、 [#xAFFFE-#xAFFFF]、[#xBFFFE-#xBFFFF]、[#xCFFFE-#xCFFFF]、 [#xDFFFE-#xDFFFF]、[#xEFFFE-#xEFFFF]、[#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]、 [#x4FFFE-#x4FFFF]、[#x5FFFE-#x5FFFF]、[#x6FFFE-#x6FFFF]、 [#x7FFFE-#x7FFFF]、[#x8FFFE-#x8FFFF]、[#x9FFFE-#x9FFFF]、 [#xAFFFE-#xAFFFF]、[#xBFFFE-#xBFFFF]、[#xCFFFE-#xCFFFF]、 [#xDFFFE-#xDFFFF]、[#xEFFFE-#xEFFFF]、[#xFFFFE-#xFFFFF]、 [#x10FFFE-#x10FFFF]。

- Remy Lebeau

0

听起来很愚蠢，因为它确实很愚蠢。XML的第一版（1998年）中写道“Unicode的合法图形字符。”出于某种原因，第二版于2000年将“图形”一词删除了，可能是因为这是不准确的：XML允许许多不是图形字符的字符。

Char生产中的定义确实是查找的正确位置。

- John Cowan

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Mike Samuel · Accepted Answer

问题：什么是/曾经是合法的Unicode字符？ Unicode词汇表这样定义它：

字符。（1）书写语言中具有语义价值的最小组成部分；指抽象意义和/或形状，而不是特定的形状（参见字形），尽管在代码表中某种形式的视觉表示对于读者的理解至关重要。（2）抽象字符的同义词。（3）Unicode字符编码的基本编码单元。（4）汉字书写元素的英文名称。[请参阅表意文字（2）。]

NUL是一个有效的Unicode字符吗？（我找到了一份ISO 10646（第2版，2010年）的pdf文件，似乎没有排除U+0000。）

NUL是一个码点，它符合“抽象字符”的定义，因此根据上述意义，它是一个字符。

ISO 10646或Unicode在2000版和2010版之间是否发生了变化，以包括先前被排除的控制字符？

NUL从早期版本就是控制字符。附录D中包含了变更列表。

表D.2中指出，在版本1到版本3中有65个控制字符没有变化。

Table D-2 documents the number of characters assigned in the different versions of the Unicode standard.
         V1.0 V1.1 V2.0 V2.1 V3.0
...
Controls   65   65   65   65   65

关于XML，为什么文本内容如此宽松而BNF非常严格？

编写既完整又简洁的规范很难。当文本与BNF不一致时，请相信BNF。