摘要

  • RFC 1922 要求含中文的 ISO-2022-CN 行在本行重新声明所用字符集，并在 CRLF 之前以 SI 回到 ASCII；当前行不再依赖更早行遗留的隐藏状态。
  • 转义指定、SI/SO 锁定移位与 SS2/SS3 单字符移位，组成了一套七位字节语法。语法成立不等于邮件送达、字库完备、字形正确或读者理解。
  • charset-edition 与 charset-extension 把版本差异和厂商扩展写进记录。它们让分歧可见，却不能替接收端安装映射表，也不能证明采用情况。

换行承担了恢复责任

状态式编码的效率来自省略：前面已经说过“下面按哪套表解释”，后面的字节便不再重复。但邮件并不总从开头连续显示。读者会滚动窗口，回复会截取几行，网关可能保留后半段，故障也可能只损坏前缀。只要当前行的意义藏在更早的位置，一行完好的字节就可能显示成另一套字符。

1996 年 3 月以 Informational 文档发布的 RFC 1922，把行尾改造成确定性边界。ISO-2022-CN 从 ASCII 状态开始。凡本行出现中文，都要在本行给出所需的字符集指定；换行前必须发出 SI，回到 ASCII。于是下一行拥有共同起点。

这不是为了格式整齐，而是为了缩小错误半径。一个转义序列丢失，不必让后续几十行持续误读；显示程序从任意一行打开，也能用眼前的证据恢复解释状态。额外字节保存了可验证的局部历史。

指定哪张表，与何时使用，是两件事

转义指定负责把某套已登记字符集放入寄存器。SO 进入双字节集，SI 返回 ASCII；同一寄存器后来收到新的指定，旧指定便被替换。因此，只记录“中文模式”远远不够，还要知道是哪套表、何时生效。

SS2 与 SS3 则是一次性借用。它们只让接下来的两个字节按另一套字符集解释，也就是一个中文字符；随后自动恢复原有的 SI/SO 状态。若实现把这次借用误当成长期切换，后续合法字节也会被持续误解。

ISO-2022-CN-EXT 又加入更多已登记字符集与平面。规范也为未来 ISO 指定保留了带占位终结字符的转义形式，但明确禁止在正式分配前使用。语法中预留一个位置，并不等于任何厂商都有权先替全网定义它。

七位安全与八位能力不是同一张收据

ISO-2022-CN 及扩展形式都限制在七位范围内。单就最高位是否会被老式邮件系统清除而言，它们通常不需要 Content-Transfer-Encoding。可这只解决运输中的一个风险：MIME 标签是否正确、状态是否合法、接收端是否支持字符集，仍需分别判断。

CN-GB 与 CN-Big5 是八位形式。若路径仍按七位处理，就应使用 Base64 或 Quoted-Printable；只有在 SMTP 的 8BITMIME 能力已实际协商时，八位内容才有直接传输的依据。把原始八位字节送进七位邮件代理，最高位可能被截掉，结果虽然“送过了”，却无法阅读。

因此要分清三层记录：charset 表明预期解释，传输编码保护表示形式，8BITMIME 说明某一段 SMTP 会话接受八位内容。它们都不能认证作者，不能保证终端字库，也不能证明人眼最终看到了什么。

字符编号也不等于眼前字形

中文字符标准存在不同版本。charset-edition 用年份指出消息依赖的版本。理解该参数的实现可以选对映射；不理解的实现会忽略它，可能按旧版显示少数字符错误。年份约束了解释范围，却没有把正确字形凭空带到终端。

charset-extension 用来标识厂商或本地扩展，可以使用登记值，也可用 x- 私有名。它能解释“为什么这里需要一套额外字表”，但接收端没有那套表时，标签本身不会生成字形。规范也承认扩展会损害互操作性。

Big5 与 CNS 11643 之间的转换同样依赖实现及其映射表。某段字节可以完全符合语法，仍因版本、表格或字体不同而出现另一种形状。编码有时暗示字形传统，却不能据此推断作者身份、国籍或所在地区。

75 列是在为未来的引用留位

转义序列占字节但不占显示列；中文字符通常占两个字节、两个显示列。RFC 1922 要求不要把一个双字节字符拆到两行，并建议正文控制在约 75 列，为回复邮件在行首添加的 > 留出空间。

这个细节说明，互操作不是“文件在实验室里能解码”就结束。邮件会被引用、转发、截取和重新排版。逐行恢复与预留引用边距，都是在为真实软件行为设计，而不是假设信道永远原封不动。

文档能证明设计，不能替运行软件作证

主要依据是 RFC 1922。RFC 1468 与 RFC 1557 提供日文、韩文七位邮件编码的相关背景；RFC 1521 是当时的 MIME 框架，RFC 1652 划定 8BITMIME 的协商边界，RFC 2046 后来进一步整理 MIME 媒体类型规则。RFC 3629 则记录 UTF-8 的后续标准化。

这些材料展示的是演进脉络，不是安装量统计。RFC 1922 建议实现至少能收发 ISO-2022-CN，并尽量接收文中描述的多种编码；它没有证明任何具体产品照做，也没有证明系统后来自动、无损地迁移到 UTF-8。其安全事项明确写的是未作讨论。

运行代码优先 可作为后来的分析纪律：RFC 与登记名称描述协调界面，真正的结果由解析器、邮件中继、映射表和字体共同产生。最小初始规范、本地化未来决策与自愿采用 又提醒我们，确定性的共同核心可以很薄——指定、移位、字节范围与复位；采用哪些字表、何时升级，仍由运行系统决定。不能把这两篇后来的笔记说成 1996 年作者的原意。

RFC 1922 最值得记住的不是某个字符集名称，而是一次克制的状态设计：让每一行在结束时归还控制权，也让下一行不必继承看不见的过去。