这两个问题问到了UTF-8设计里最核心的取舍逻辑，咱们从设计目标和技术特性两个维度拆解清楚：

一、UTF-8选择当前存储方式的核心原因 #

UTF-8能成为全球最通用的文本编码，不是因为它的编码效率最高，而是它解决了ASCII兼容和鲁棒性这两个当年最棘手的问题：

1. 严格向后兼容ASCII生态 #

当年设计UTF-8的首要目标，是让现存的所有ASCII工具（比如C语言里依赖\0终止的字符串处理函数、古老的文本编辑器、网络协议）不需要任何修改就能处理UTF-8文本。

• 当前规则里，U+0000-U+007F完全和ASCII字节一一对应，而且多字节序列的首字节永远不会落在0x00-0x7F范围内，续字节也不会是ASCII字符。这意味着传统工具处理UTF-8里的ASCII部分时，和处理纯ASCII文本完全一样——包括U+0000这个空字符，这是你提到的替代方案做不到的（替代方案没法在空终止字符串里存U+0000）。
• 这个兼容性是UTF-8能快速普及的关键，如果当年选了你的替代方案，大量现有系统要做改造，推广难度会指数级上升。

2. 强自同步的鲁棒性 #

当前编码规则给每个字节都加了明确的“身份标记”：

• 0xxxxxxx：单字节ASCII字符
• 110xxxxx：双字节序列的首字节
• 1110xxxx：三字节首字节
• 11110xxx：四字节首字节
• 10xxxxxx：只能是多字节序列的续字节
  这种设计让解码器在遇到损坏的字节（比如传输丢包、文件损坏）时，能立刻定位到下一个合法序列的开头，不会把错误扩散。比如如果某个续字节丢了，解码器看到下一个字节是110xxxxx，就知道这是新的双字节序列起点，不会把它当成上一个序列的续字节来解析。
  而你说的替代方案，续字节的判断逻辑依赖前面的字节，容错性差很多，一旦出错可能导致后续整个文本解析混乱。

3. 唯一编码，无冗余 #

UTF-8规定每个码点只有唯一的编码方式，绝对不允许用更长的序列编码本可以用短序列表示的字符（比如你提到的C0 80替代00这种情况）。

• 这种唯一性避免了字符串比较、哈希计算等场景的歧义：比如同一个字符如果有两种编码，会导致“看起来一样的字符串”哈希值不同，或者比较结果不相等。
• 同时也简化了解码逻辑，从设计上就杜绝了冗余编码的可能，解码器只需要按规则解析即可。

二、双字节编码范围为何是U+0080-U+07FF而非U+0080-U+087F？ #

这个问题其实是上面设计逻辑的延伸：

• 双字节序列的结构是110xxxxx 10xxxxxx，首字节提供5个有效位，续字节提供6个，总共是5+6=11位有效位。U+0080是二进制10000000（第8位开始），U+07FF是二进制11111111111（11位全1），刚好把11位有效位的所有可能值填满。
• 如果要扩展到U+087F，那需要12位有效位，这意味着要么修改双字节的结构（比如首字节改成111xxxxx，但这样就和三字节首字节冲突了），要么允许冗余编码（比如用双字节编码本来需要三字节的码点），这都会破坏UTF-8的自同步和唯一编码原则。
• 另外，当年设计UTF-8的时候，Unicode还只是16位的（U+0000-U+FFFF），把双字节对应11位范围，三字节对应16位范围，刚好完美覆盖整个Unicode空间，解码器实现起来非常直接。

最后补充一下 #

你提到的替代方案在编码效率上确实有优势，但它牺牲了UTF-8最核心的两个特性：完全兼容ASCII生态和强自同步能力。当年UTF-8的设计者Ken Thompson和Rob Pike在做取舍时，把“让现有系统平滑过渡到Unicode”放在了第一位——毕竟，一个编码再高效，如果没人愿意用，也没意义。

内容的提问来源于stack exchange，提问作者phuclv