UTF-8000：无限 UTF-8

原文 ↗ Hacker News 讨论 ↗

一个名为 UTF-8000 的提案将 UTF-8 扩展为可编码任意大的整数，同时保持与现有 UTF-8 文本的向后兼容，从而把今日 21 位 Unicode 范围之外的码点推进到“无限”的程度。评论者争论这额外空间是否有用——有人设想更丰富的表情符号、私用字形或 LLM token 方案；也有人认为这不过是无必要的复杂性，因为 Unicode 当前的大部分空间仍未使用，而工具链又深度绑定于已标准化的 UTF‑16/UTF‑8。该讨论还回顾了围绕编码的长期问题，例如自同步、BOM、遗留代码页、CJK 效率，以及新格式在面对不安全或遗留环境约束时应当在多大程度上予以照顾。

UTF-8000 的总体看法

  • 被视为对 UTF-8 的一个聪明、有趣的扩展：它允许任意大的码点，同时对当前 Unicode 仍与现有 UTF-8 保持字节兼容。
  • 一些人将其描述为一种优雅的巧妙变通，或原始（2003 年之前的）UTF-8 的自然延伸；那时 UTF-8 曾允许 5–6 字节序列。
  • 也有人认为它没有必要，因为 Unicode 还有大量未使用空间，而且历史上为了与 UTF‑16 兼容所施加的限制已经够用了。

有用性 vs. 复杂性

  • 持怀疑态度的人把它比作过度设计（“IPv6 → IPv50”、“给编码迷准备的 TIME CUBE”），并认为我们永远不需要那么多字符；Unicode 是一个有限的目录，而不是通用数据容器。
  • 一封被引用的来自 UTF‑8 联合作者的信称，7–8 字节扩展“没有用”，并指出 8 字节形式必须扫描整个序列才能知道其长度。
  • 也有人担心任意长度码点会使缓冲区管理更复杂并带来拒绝服务风险，不过其他人反驳说现代的内存安全方法可以处理这些问题。

性质与权衡

  • 讨论了自同步性：有人认为 UTF‑8000 保留了“从任意字节重新同步”的性质，但它很可能破坏一些有用的同态性质（例如对字节序列进行简单子串搜索）。
  • 有些人强调，即使是当前 Unicode 也已经允许任意长的字素簇，所以固定宽度的“字符”本来就是幻象。
  • 另一些人赞赏 UTF‑8 的设计：ASCII 兼容、自同步，以及能够在原始字节上执行许多操作。

与其他编码 / 用途的关系

  • 历史背景：UTF‑8 的范围曾从 31 位缩减到 21 位以匹配 UTF‑16，部分人认为这是个错误，把一个过小的上限给固定下来了。
  • 还展开了关于 BOM、UTF‑16、遗留编码的长篇讨论，以及希望世界更早统一到 UTF‑8 的愿望。
  • 也有人建议，如果我们真的超出了 Unicode 的容量，也许新的序列化模型，或者对 Unicode 进行一种不自同步的“重新嵌入”，会比不断扩展 UTF‑8 更好。

“我们能用这些空间做什么？”

  • 一些有趣的想法：完全可定制的表情符号、在单个码点中编码图像或脚本、“把 Unicode 当作字符”，甚至用于嵌入向量或 LLM token。
  • 也有人指出，私用区和字素簇已经可以支持许多自定义方案，因此 UTF‑8000 的额外空间可能更多是理论上的，而非实用上的。