Encoding 为什么UTF-32使用四个字节？

如果UTF-32仅限于17个平面（1114111字符点），需要21位，那么第四个字节在做什么？

第四个字节就在那里，占据空间（其中填充了0s）

---

理论上，可以设计21位或24位交换格式。实际上，这两个问题都相当棘手。很少（如果有的话）现代计算机有21位或24位数据类型。由于32位字很容易使用，因此使用它们来存储最大值大大小于231-1的数字数据类型是很常见的。

直截了当地说：因为它可以，而且在大多数计算机中使用32位值很容易。我知道，位对齐的数字可能很难在某些平台上实现，但是4B数据类型如何比3B数据类型更容易使用呢？char32的大小可以是3，int32应该用来存储大整数，否？（字符是整数）。假设它是3个字节（所以它实际上是char24:）。其对齐要求是什么？3不是一个有效的答案；没有硬件具有3字节对齐。但是如果它的对齐是2或4，你如何安排它们的向量，使它们都对齐？如果对齐是一个，那么在不能进行未对齐加载的硬件上会发生什么？硬件往往没有3字节的负载。如果一个字符占用了一个页面的最后三个字节，而下一个页面在被访问时会出现页面错误，那么如何将其放入寄存器？SSE指令使用FWIK内存对齐在一个周期内进行多个数字运算。对字符串没有这样的需求，只需要顺序或随机访问R/W。对齐加载可能会稍微加快一点，我可以看到这样的好处，即标记短字符串（以25%内存的价格）。是的，这是一个原因。宽字符的意义在于，您可以将它们作为单个整数而不是字节字符串来访问。因此，您通常希望能够将单个21位字符代码作为单个原子加载。字符在语义上不是整数，我们对它们的字节处理不同，使用不同的指令。整数可以乘以，这里的大数据类型是合理的。字符是指作为一个字符串进行频繁的顺序操作来访问的。要替换字符，我们只需要固定的宽度，而不是对齐。我知道使用32位寄存器可能需要一个额外的操作来加载24位内存空间。但是对于较长的字符串（通常是复制的），这种微优化的内存通常太多。我接受了你的回答。