Unicode 为什么UTF-32存在，而编码每个字符只需要21位？

我们知道，代码点可以在小于2^21的0..10FFFF间隔内。那么，当所有代码点都可以用3个字节表示时，为什么我们需要UTF-32呢？UTF-24应该足够了。

的确，只需要21位（），但现代计算机擅长移动32位单位的物体并通常与它们进行交互。我想我从来没有使用过24位整数或字符类型的编程语言，也没有使用过处理器字长倍数的平台（自从我上次使用8位计算机以来就没有使用过；UTF-24在8位机器上是合理的），当然也有一些原因。

我可以想到两个原因：

• 它允许将来扩展
• （更重要的是）计算机通常更擅长处理4字节边界上的数据。与处理3字节边界的痛苦相比，减少内存消耗的好处相对较小

---

我想这有点像是在问为什么我们通常有8位、16位、32位和64位整数数据类型（byte、int、long等等），而不是24位。我相信在很多情况下，我们知道一个数字永远不会超过221，但使用

int

比创建24位类型更简单。

UTF-32是16位的倍数。使用32位数量比使用24位数量更常见，并且通常得到更好的支持。它还有助于保持每个字符4字节对齐（假设整个字符串是4字节对齐的）。从1字节到2字节再到4字节是最“合乎逻辑”的过程

---

除此之外，Unicode标准正在不断发展。超出该范围的代码点最终可能会被分配（但是，由于仍有大量未分配的代码点可用，在不久的将来这是不太可能的）。

首先有两种字符编码方案：UCS-4将每个字符编码为32位，作为0x00000000-0x7FFFFFFF范围内的无符号整数，和UCS-2，每个码点使用16位

后来人们发现，仅仅使用UCS-2的65536个代码点无论如何都会使人陷入问题，但许多程序（Windows、cough）依赖16位宽的宽字符，因此创建了UTF-16。UTF-16对

U+0000

-

U+FFFF

范围内的码品进行编码，就像UCS-2一样；和

U+10000

-

U+10FFFF

使用代理项对，即两个16位值的对

由于这有点复杂，引入了UTF-32，作为

U+FFFF

以外字符的简单一对一映射。现在，由于UTF-16最多只能编码

U+10FFFF

，因此决定这将是有史以来分配的最大值，因此不会有进一步的兼容性问题，因此UTF-32实际上只使用21位。作为额外的好处，UTF-8最初计划采用1-6字节编码，现在每个代码点所需的字节数不再超过4个。因此，可以很容易地证明，它从来都不需要比UTF-32更多的存储空间

的确，假设的UTF-24格式可以节省内存。然而，它的节约无论如何都是值得怀疑的，因为它将消耗比UTF-8更多的存储空间，除了大量的表情符号之类的东西——并且没有多少很长的有趣的文本完全由表情符号组成

---

但是,，UTF-32被用作程序中文本的内存表示，这些程序需要对代码点进行简单的索引访问-这是唯一的编码，其中C数组中的第n个元素也是第n个代码点-UTF-24可以节省25%的内存，但更复杂的元素访问。

我使用了一个24位处理器不久前的话。可能是Sigmatel的产品吧？我现在记不起来了。虽然24位字在大多数处理器上都不太合适，但24位仍然是一个非常高效的存储库。它广泛应用于媒体应用中，包括音频（24位是录音室录音的标准位深度）和视频（3个彩色通道，8位）。在这些应用程序中，性能并不是不重要的！现在是2018年，几乎所有的计算机都可以轻松地以全性能使用64位数据类型。要扩展到21位以上，我们需要一种新的“UTF-16兼容”编码。否则我们就放弃UTF-16。我不介意，但所有将Unicode视为UTF-16同义词的应用程序、库和系统可能都不会高兴。将3个代码点填充到64位整数中如何？3 21位数字完全适合64位整数（有符号或无符号）。@ColeJohnson:那会有用，但只有在我们发现21位还不够时。。。而且它在需要位移位等方面仍然不太容易处理。但在某些情况下，它可能是一个有用的实现。可以将UTF-32想象为等同于32位填充RGBx像素格式，通常用于没有alpha通道的图像，以保持像素字对齐。这只是渗透到软件设计中的CPU时间与内存占用权衡的另一个产物。即使在8位计算机上，4字节对齐并不是一件真正的事情，您也必须乘以3来索引UTF-24字符数组。以6502台像Commodore 64这样的机器为例，将一个字节值乘以3需要四条指令，总共6个字节和10个时钟周期；相反，将其乘以4只需要占用两个字节和4个周期的两条指令。