摘要

  • RFC 2130 的七层模型把线路上的编码字符集、字符编码方案、传输编码语法，与面向人的语言、地区习惯、文化和排版分开。解出了字符，只证明了证据链的一段。
  • 报告推荐可注册的 MIME 标记及新协议的 ISO 10646、UTF-8 默认值，同时保留旧协议的协商、回退和其他必要字符集。它是资讯性指导，不是新线路协议或全球普及的记录。

同一段对话里的两种文字

假设邮件服务器拒绝了一次操作。MAIL FROM 是机器要解析的指令；解释拒绝原因的句子则交给人阅读。把两者统统称为“文本”，就容易以为把指令翻成另一种语言也算国际化。RFC 2130 正是用这个例子说明：协议机器的令牌不应轻易改变，面向人的错误消息则可以在有明确扩展时使用合适语言和字符集。前者牵涉已运行解析器的兼容性，后者牵涉接收者能否读懂。

IAB 召集的工作坊于 1996 年 2 月 29 日至 3 月 1 日举行，报告于次年 4 月发表，类别为 Informational。它既不是一项新的 Internet Standard，也没有统计多语言软件已部署多少。其任务是给邮件、名录、网页等不同应用一个共同的提问方法：当人说“字符集”，究竟指字符编号、字节表示、传输包装，还是最后的呈现？

能过线，不等于能阅读

模型的前三层负责线路。CCS 把抽象字符映射为整数；CES 把这些值编码成 octet；TES 根据传输限制再变换编码数据。ISO 10646、UTF-8 和 Base64 分别可以说明这三种角色。倘若把它们混为一谈，排查乱码时就无法判定错误发生在字符选择、字节编码还是七位通道所需的包装。

后四层转向人：语言、决定日期和货币等呈现方式的 locale、影响拼写与措辞的文化、以及字形和换行等排版。报告主要讨论线路三层，对许多界面问题明确保留边界；但它也承认语言标签有时影响汉字字形选择和多语言文档检索。一个完全合法的 UTF-8 字节串，仍不能凭自身告诉浏览器该用哪种语言的字形、读者习惯哪种日期格式，也不能保证解释被理解。

标签是让这些选择可追问的工具。在 MIME 中，Content-Type 的 charset 可同时覆盖 CCS 和 CES，Content-Transfer-Encoding 另指传输变换。报告没有假装既有注册项天然符合它的新模型，而是建议后续注册澄清各层。它列出标准固定、信封携带、流内标记、事先约定、交互协商等辨认办法；只凭发件地猜编码并不可靠。因此推荐在没有可靠既有机制时采用 MIME 注册值来标记字符集和语言。标记须与实际发送的字节相符，单有标签并不会修复错误内容。

名称的公开程度决定风险

工作坊将旧协议问题分为机器、标识符和数据。RFC 1958 对广泛可见公共名称提出不区分大小写的 ASCII 建议，包括 DNS 名称和以文本传输的协议元素；本地邮箱文件夹名不必机械套用同一约束。已有 ASCII 协议若改用 UTF-8，应协商协议版本或字符集，并提供兼容回退，而不是悄悄重新解释老字节。邮件正文、数据库和 HTML 页面等数据需要能够处理多个字符集及应用上下文。

这也限定了“默认 UTF-8”的含义。报告建议新文本协议优先采用 ISO 10646 的字符集合及 UTF-8 的字节方案，但旧协议可因兼容性保留原默认；七位通道还可能需要额外的传输转换。它没有设定通用 TES，也没有废除其他字符集。默认值可以减少新设计的协调成本，却不能替代旧端的协商或证明世界已经同时会读所有文字。

RFC 2044 聚焦 UTF-8 字节形式，RFC 2066 给 Telnet CHARSET 明确协商过程，RFC 2070 规定 HTML 外部字节如何解为文档字符，RFC 2152 处理七位邮件中的 Unicode。它们各自解决一环，不能代替本篇关于跨协议边界的判断。

来源与不能推出的结论

Lu Heng 关于运行代码与现实证据的笔记在这里是后见的编辑分析镜头，不是工作坊作者意图的史料。报告给出建议和未决问题，没有给出某个服务的部署率、显示质量或用户理解程度。