UTF-8 直接存储代码点的基本原理是什么？

Question

UTF-8 将代码点的有效位存储在代码单元的低位中

U+0000-U+007F       0xxxxxxx
U+0080-U+07FF       110xxxxx    10xxxxxx
U+0800-U+FFFF       1110xxxx    10xxxxxx    10xxxxxx
U+10000-U+10FFFF    11110xxx    10xxxxxx    10xxxxxx    10xxxxxx

这需要解码器检查over long sequences（例如C0 80而不是00），并且还将可编码的代码点数减少到固定字节数。如果它使用相同的编码但像这样映射代码点

• 前 128 个码位（U+0000—U+007F）：1 个字节
• 接下来的 2048 个代码点（U+0080—U+087F）：2 个字节。例如。 C0 81:U+0081
• 接下来的 65536 个代码点（U+0880—U+1087F）：3 个字节。例如。 E0 B0 B1:U+0881
• 接下来的 131072 个代码点（U+10880—U+10FFFF，直到 U+20880）：4 个字节。例如。 F0 B0 B0 B1:U+10881

（即该值将偏移量编码到范围的开头）

然后可以使用更短的序列对更多字符进行编码。解码可能也更快，因为它只需要一个常数加法，这通常比检查过长代码点的分支成本更低。事实上，如果我们从映射中删除代理对范围，则可以将 2048 个字符压缩到 3 个字节中

那么为什么 UTF-8 以这种方式存储代码点？

Answer 1

基本原理在“餐垫”轶事中得到了充分记录，该轶事讲述了当 Unicode 人员（实际上是 X/Open 的某个人）联系他们进行审查时，肯·汤普森和罗伯·派克如何在餐厅里制定了餐垫规范规范草案。

http://doc.cat-v.org/bell_labs/utf-8_history 包含 Rob Pike 本人的叙述，以及他、Ken Thompson 和 X/Open 人员之间的通信。它把这个愿望称为早期草案中缺失的关键部分之一：

能力 同步一个在运行中拾取的字节流，少于一个 同步前消耗的字符

换句话说，当您查看设置了高位的字节时，您可以仅从该字节值判断您是否处于 UTF-8 序列的中间，如果是，您需要多远快退到多字节编码字符的开头。

完整的故事非常值得一读，所以我将在这里简要总结一下。以下是Wikipedia article's history section.的一段删减版

到 1992 年初，人们开始寻找对多字节字符集进行良好字节流编码的方法。 ISO 10646 标准草案包含一个名为 UTF-1 的非必需附件，该附件提供了其 32 位代码点的字节流编码。这种编码在性能方面并不令人满意，除其他问题外，最大的问题可能是它没有明确区分 ASCII 和非 ASCII ...

1992 年 7 月，X/Open 委员会 XoJIG 正在寻找更好的编码。 Unix System Laboratories 的 Dave Prosser 提交了一个具有更快实现特性的提案，并介绍了 7 位 ASCII 字符仅代表自己的改进；所有多字节序列将仅包括设置了高位的字节。 ...

1992 年 8 月，IBM X/Open 代表将该提案分发给了相关方。贝尔实验室 Plan 9 操作系统组的 Ken Thompson 进行了修改，使其位效率低于之前的提议，但至关重要的是，它可以自我同步，让阅读器从任何地方开始并立即检测字节序列边界。它还放弃了使用偏差，而是添加了只允许最短编码的规则；紧凑性的额外损失相对微不足道，但读者现在必须注意无效编码以避免可靠性，尤其是安全问题。汤普森的设计于 1992 年 9 月 2 日在新泽西州餐厅的餐垫上与 Rob Pike 勾勒出来。在接下来的几天里，Pike 和 Thompson 实施了它并更新了 Plan 9 以在整个过程中使用它，然后将他们的成功传达给 X/Open，X/Open 接受了它作为 FSS-UTF 的规范。