对于 Unicode 标准 3.0.1 版，您需要了解什么

Tony Graham
高级顾问，Mulberry Technologies, Inc.
2000 年 11 月

内容：


3.0.1 版如何重要？
名称的含义？
四倍、五倍或六倍
更改了什么？
认识不可知的
参考资料  
关于作者  

2000 年 8 月发布的 Unicode 3.0.1 版是自 1999 年 9 月完成版本 3.0 标准和 2000 年 2 月发布 Unicode Standard, Version 3.0 一书之后，对 Unicode 标准的第一次更新。这次更新向 Unicode 字符数据库添加了 3 个新文件，引入了新的变长 Unicode 代码点表示法，同时还澄清和扩展了该书的某些部分。本文解释 Unicode 3.0.1 引入的更改和补充。

3.0.1 版如何重要？
3.0.1 版是对 Unicode 标准的更新。"3.0.1" 中的三个数字分别代表主、次和更新版本号。对于针对 Unicode 标准作出重要更改的主版本，为其分配新的主号，并以书籍形式发布。对于针对标准的规范部分作出字符上的添加和重要的、但不是主要更改的次版本（例如即将推出的版本 3.1），保留当前主号，分配新的次号，并以 Unicode 技术报告的形式发布。对于更改了标准的规范或重要的信息性部分、并可能影响支持 Unicode 的软件的那些对标准的更新（如 3.0.1 版），保留当前主和次版本号，分配新的更新号，并在 Unicode 联盟的 Web 站点上以“更新页”的形式发布。（请参阅参考资源）。

规范性和信息性
“规范性”和“信息性”这两个词经常出现在 Unicode 标准的任何讨论中，并肯定也会出现在字符属性或 Unicode 字符数据库的任何详细讨论中。
“规范性”指为与标准一致所需的东西。例如，在 Unicode Standard, Version 3.0 的 4.6 小节中定义的“数值”属性是表示数字的字符的规范属性。符合该属性的 Unicode 应用程序必须将所有具有数值的字符作为数字处理。类似地，Unicode Standard, Version 3.0 的 3.12 小节中所描述的双向算法，是所有显示包含从右到左字符的文本的应用程序规范。

相反，“信息性”指作为标准的一部分提供，但不是为符合标准所必需的 Unicode 标准的特性或其它方面。例如，Unicode Standard, Version 3.0 的 4.10 小节中定义的表意属性，是表意字符的信息性属性。应用程序无需对表意属性做任何事：如果使用它，当然可以，如果不使用，也没关系。

名称的含义？
3.0.1 版引入了两个新的 Unicode 技术报告 (UTR) 类别。通过数字标识所有技术报告（例如 UTR #7），但是，现在还有两个附加的报告类别：UAX 和 UTS。

Unicode 标准附录 (UAX) 被认为是 Unicode 标准的一部分，它恰巧也以单独文挡的形式发布。UAX 版本号采用标准的版本号，因此，目前所有 UAX 的版本都是 3.0.1 版。目前的 UAX 有：

UAX #9：双向算法
UAX #11：东亚宽度
UAX #13：Unicode 新行指引
UAX #14：断行属性
UAX #15：Unicode 范式

Unicode 技术标准 (UTS) 是在实现时可选择遵循的独立规范。每个 UTS 都指定 Unicode 标准的基本版本，但与特定 Unicode 版本无关。UTS 版本号只是随每个 UTS 新版本增加的整数。目前的 UTS 有：

UTS #6：Unicode 的标准压缩模式
UTS #10：Unicode 整理算法

目前的 UAX 和 UTS 是引入新的分类之前的 UTR，3.0.1 版没创建新报告。其它现有的 Unicode 技术报告仍是 UTR：

UTR #7：平面 14 语言标记字符
UTR #16：UTF-EBCDIC
UTR #17：字符编码模型
UTR #18：Unicode 规则表达式指南
UTR #19：UTF-32
UTR #21：大小写映射

技术报告的余下类别是草案 Unicode 技术报告 (DUTR) 和建议草案 Unicode 技术报告 (PDUTR)。目前有三个 DUTR，还没有 PDUTR。

技术报告可由比较新的技术报告或包含它们的标准文本所取代。用 "superseded"（例如，"superseded UTR"）标记被取代的报告，而不再创建更多的缩写词（如 SUAX 或 SUTS）。

