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

【问题标题】：XML and Unicode specifications: what’s a legal character?XML 和 Unicode 规范：什么是合法字符？
【发布时间】：2012-03-02 01:52:48
【问题描述】：

我的经理让我解释为什么我在将字符串传递给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（2010 年第 2 版）的 pdf，它似乎不排除 U+0000。）ISO 10646 或 Unicode 在 2000 版和 2010 版之间是否发生了变化，以包含以前排除的控制字符？而对于 XML，文本如此宽松/草率，而 BNF 严格是有原因的吗？

【问题讨论】：

标签： unicode xml-parsing

【解决方案1】：

问题：什么是/曾经是合法的 Unicode 字符？

The Unicode Glossary 是这样定义的：

字符。 (1) 书面语言中具有语义价值的最小组成部分；指的是抽象的含义和/或形状，而不是特定的形状（另见字形），尽管在代码表中，某种形式的视觉表示对于读者的理解是必不可少的。 (2) 抽象字符的同义词。 (3) Unicode 字符编码的基本编码单位。（四）汉语表意文字的英文名称。 [见表意文字（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。

【讨论】：

【解决方案2】：

“字符”一词在 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 位代码单元的序列）。

【讨论】：

【解决方案3】：

我会忽略措辞，只关注定义：

XML 1.0：

字符::= #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]、 [#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：

字符::= [#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]。

【讨论】：

【解决方案4】：

这听起来很愚蠢，因为它很愚蠢。 XML 的第一版（1998 年）读作“Unicode 的合法图形字符”。无论出于何种原因，“图形”一词已从 2000 年的第二版中删除，可能是因为它不准确：XML 允许许多不是图形字符的字符。

Char 产生式中的定义确实是正确的地方。

【讨论】：