为什么需要在 UTF-8 中标记连续字节？答案

【问题标题】：Why is it necessary to mark continuation bytes in UTF-8?为什么需要在 UTF-8 中标记连续字节？
【发布时间】：2016-12-20 00:12:00
【问题描述】：

我最近一直在阅读 UTF-8 可变宽度编码，我发现奇怪的是 UTF-8 将每个连续字节的前两位指定为 10。

 Range           |  Encoding
-----------------+-----------------
     0 - 7f      |  0xxxxxx
    80 - 7ff     |  110xxxx 10xxxxxx
   800 - ffff    |  1110xxx 10xxxxxx 10xxxxxx
 10000 - 10ffff  |  11110xx 10xxxxxx 10xxxxxx 10xxxxxx

我在尝试其他可能的可变宽度编码，发现通过使用以下方案，最多需要 3 个字节来存储所有 Unicode。如果第一位为 1，则字符至少再编码一个字节（读取直到第一位为 0）。

 Range           |  Encoding
-----------------+-----------------
     0 - 7f      |  0xxxxxx
    80 - 407f    |  1xxxxxx 0xxxxxxx
  4080 - 20407f  |  1xxxxxx 1xxxxxxx 0xxxxxxx

UTF-8 中的连续位真的那么重要吗？第二种编码似乎更有效。

【问题讨论】：

UTF-8 方案允许您从任何代码单元位置恢复预期的解码。
即使使用我的编码，这也是可能的。从任意位置向后退一步，直到找到一个结束字节（带 0），然后下一个字节是字符的开头。
并非如此：如果您指向 0xxxxxx 字节，我无法判断这是一个完整的字符还是多字节序列的损坏结尾。（假设我不能倒退。）

标签： unicode utf-8 character-encoding utf

【解决方案1】：

UTF-8 是自我验证的，前进速度快，后退更容易。

自我验证： 由于序列中的第一个字节指定了长度，接下来的 X 个字节必须适合 10xxxxxx，否则您的序列无效。看到 10xxxxxx 字节本身会立即被识别为无效。
您建议的编码没有内置验证。

快进一步：如果您必须跳过字符，您可以立即跳过由第一个字节确定的 X 个字节，而无需检查每个中间字节。

更容易后退：如果您必须向后读取字节，您可以立即通过10xxxxxx 识别连续字符。然后，您可以向后扫描 10xxxxxx 字节后的 11xxxxxx 前导字节，而无需扫描前导字节。

参见维基百科上的UTF-8 Invalid sequences and error handling。

【讨论】：

【解决方案2】：

使用您提出的方案，如果您查看编码为 0xxxxxxx 的字节，您无法判断它是单字节单元 0x00..0x7F 还是多字节单元的最后一个字节。您必须向后扫描并查看前面的字节才能知道（并且您必须向后检查两个单元以查看它是否是 2 或 3 字节代码点的最后一个字节）。如果你有一个 1xxxxxxx 字节，你无法分辨它是多字节单元的第一个字节还是中间字节。同样，您必须向后扫描。

相比之下，UTF-8 方案允许您告诉任何非连续字节有多少后续字节是代码点的一部分。对于连续字节，您只需向后扫描到起始字节。您还将获得错误检查； UTF-8 中有许多无效序列，这实际上是一个好处。（字节 0xC0、0xC1、0xF5..0xFF 不能出现在有效的 UTF-8 中。）

【讨论】：

【解决方案3】：

除了前面提到的易于迭代之外：UTF-8 旨在确保基于 ASCII（以及其他不支持 UTF-8）的工具通过搜索、连接、替换和转义等常见操作进行处理。

ASCII 兼容性对于互操作性和安全性的优势超过了为字符 U+0800 到 U+407F 使用额外字节的成本。

80 - 407f | 1xxxxxx 0xxxxxxx

所以有一些东亚多字节编码就是这样做的，而 UTF-8 专门试图避免一些不幸的结果。

在这个提议的方案中，连续字节现在与 ASCII 重叠，并且许多 ASCII 字符对不同的语言和工具具有特殊的含义。因此，如果您想说¢ 是 0x80,0x27 并且对于任何在不支持和知道该数据使用建议的编码的情况下操作字节字符串的工具来说，它的第二个字节看起来像 "。

提示所有将用户输入结合到控制流中的安全漏洞。查询中的 SQL 注入、网页中的 HTML 注入、shell 脚本中的命令注入等等。

（东亚多字节编码并不像这里的这种编码那么糟糕，因为它们没有将 ASCII 控制码作为连续字节重用。正如建议的那样，使用这种编码的文本不能存储在 C null - 终止字符串，例如。不过，Shift-JIS 和朋友造成了一大堆安全漏洞，我们都很高兴摆脱它们。）

【讨论】：