四倍、五倍或六倍
在 Unicode Standard, Version 3.0 中，将 Unicode 值表示成 U+nnnn，其中，nnnn 是四位十六进制数。与 ISO/IEC 10646 一样，使用 nnnnnnnn 的形式（其中，nnnnnnnn 是八位十六进制数）来表示基本多语言平面 (BMP) 之外的字符。

除了 BMP 之外，Unicode 标准还定义了 16 个辅助平面。目前，BMP 以外的代码点只用于“专用”字符，但是，Unicode 标准（以及 ISO/IEC 10646-2）将很快在平面 1 和平面 2 中分配字符。因为最大的 Unicode 数值是 10FFFF16，所以，用八位十六进制数书写 Unicode 值意味着：将用没有实际意义的两个或三个前导零书写每个非 BMP 字符。

为了使所有人感到方便，3.0.1 版引入了 U+n 这样的变长 Unicode 值表示法，其中，n 是四到六位十六进制数。与前面的四位表示法一样，只有在可以用少于四位十六进制数书写代码点时，才使用前导零。3.0.1 版中的例子有 U+0001、U+0012、U+0123、U+1234、U+12345 和 U+102345。

Unicode 字符数据库目录名称
http://www.unicode.org/Public/3.0-Update1/" 中的 "Update1" 指的是自版本 3.0 以后，3.0.1 版是对 Unicode 标准所作的第一次发行的更新，而不是特别指 "1" 这个更新号。例如，如果 Uicode 技术委员会创建了版本 3.0.2 和 3.0.3，但却没有发布，则将把发行版 3.0.4、版本 3.0.4 文件放在 3.0-Update2 目录、而不是 3.0-Update4 中。
Unicode 字符数据库更改
可以在 http://www.unicode.org/Public/3.0-Update1/（和 ftp://ftp.unicode.org/Public/3.0-Update1/）上获得 3.0.1 版中新的或更改的 Unicode 字符数据库文件。某些文件的版本号反映了 Unicode 版本，还有一些反映了文件修订本号。

3.0.1 版中更改了以下文件：

ArabicShaping-3.txt
CompositionExclusions-2.txt（只更改了注释）
Jamo-3.txt
PropList-3.0.1.txt
ReadMe-3.0.1.txt
SpecialCasing-3.txt
UnicodeCharacterDatabase-3.0.1.html
UnicodeData-3.0.1.html
UnicodeData-3.0.1.txt

将在后续章节中解释 3.0.1 版中的以下新文件：

BidiMirroring-1.txt
CaseFolding-2.txt
NormalizationTest-3.0.1.txt

BidiMirroring.txt
这个信息性数据文件列出了具有镜像属性的字符，具有这种属性的字符，其具有镜像图像字型的镜像字符也在 Unicode 标准中编码。按出现顺序，BidiMirroring.txt 中的每一个非注释行包含以下 Unicode 标准中字符的信息：

源字符代码点
具有镜像图像字型的字符代码点
包含源字符名称的注释，如果是不完全镜像，则字符名称前有 "[BEST FIT]"

在该文件末尾的注释中，列出了具有镜像属性，但在 Unicode 中没有镜像字符的字符。

下面显示了 BidiMirroring.txt 的五个样本行：

BidiMirroring.txt 摘录

0028; 0029 # LEFT PARENTHESIS
0029; 0028 # RIGHT PARENTHESIS
003C; 003E # LESS-THAN SIGN
003E; 003C # GREATER-THAN SIGN
005B; 005D # LEFT SQUARE BRACKET

例如，与 U+0028（左圆括号）镜像的是 U+0029（右圆括号）。类似地，U+0029 的镜像是 U+0028。

CaseFolding.txt
这个信息性数据文件包含从大写、首字母大写、重音和字母结合以及某些数字和符号到小写形式的、与语言环境无关的映射。当进行不区分大小写的文本比较时使用这些数据，对要比较的字符串中的字符应用合并大小写映射消除了任何大小写差异。

按出现顺序，CaseFolding.txt 中的每个非注释行包含以下 Unicode 标准中字符的信息：

源字符代码点
大小写映射状态，即，代表 1 对 1 小写映射的 "L"，或代表例外情况的 "E"
源字符合并大小写映射的一个或多个代码点
包含源字符名称的注释

下面显示了 CaseFolding.txt 的五个样本行：

CaseFolding.txt 摘录

