UTF-16 编码 - 为什么使用复杂的代理对？答案

【问题标题】：UTF-16 Encoding - Why using complex surrogate pairs?UTF-16 编码 - 为什么使用复杂的代理对？
【发布时间】：2020-05-07 05:33:55
【问题描述】：

我一直在研究字符串编码方案，在研究 UTF-16 的工作原理时，我有一个问题。为什么使用复杂的代理对来表示 21 位代码点？为什么不简单地将位存储在第一个代码单元中，将剩余位存储在第二个代码单元中？我错过了什么吗！像我们在 UTF-8 中那样直接存储位有问题吗？

我想的例子：

字符'????'

对应码位：128579（十进制）
二进制形式：1 1111 0110 0100 0011（17 位）
它是 17 位代码点。

基于 UTF-8 方案，将表示为：

240 : 11110 000
159 : 10 011111
153 : 10 011001
131 : 10 000011

在 UTF-16 中，为什么不这样做而不是使用代理对：
```
49159 : 110 0 0000 0000 0111
30275 : 01 11 0110 0100 0011
```

【问题讨论】：

第一个单元中存储哪些位？您将哪些位存储在第二个单元中？你怎么知道你正在处理的是一个 21 位数字，而不是两个 16 位数字（代码点）？当您有代理对时，您必须能够明确确定。这就是 UTF-16 编码的作用。这也是为什么最大的 Unicode 代码点是 U+10FFFF 的原因——你不能用目前设计的方案只用两个代理来编码更大的东西。
另外，你对 UTF-8 有误解；它使用类似的方案将 21 位数字存储在 8 位字符中。事实上，UTF-8 比 UTF-16 更复杂，因为它对各种代码点使用四种不同的编码（具有四种不同的长度），而不是像 UTF-16 那样只使用两种不同的编码。
请再看问题，我已经编辑过了。
还有一个历史维度：当 UTF-16（当时称为 UCS2）被认为 2 个字节（65536 个代码点）不够用时，它已经在使用了。那时，发明了代理对解决方案，他们保留了两个仍未使用的范围。如果您认为 UTF-16 很复杂，答案可能是它从一开始就不是这样设计的。
@MrLister...哇，这是我第一次听说 UTF-8 比 UTF-16 更复杂的说法 :) 我想这取决于你对这个词的定义“复杂”

标签： string unicode utf-8 character-encoding utf-16

【解决方案1】：

建议的 UTF-16 替代方案

我认为您提出了一种使用 16 位代码单元的替代格式，类似于 UTF-8 代码方案 - 我们将其指定为 UTF-EMF-16。

在您的 UTF-EMF-16 方案中，从 U+0000 到 U+7FFF 的代码点将被编码为单个 16 位单元，MSB（最高有效位）始终为零。然后，您将保留 2 个最高有效位设置为 10 的 16 位单元作为“延续单元”，以及 14 位有效负载数据。然后，您将以 16 位单元对从 U+8000 到 U+10FFFF（当前最大 Unicode 代码点）的代码点进行编码，其中三个最高有效位设置为 110 和最多 13 位的有效负载数据。使用当前定义的 Unicode (U+0000 .. U+10FFFF)，您永远不需要超过 13 位集合中的 7 个。

U+0000 .. U+7FFF   — One 16-bit unit: values 0x0000 .. 0x7FFF
U+8000 .. U+10FFF  — Two 16-bit units:
                     1. First unit  0xC000 .. 0xC043
                     2. Second unit 0x8000 .. 0xBFFF

对于您的示例代码点，U+1F683（二进制：1 1111 0110 0100 0011）：

First unit:  1100 0000 0000 0111 = 0xC007
Second unit: 1011 0110 0100 0011 = 0xB643

第二个单元与您的示例的不同之处在于反转两个最高有效位，从您示例中的 01 到我的示例中的 10。

为什么在 UTF-16 中没有使用这种方案

这样的计划可以奏效。这是明确的。它可以容纳比 Unicode 当前允许的更多的字符。 UTF-8 可以修改为 UTF-EMF-8，以便它可以处理相同的扩展范围，其中一些字符需要 5 个字节，而不是当前的最大 4 个字节。具有 5 个字节的 UTF-EMF-8 最多可编码 26 位； UTF-EMF-16 可以编码 27 位，但应限制为 26 位（大约 6400 万个代码点，而不是刚刚超过 100 万个）。那么，为什么不采用它或类似的东西呢？

答案很常见——历史（加上向后兼容性）。

当首次定义 Unicode 时，人们希望或相信 16 位代码集就足够了。 UCS2 编码是使用 16 位值开发的，0x8000 .. 0xFFFF 范围内的许多值都被赋予了含义。比如U+FEFF就是字节序标记。

