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 替代方案

我认为您正在提议使用类似于 UTF-8 代码方案的 16 位代码单元的替代格式——让我们将其指定为 UTF-EMF-16。

在您的 UTF-EMF-16 方案中，从 U+0000 到 U+7FFF 的代码点将被编码为单个 16 位单元，MSB（最高有效位）始终为零。然后，您将保留 16 位单元，其中 2 个最高有效位设置10为“连续单元”，以及 14 位有效载荷数据。然后，您可以将代码点从 U+8000 编码到 U+10FFFF（当前最大的 Unicode 代码点），以 16 位为单位，其中三个最高有效位设置为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：

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

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

使用以下类型定义

typedef unsigned int16 UTF16;
typedef unsigned int32 UTF32;

第一个片段根据字符代码 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 位分布中使用的标签。下一个片段对低代理执行相同的操作。

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 在适当的范围内。[