005A; L; 007A; #LATIN CAPITAL LETTER Z
00B5; E; 03BC; #MICRO SIGN
00C0; L; 00E0; #LATIN CAPITAL LETTER A WITH GRAVE
00DF; E; 0073 0073; #LATIN SMALL LETTER SHARP S
FB04; E; 0066 0066 006C; #LATIN SMALL LIGATURE FFL

U+005A 的映射是从 "Z" 到 "z" 的简单的 1 对 1 映射。因为 U+00B5 MICRO 符号是映射成另一个小写字母的小写字母，所以将 U+00B5 映射标记成例外。U+00C0 映射是从大写重音字符到其兼容性分解映射的 1 对 1 映射。因为 U+00DF LATIN SMALL LETTER SHARP S 映射成两个字符，所以，U+00DF 是个例外。因为其大写映射是到 "SS" 的映射，所以，它映射成两个字符。U+FB04 映射在其兼容性分解映射中映射成三个字符。

NormalizationTest.txt
这个文件包含 15228 个测试案例，用于验证程序是否符合在 UAX #15 Unicode 范式中定义的规范规则。该文件包括一个解释文件格式的初始注释，21 个特定测试案例，以及 15207 个通用测试案例。每个非注释行代表一个测试。每个测试行包含五个由分号隔开的字段（在文件的初始注释中称为“栏”c1 到 c5），在后面跟有注释。每个字段包含一个或多个 Unicode 字符的代码点。这个代码列表显示了 NormalizationTest.txt 中的前五行。根据浏览器和字体的不同，您可能无法正确查看每一行的非 ASCII 字符。

这五列中的字符或字符序列足以用来测试是否正确实现了所有的范式：C、D、KC 和 KD。在范式 C 中，列 c2 和列 c1 到 c3 的正则化形式的值都相同，列 c4 和 c4 和 c5 正则化形式的值也都相同。在范式 D 中，c3 和 c1 到 c3 的正则化值都相同，c5 和 c4 到 c5 的正则化值也都相同。在范式 KC 中，c4 和 c1 到 c5 的正则化值都相同，在范式 KD 中，c5 和 c1 到 c5 的正则化值也都相同。很明显，15228 个测试不足以测试每一个 Unicode 字符的范式，但是，该文件的初始注释说明，对于任何没有列出的 Unicode 3.0 代码点，范式 C、D、KC 和 KD 中的代码点及其值完全相同。

每一个测试末尾的注释都在测试列 c1 到 c5 中包含字符或字符序列的 UTF-8 表示，后面跟有测试中所用字符的 Unicode 字符名称。如果了解 UTF-8，则 UTF-8 文本会有帮助，否则会令人迷惑。如果没有可以处理 UTF-8 的编辑器，或许可以将文件重命名，将其扩展名改成 .html，然后在 Web 浏览器中打开。可能还需要手工设置编码和字体，才能正确查看文件。

认识不可知的
Unicode 标准中的规范部分（例如双向算法、断行算法和范式）依赖与代码点相关联的字符属性。同时，Unicode 标准包括很多目前还没有分配给字符、但可能会在以后版本中分配字符的代码点。另外，标准还包括多个分配了最小属性的专用字符区域。而且，虽然不受支持的字符通常被显示成难看的字型，但是，某些字符（例如格式和控制字符）并没有可视的字型。

3.0.1 版修改了 Unicode 标准的文本，以阐明在实现时如何处理未分配的代码点：

现在保留范围 U+2060-U+2069 和 U+E0000-U+E1000，以用于日后在格式化和显示时应该被忽略的格式和控制字符。
UAX #9，Unicode 双向算法，以块的形式为未分配的代码点分配双向类别。
UAX #11，东亚宽度，还以块的形式为未分配的代码点定义缺省属性。
UAX #14，断行属性，为所有未分配的代码点分配属性 "XX"。
正则化算法为所有未分配的代码点分配一个规范的 0 组合类和不分解的映射。

