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

[基本原理在“ placemat”轶事中有据可查，其中讲述了Ken Thompson和Rob Pike如何在Unicode专家（实际上是X / Open的某人）与他们联系以审查餐厅时，如何在餐馆中提高了餐垫的规格。规范草案。

http://doc.cat-v.org/bell_labs/utf-8_history包含罗伯·派克本人的叙述，他，肯·汤普森和X / Open人之间有通信。它称呼此愿望为早期草案中缺少的关键部分之一：

同步中途采集的字节流，且少于一个同步之前消耗的字符

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

全文值得一读，所以我在这里仅作简要总结。以下是Wikipedia article's history section.

部分的简化版本

到1992年初，人们一直在寻求对多字节字符集进行良好的字节流编码。 ISO 10646标准草案包含一个不需要的附件，称为UTF-1，该附件提供了其32位代码点的字节流编码。这种编码在性能方面还不能令人满意，其中最大的问题可能是最大的问题是它在ASCII和非ASCII之间没有清晰的分隔...

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

1992年8月，该建议由IBM X / Open代表分发给有关各方。 Bell Labs的Plan 9操作系统小组的Ken Thompson进行的修改使它的位效率比以前的建议要低一些，但至关重要的是，它可以自我同步，使阅读器可以从任何地方启动并立即检测字节序列边界。它还放弃了使用偏差，而是增加了规则，即只允许最短的编码。紧凑性带来的额外损失相对较小，但是读者现在必须注意无效编码，以避免可靠性，尤其是安全性问题。汤普森（Thompson）的设计于1992年9月2日在罗宾·派克（Rob Pike）的新泽西小餐馆的餐垫上进行了概述。在接下来的几天里，Pike和Thompson实施了它并更新了Plan 9以在整个过程中使用它，然后将其成功传达给X / Open，后者将其接受为FSS-UTF的规范。