当必须扩展 Unicode 方案以使 Unicode 成为更大的代码集时，许多已定义的字符在最高有效位中具有 10 和 110 位模式，因此向后兼容意味着 UTF-如果不破坏与 UCS2 的兼容性，上述 EMF-16 方案无法用于 UTF-16，这将是一个严重的问题。

因此，标准化者选择了一种替代方案，其中有高代理和低代理。

0xD800 .. 0xDBFF   High surrogates (most signicant bits of 21-bit value)
0xDC00 .. 0xDFFF   Low surrogates (less significant bits of 21-bit value)

低代理范围提供 10 位数据的存储 — 前缀 1101 11 使用 16 位中的 6 位。高代理范围还提供 10 位数据的存储 — 前缀 1101 10 也使用 16 位中的 6 位。但是由于 BMP（Basic Multilingual Plane — U+0000 .. U+FFFF）不需要用两个 16 位单元编码，UTF-16 编码从高阶数据中减去1，因此可以用于编码 U+10000 .. U+10FFFF。（请注意，虽然 Unicode 是 21 位编码，但并非所有 21 位（无符号）数字都是有效的 Unicode 代码点。来自 0x110000 .. 0x1FFFFF 的值是 21 位数字，但不是 Unicode 的一部分。）

来自 Unicode FAQ — UTF-8, UTF-16, UTF-32 & BOM：

问：从 UTF-16 转换为字符码的算法是什么？

A: Unicode 标准曾经包含一个简短的算法，现在只有一个位分布表。下面是三个短代码 sn-ps，它们将位分布表中的信息转换为 C 代码，从而与 UTF-16 相互转换。

使用以下类型定义
typedef unsigned int16 UTF16;
typedef unsigned int32 UTF32;
第一个 sn-p 计算字符代码 C 的高（或前导）代理项。
const UTF16 HI_SURROGATE_START = 0xD800

UTF16 X = (UTF16) C;
UTF32 U = (C >> 16) & ((1 << 5) - 1);
UTF16 W = (UTF16) U - 1;
UTF16 HiSurrogate = HI_SURROGATE_START | (W << 6) | X >> 10;
其中 X、U 和 W 对应于表 3-5 UTF-16 位分布中使用的标签。下一个 sn-p 对低代理做同样的事情。
const UTF16 LO_SURROGATE_START = 0xDC00

UTF16 X = (UTF16) C;
UTF16 LoSurrogate = (UTF16) (LO_SURROGATE_START | X & ((1 << 10) - 1));
最后反过来，hi 和 lo 是高位和低位代理，C 是结果字符
UTF32 X = (hi & ((1 << 6) -1)) << 10 | lo & ((1 << 10) -1);
UTF32 W = (hi >> 6) & ((1 << 5) - 1);
UTF32 U = W + 1;

UTF32 C = U << 16 | X;
调用者需要确保 C、hi 和 lo 在适当的范围内。 [

【讨论】：

感谢您的宝贵时间。所以这都是关于“向后兼容性”的，通过使用我的模式，我将无法确定这个代码单元是编码单个字符还是代理对的一部分。但是我想知道如果两个连续的单字符代码单元以代理对的相同标记开头怎么办？
您的方案可以使用并且是明确的——但它不会向后兼容 UCS2，而 UTF-16 向后兼容。是的，由于“向后兼容性”，做出了许多奇怪的决定。这是一个非常常见的原因，否则可能会被视为“非显而易见”的设计决策。
如果两个连续的单字符代码单元以与代理对相同的样式开头怎么办？例如，这些字符： 55357 : 1101100000111101 56899 : 1101111001000011 我们怎么知道这些表示是针对单个字符而不是代理对！
您对数据进行了错误编码。在假设的 UTF-EMF-16 编码中，十进制 55357 将使用两个单位进行编码——就像从 U+8000（十六进制）向上的任何其他 Unicode 字符一样。因此，十进制 56899 也是如此（实际上是 U+55357 和 U+56899，以十六进制表示）。此外，十进制 55357 是 U+D83D，十进制 56899 是 U+DE43。这是 UTF-16 中的高代理和低代理。这些是在 UTF-EMF-16 编码下保留的、永久未分配的代码点。没有有效的 UTF-EMF-16 数据会编码任何代理项 U+D800 .. U+DFFF（任何超过有效的 UTF-8 都包含编码代理项）。
最后?码点 U+10000(65,536) 到 U+10FFFFF(1,114,111)，保留补充字符。补充字符被编码为连续的代码单元对。这种编码对中的每个值都落入基本多语言平面（代码点 U+0000(0) 到 U+FFFF(65,535)）的 2048 个“未使用值”范围内，称为代理区域（U+D800 (55296) 到 U+DBFF(56319) 用于第一个代码单元（高代理），U+DC00(56320) 到 U+DFFF(57343) 用于第二个代码单元（低代理））。非常感谢?