非字符与 XML
虽然 3.0.1 版（和 ISO/IEC 10646-1:1993）将 U+FFFE、U+FFFF、U+1FFFE、U+1FFFF 等声明为非字符，但是，XML Recommendation 的 Production 2，“字符”（第 1 和第 2 版）明确禁止将 #xFFFE 和 #xFFFF（为了使用 XML 表示法）作为字符，但是允许范围 #x10000 到 #x10FFFF 之内的字符。然而，该建议书第 2 版的文本声明：“合法字符为制表键、回车、换行以及 Unicode 和 ISO/IEC 10646 的合法字符”。第二版还说明：“XML 处理器必须接受为“字符”指定的范围内的任何字符。该建议没有提到：Unicode 标准或 ISO/IEC 10646 新版本禁止将某些代码点用作字符。
一个有趣（可能有些不切实际）的问题是：首先，在 XML 文档中是否允许使用 #x1FFFE 等代码点，其次，如果 XML 处理器接收到这些字符，它们是否会正确处理。我不知道答案，但是，您也无需深究，因为在 XML 文档中不应该使用那些代码点。

非字符
ISO/IEC 10646-1:1993 一直在声明：将平面中最后两个代码点 - 即将那些具有 RC 元素值 FFFE16 或 FFFF16（为了逐渐进入 ISO-先讲一会）- 分类成非字符，并永远不会将其分配给字符。Unicode 标准所包含的非字符代码点是 U+FFFE、U+FFFF、U+1FFFE、U+1FFFF、U+10FFFE、U+10FFFF。

以前版本的 Unicode 标准曾说过：U+FFFE 和 U+FFFF 将不解释成抽象字符，但是没有提到其它非字符代码点 - 甚至从版本 2.0 之后，Unicode 标准还支持 UTF-16。

3.0.1 版修改了 Unicode 标准第 3 章中的定义和符合性条款，以声明：以 FFFE16 和 FFFF16 结束的 Unicode 值（例如，U+nFFFE 和 U+nFFFF，其中，n 从 0 到 1016）为非字符。尽管应用程序可以在内部使用这些值，但现在说明：不将非字符解释成抽象字符。当应用程序遇到某些不在内部表示法中使用的非字符时，该应用程序可以发出错误通知，也可以删除或忽略违反规则的非字符。

联接或非联接
3.0.1 版扩展了 U+200C，ZERO WIDTH NON-JOINER（或 ZWNJ）和 U+200D，零宽度联接符（或 ZWJ）的语义学。3.0.1 版中的相关文本完全替代 Unicode 标准中 Layout Controls 第 13.2 小节 "Controlling Ligatures" 子节的文本。

Unicode Standard, Version 3.0 称：可以使用 ZWJ 和 ZWNJ 来停止字母结合的形成，但却没有提供实施或鼓励形成字母结合的方式。然而，3.0.1 版却分别提供了使用 ZWJ 来促进字符之间的字母结合形成或草体连接，使用 ZWNJ 来断开字母结合或草体连接，以及使用 ZWJ-ZWNJ 和 ZWJ-ZWNJ-ZWJ 组合来促进序列一端或两端的草体连接的指南，同时又不允许形成字母结合。

其它较小的更改
澄清标识符
3.0.1 版将版本 3.0 5.16 小节中 "Specific Character Additions" 子节重命名为 "Specific Character Adjustments"，并添加了一条注释：考虑不在标识符中使用任何具有 <font> 分解的字符是有用的。

数字分隔符声明
3.0.1 版向 6.1 小节添加一条声明：可以将某些字符 -- 特别是 U+002E、U+002C、U+060C、U+066B 或 U+066C，但也可能是其它字符 -- 用作数字分隔字符。

参考资料

Unicode 3.0.1 版页面位于 http://www.unicode.org/unicode/standard/versions/Unicode3.0.1.html。
可以从 http://www.unicode.org/Public/UNIDATA/ 获得当前 Unicode 字符数据库文件（镜像站点是 ftp://ftp.unicode.org/Public/UNIDATA/）。
Unicode 的每一个发行版（主、次或更新）都在 http://www.unicode.org/Public/（和 ftp://ftp.unicode.org/Public/）有一个单独目录，包含该标准版本的新的、或更改的 Unicode 字符数据库文件。
可以在 http://www.unicode.org/Public/3.0-Update1/（和 ftp://ftp.unicode.org/Public/3.0-Update1/）获得 3.0.1 版中新的或更改的 Unicode 字符数据库文件。
关于作者
Tony Graham 是 Unicode: A Primer，IDGBooks Worldwide，2000 年 3 月 (ISBN: 0764546252) 的作者。这是有关 Unicode 标准版本 3.0 及其用法的第一本、也是唯一一本书籍。Tony 是澳大利亚人，他是 Unicode 联盟的专家成员和位于美国马里兰州 Rockville 的 Mulberry Technologies, Inc. 的高级顾问。