为什么最大 Unicode 代码点限制为 0x10FFFF？是否可以通过 UTF-16、UTF-8 等任何编码方案在此代码点上方表示 Unicode - 例如 0x10FFFF + 0x000001 = 0x110000？
问问题
4515 次
1 回答
24
这是因为 UTF-16。基本多语言平面 (BMP) 之外的字符使用 UTF-16 中的代理对表示，第一个代码单元 (CU) 位于0xD800–0xDBFF之间，第二个代码单元 (CU) 位于0xDC00–0xDFFF之间。每个 CU 代表 10 位代码点，允许总共20 位数据（0x100000 个字符）被分成16 个平面（16×2 16 个字符）。剩余的 BMP 将代表 0x10000 个字符（代码点 0–0xFFFF）
因此，字符总数为17×2 16 = 0x100000 + 0x10000 = 0x110000，这允许代码点从 0 到 0x110000 - 1 = 0x10FFFF。或者，最后一个可表示的代码点可以这样计算：BMP 中的代码点在 0–0xFFFF 范围内，因此使用代理对编码的字符的偏移量是 0xFFFF + 1 = 0x10000，这意味着最后一个代码点代理对表示的是 0xFFFFF + 0x10000 = 0x10FFFF
这是由Unicode 字符编码稳定性策略保证的，即永远不会分配高于该代码点的代码点
General_Category 属性值 Surrogate (Cs) 是不可变的：具有该值的代码点集永远不会改变。
从历史上看，UTF-8最多允许 U+7FFFFFFF 使用 6 个字节，而 UTF-32 可以存储两倍的数量。然而，由于 UTF-16 的限制，Unicode 委员会决定 UTF-8 永远不能超过 4 个字节，导致与 UTF-16 的范围相同
2003 年 11 月，UTF-8 受到 RFC 3629 的限制，以匹配 UTF-16 字符编码的约束：明确禁止高低代理字符对应的代码点删除超过 3% 的三字节序列，并以在 U+10FFFF 删除了超过 48% 的四字节序列和所有五字节和六字节序列。
这同样适用于 UTF-32
2003 年 11 月，Unicode 受到 RFC 3629 的限制，以匹配 UTF-16 编码的约束：明确禁止大于 U+10FFFF 的代码点（以及从 U+D800 到 U+DFFF 的高和低代理项）。这个有限的子集定义了 UTF-32
你可以阅读这个更详细的答案和
于 2018-09-06T12:15:03.643 回答