摘要

  • RFC 2277 要求进入 IETF 标准流程的协议区分协议元素与人类文本，为字符数据标明 charset，能够使用 UTF-8，并提供携带语言信息的明确方式。
  • 这些要求形成规范审查的设计收据；它们不证明接收端具备能力、协商结果被采用、locale 合适、字符正确呈现或用户真正理解。

RFC 2277 不是另一种编码格式。它于 1998 年 1 月作为 BCP 18 发布，说明 IESG 对进入 IETF 标准流程的协议规范所执行的政策。同期 IESG 公告把门槛说得很清楚：人类可读文本必须能够使用 UTF-8，也必须能够携带语言标签；不能满足时，需要走 variance 程序并给出充分理由。

政策约束的是规范文本。工作组不能再把国际化当作实现者日后自行填补的空白。看起来像文字的元素，必须说明究竟是机器解析的协议令牌，还是给人阅读的文本。若把责任交给另一层，还要确认那一层确实知道自己承担了什么。名称也要明确说明是国际化名称还是 US-ASCII 名称。

这张审查清单提高了可追责性，却没有观察任何真实接收端。RFC 2277 所说的 charset，是把 octet 序列映射成字符序列的一组规则。标签告诉接收者应尝试哪条解码规则；它不会检查实际字节是否合法，不会替旧软件安装 UTF-8 支持，也不会补齐字体和版面能力。

“必须能够使用 UTF-8”同样不是“所有环境已经使用 UTF-8”。RFC 允许既有协议和存量数据继续需要其他默认字符集，只要求 UTF-8 路径必须可能存在，其他字符集则应采用登记名称。这个安排是在共同方向与兼容现实之间划界，而不是发布一张全球迁移完成证书。

交互式协议与存储文本的证据也不同。HTTP 一类往返交互可以协商 charset；电子邮件和归档数据往往无法与未来接收者实时沟通，只能把清楚的声明附在数据旁。协商记录了提议与选择，存储标签记录了发送方主张。两者都不自动证明接收端真正采用了选择，也不证明最终画面可读。

语言信息解决的是另一层问题。RFC 2277 要求协议提供携带语言信息的方式，却没有要求每段文本都必须带标签。当时它推荐 RFC 1766，同时明确语言不等于 POSIX locale。locale 还可能涉及排序、日期、货币等文化规则，接收者可以接受，也可以忽略发送者对这些规则的意见。

因此，zh 只是一项语言信息，不是“这位读者看得懂”的证明。RFC 2068 的 Accept-Language 表达偏好，但它也提醒：可懂性依赖具体用户，标签前缀匹配并不意味着用户理解所有更具体的语言变体。RFC 1766 甚至明确说，语言标签无法在所有情况下正确决定字符集的呈现方式，日中混排就是典型边界。

RFC 2277 建议把这些决定集中写入紧邻 Security Considerations 的 “Internationalization Considerations”。这是一项很有力量的治理设计：审查者可以在一个位置检查文本在哪里、字符集如何选择、语言如何携带、协商怎样发生、责任留在哪一层。但这仍只是设计决定的收据，不是实现通过、翻译一致或用户行为正确的收据。

文档自己的安全讨论正好说明了这道边界：外语警告可能促使用户采取不当行为，多语言版本也常有一致性问题。字节、字符和标签都正确，并不能替代用词、语境、无障碍呈现与人的判断。

RFC 2277 的历史贡献，是让标准制定者不能隐去这些选择。它没有承诺选择一经写下，后续每一环就会自动成功。声明、能力、协商、解码、呈现和理解，仍然是六张不同的收据。

来源与证据限度

下列一手资料支持 1998 年政策、工作坊来源、同期语言标签、MIME/HTTP 机制和 UTF-8 规范演进；它们不提供当前采用率、具体产品表现、一次真实会话或用户理解的证据。