【发布时间】：2011-09-14 10:46:03
【问题描述】：
我们知道代码点可以在小于 2^21 的 0..10FFFF 区间内。那么当所有代码点都可以用 3 个字节表示时，为什么我们需要 UTF-32 呢？ UTF-24 应该足够了。
【问题讨论】：
【发布时间】：2011-09-14 10:46:03
【问题描述】：
确实只需要 21 位 (reference)，但现代计算机擅长移动 32 位单元并通常与它们交互。我不认为我曾经使用过具有 24 位整数或字符类型的编程语言，也没有使用过处理器字长倍数的平台（自从我上次使用 8 位计算机以来没有；UTF -24 在 8 位机器上是合理的），尽管自然有一些。
【讨论】：
-
不久前我使用了一个 24 位字的处理器。可能是 Sigmatel 的产品？现在想不起来了。
-
虽然 24 位字不能很好地映射到大多数处理器，但 24 位仍然可以成为一个非常有效的存储基础。它在媒体应用中得到了非常广泛的应用，包括音频（24 是工作室录音的标准位深度）和视频（三个颜色通道 à 8 位）。在这些应用程序中，性能并不是不重要的！
-
现在已经是 2018 年了，几乎所有计算机都可以轻松处理 64 位数据类型并充分发挥其性能。
计算机通常更擅长处理 4 字节边界上的数据。与处理 3 字节边界的痛苦相比，减少内存消耗的好处相对较小。
（我推测在提出原始设计时，也不愿意有一个“只有我们目前可以想象的有用的限制”。毕竟，这引起了很多过去的问题，例如 IPv4。虽然我看不到我们需要超过 24 位，但如果 32 位更方便无论如何，那么避免限制 似乎是合理的可能可能会在某一天被击中，通过保留范围等）
我想这有点像问为什么我们经常有 8 位、16 位、32 位和 64 位整数数据类型（byte、int、long 等），而不是 24 位。我相信在很多情况下我们都知道一个数字永远不会超过 221，但使用 int 比创建 24 位类型更简单。
【讨论】：
-
要扩展到超过 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 字符数组。以 Commodore 64 这样的 6502 机器为例，将一个单字节值乘以 3 需要 4 条指令，总共 6 个字节和 10 个时钟周期；将它乘以 4 只需要两条指令，占用 2 个字节和 4 个周期。
UTF-32 是 16 位的倍数。使用 32 位数量比使用 24 位数量更常见，并且通常得到更好的支持。它还有助于使每个字符保持 4 字节对齐（假设整个字符串是 4 字节对齐的）。从 1 字节到 2 字节再到 4 字节是最“合乎逻辑”的过程。
除此之外：Unicode 标准还在不断发展。超出该范围的代码点最终可能会被分配（但在不久的将来不太可能，因为仍有大量未分配的代码点可用）。
【讨论】：
首先有 2 种字符编码方案：UCS-4 将每个字符编码为 32 位，作为 0x00000000 - 0x7FFFFFFF 范围内的无符号整数，UCS-2 将 16 位用于每个代码点.
后来发现只使用 UCS-2 的 65536 个代码点无论如何都会遇到问题，但是许多程序（Windows，咳嗽）依赖于 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 位。作为额外的好处，最初计划为 1-6 字节编码的 UTF-8 现在每个代码点都不需要超过 4 个字节。因此很容易证明它从不需要比 UTF-32 更多的存储空间。
确实，假设的 UTF-24 格式会节省内存。然而，它的节省无论如何都是值得怀疑的，因为它通常会比 UTF-8 消耗更多的存储空间，除了只是表情符号等的爆炸——而且没有多少有趣的长篇文章完全由表情符号组成。
但是，UTF-32 在需要对代码点进行简单索引访问的程序中用作文本的内存表示 - 它是 only 编码，其中 C 数组中的第 N 个元素是第 N 个代码点 - UTF-24 也可以节省 25% 的内存，但元素访问更复杂。
【讨论】：