Unicode私有使用区域
目录
1、概述
2、Unicode标准中的描述
2.1、基本多语言平面的私有区域
2.2、补充私有区域
2.3、私有区域位置
3、实际测试
3.1、测试代码
3.2、测试结果
4、最后的结论
1、概述
Unicode规范中，私有使用区域一共3个，分别是1+2，1是指在BMP(基本多语言平面)中的U+E000到U+F8FF，共6400个编码点位，2是指两个补充私有区域，很大，其范围几乎覆盖了平面15和平面16的全部（BMP是编号为0的平面，15、16是Unicode的最后两个平面，除了末尾的两个编码点，其余都是私有使用区域），15号平面的私有使用区域范围是：U+F0000到U+FFFFD，末尾的两个(U+FFFFE和U+FFFFF)除外；16号平面的私有使用区域范围是：U+100000到U+10FFFD，末尾的两个(U+10FFFE和U+10FFFF)除外。
| 平面编号 | 平面名称 | 范围 | 编码点数量 | 说明 |
|---|---|---|---|---|
| 0 | BMP，基本多语言平面 | U+E000 ~ U+F8FF |
6400 = 4096+2304 | 建议：企业从前(U+E000)往后用，个人从后 U+F8FF往前用 |
| 15 | PUP-A，补充私人使用区域-A | U+F0000 ~ U+FFFFD |
65534 = 65536 - 2 | 末尾的两个(U+FFFFE和U+FFFFF)除外 |
| 16 | PUP-B，补充私人使用区域-B | U+100000 ~ U+10FFFD |
65534 = 65536 - 2 | 末尾的两个(U+10FFFE和U+10FFFF)除外 |
2、Unicode标准中的描述
私有字符被指定为Unicode码位，其解释未由Unicode标准规定，其使用可能由合作用户之间的私人协商决定。这些字符被指定用于私人用途，并且没有定义的、可解释的语义，除非通过私人协议。
私有字符通常用于实现最终用户定义的字符（EUDC），这在东亚计算环境中很常见。Unicode标准没有为私用字符提供图表，因为任何此类字符的性质仅在本标准上下文之外定义。
Unicode标准中提供了三个不同的私有字符块：BMP中的主要私有区（PUA, Private Use Area）和补充平面中的两个补充私有区。
Unicode标准中似有字符块中的所有代码点都被永久指定为私有。Unicode 联盟不会为这些代码点背书或记录对特定标准字符集的赋值。任何之前将字符用作私用字符的行为都与是否以及如何编码该字符的任何实际编码决策没有直接关系。字符标准化必须始终遵循新字符或脚本编码的正常过程。
属性。任何私人协议都无法更改保留给私人使用的字符代码。然而，许多Unicode算法使用General_Category属性或通过引用General_Catagory属性派生的属性。私人协议可以覆盖General_Category或基于它的派生，除非在特定算法的一致性声明中明确禁止覆盖。换言之，私人协议可以定义哪些私人使用字符应被这些私人协议的各方视为空格、数字、字母、标点符号等。特别是，当私有协议将私有字符的General_Category从默认值gc=Co覆盖为其他值，如gc=Lu或gc=Nd时，这样的更改不会改变其作为私有字符的固有身份，而只是根据私有协议指定其预期行为。
对于所有其他属性，Unicode字符数据库还为私有字符提供默认值。除了与规范化相关的属性外，这些默认属性值应被视为信息性的。它们旨在允许实现以一致的方式处理私有字符，即使没有特定的私有协议，并简化通用类型的私有字符的使用。这些默认值基于私有字符的典型用例。实现可以根据其私用要求自由更改或覆盖默认值。例如，私有协议可能指定将两个私有字符视为一个事例映射对，或者私有协议可以指定将呈现一个私有字符，否则将其视为组合标记。
为了以语义一致的方式交换私有字符，用户还可以交换私有定义的数据，这些数据描述了如何解释每个私有字符。Unicode标准没有为这种数据交换提供预定义格式。
规范化。任何私有字符的规范分解和兼容性分解都等于字符本身（例如，U+E000分解为U+E00）。私有字符的Canonical_Combining_Class定义为0（Not_Reordered）。这些值由Unicode标准规范定义，不能通过私人协议更改。规范化格式NFC、NFD、NFKD和NFKC的所有专用字符的处理也由Unicode标准根据这些分解进行规范性定义。（见Unicode标准附件#15，“Unicode规范化格式”）任何私人协议都不得更改这些格式，例如，通过更改私有字符的标准规范或兼容性分解。这意味着，所有私用字符，无论它们受什么私用协议的约束，都会对自己进行规范化，并且永远不会以任何Unicode或malization形式重新排序。
这并不排除就其他转型达成私人协议。因此，可以定义一个与NFC相同的转换“MyCompanyComposition”，只是它将U+E000映射为“a”。然而，NFC、NFD、NFKD和NFKC本身的形式不能因此类协议而改变。
2.1、基本多语言平面的私有区域
主要私有区由U+E000到U+F8FF范围内的代码点组成，总共6400个私有字符。
编码结构。按照惯例，主要私有区被划分为平台编写器的公司级使用分区，从U+F8FF开始向下扩展，以及从U+E000开始向上扩展的最终用户分区。
通过遵循此约定，可以减少平台编写器定义的私有字符与最终用户定义的私有字符之间发生冲突的可能性。然而，应该指出，这只是一个公约，而不是一个强制性规范。原则上，任何用户都可以定义任何私用字符的任何解释。
公司用途子区域。系统供应商和/或软件开发人员可能需要保留一些专用字符，供其软件内部使用。公司用途分区是此类保留的首选区域。此分区中的字符语义分配可能完全是内部的，对最终用户隐藏，并且仅用于特定于供应商的应用程序支持，也可能作为特定于供应商、可供应用程序和最终用户使用的字符分配发布。前一种情况的一个例子是将字符代码分配给系统支持操作，例如或；后一种情况的一个例子是将字符代码分配给特定于供应商的徽标字符，例如苹果的apple字符。
然而，请注意，系统供应商可能需要支持所有专用字符的完全最终用户可定义性，例如gaiji支持或瞬态交叉映射表。使用非字符（见第23.7节“非字符”和第3.4节“字符和编码”中的定义D14）是使用各种不可交换的内部系统哨兵的首选方式。
最终用户子区域。最终用户子区域用于最终用户的私有字符定义或最终用户应用程序的字符空间临时分配。
分区分配。供应商可以选择在公司使用分区中保留私人使用字符的范围，并使最终用户分区的某些定义部分可用于完全免费的最终用户定义。划分这两个分区的约定仅仅是为了方便系统供应商和软件开发人员。由于不同的用户可能有不同的要求，本标准没有明确界定两个分区之间的界限。Unicode标准中没有规定避免两个子区域之间的“堆叠冲突”(stack-heap collision)；换句话说，没有保证最终用户不会在与同一代码点的特定公司私有定义重叠和冲突的代码点定义私有字符。避免定义中的这种重叠取决于实现和用户。
2.2、补充私有区域
编码结构。除了字符U+FFFFE和U+FFFFF外，整个平面15被定义为补充私有区域-A。除了字符U+10FFFE和U+10FFFF外，整个平面16被定义为补充私有区域-B。这些区域共同构成了131068个额外的代码点供私人使用。
补充PUA为基本PUA中6400个私有字符不足的实现提供了额外的私有字符无差别空间。
2.3、私有区域位置
图2-13的纵向编码空间最底部的两个区域（从F0000到100000再到10FFFF）展示了两个私有平面的分配位置，其名称叫“Supplementary Private Use Area-A”和“Supplementary Private Use Area-B”，在整个Unicode的区域中都是在最末位的位置。
图2-14展示了BMP平面中的私有区域分配的位置，在底部倒数第二个的“E000-F8FF Private Use Area”的位置。
3、实际测试
在我的实际测试用例中，发现了有意思的结果，在Mac OS 12 + IDEA2020 + java8的环境中，打印了BMP中的私有使用区域的6400个字符，结果有大部分的编码点是有字符的，但在Mac和Linux的命令行中却发现BMP中的私有使用区域没有可展示的字符。
3.1、测试代码：(使用java语言编写)
public class UnicodePUPTest {
public static void main(String[] args) {
int start = 0xE000;
int end = 0xF8FF;
int count = 0;
for (int i = start; i <= end; i++) {
count++;
System.out.print(((char) i) + " ");
if (i % 640 == 0) {
System.out.println();
}
}
System.out.println("\ncount = " + count);
}
}
3.2、测试结果展示
以下为IDEA的控制台结果截图，可以看到大部分的编码点上有字符被分配上去的：
但是将文本拷贝到文本文件中，在Mac的命令行上用cat命令查看文本却有不一样的结果：
将文件上传到Linux服务器，再用cat命令查看文件内容同样得到了大部分都无法展示的结果：
以下给出了6400个私有区域的字符，在不同的渲染工具可能有不一样的效果：
count = 6400
4、最后的结论
私有区域的字符没有统一的标准，各个工具解析的结果不尽相同。