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

Question

我一直在研究字符串编码方案，在研究 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
  

Answer 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-EMF-16 方案不能用于 UTF-16，而不会破坏与 UCS2 的兼容性，这将是一个严重的问题。

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

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 :

Q: What’s the algorithm to convert from UTF-16 to character codes?

A: The Unicode Standard used to contain a short algorithm, now there is just a bit distribution table. Here are three short code snippets that translate the information from the bit distribution table into C code that will convert to and from UTF-16.

Using the following type definitions

typedef unsigned int16 UTF16;
typedef unsigned int32 UTF32;

the first snippet calculates the high (or leading) surrogate from a character code 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;

where X, U and W correspond to the labels used in Table 3-5 UTF-16 Bit Distribution. The next snippet does the same for the low surrogate.

const UTF16 LO_SURROGATE_START = 0xDC00

UTF16 X = (UTF16) C;
UTF16 LoSurrogate = (UTF16) (LO_SURROGATE_START | X & ((1 << 10) - 1));

Finally, the reverse, where hi and lo are the high and low surrogate, and C the resulting character

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;

A caller would need to ensure that C, hi, and lo are in the appropriate ranges. [