摘要

  • 1993 年 12 月的 RFC 1557 为韩文纯文本邮件正文使用 ISO-2022-KR：从 ASCII 起步，以 ESC $ ) C 指定 KSC 5601，SO 进入双字节字符，SI 返回 ASCII。
  • 邮件头中的韩文走另一条路：先以 EUC-KR 表示，再装进 RFC 1522 的 B 或 Q 编码词。标题正常显示，不能替正文的解码器签收。

标题与正文各拿一张号码牌

想象一封通知：标题写着会议改期，正文写着新的时间。标题显示正常，时间却成了一串控制符和乱码。反过来的故障也成立。邮件并没有被拆成两封；它只是把同一种人类语言交给了两个不同的机器规则。

这条边界在邮件格式里早已存在。RFC 822把发件人、收件人、主题等结构化字段放在上方，空行之后才是正文。邮件头里的标点与折行带有语法意义，中继程序还可能重新排列地址或折叠长行。正文则是一段相对连续的文本。要在两处都放入韩文，直接套同一条字节流规则，会让至少一处出问题。

U. Choi、K. Chon 和 H. Park 在 RFC 1557里记录了解法。作者说，这种方法于 1991 年确定，到 1993 年已经在韩国 IP 网络广泛使用。文件讨论的是纯文本消息，最有意思的地方是它毫不掩饰分工：正文靠七位字节和状态切换；邮件头靠另一种字符表示与 ASCII 外壳。

先看正文。它从 ASCII 状态开始。ESC $ ) C 指定 KSC 5601 字符集，SO 让随后的字节两两成组解释为韩文字符，SI 再切回 ASCII。KSC 5601 包含谚文、汉字和其他字符。字节本身像站台上的旅客；最后一次状态切换决定它要上哪列车。正文的 MIME 字符集名称是 ISO-2022-KR。

这里有一处值得慢读的档案细节。RFC 的说明文字谈到在含韩文行的开头、SO 之前放置指定序列；形式语法则允许一个指定序列之后接续多行。作者明说两处有冲突时以形式语法为准。检查旧邮件时，应沿原始字节寻找真正的指定位置和 SO、SI 顺序。把其他编码的“每行重申”习惯生搬过来，会误判这份材料。

正文采用七位表示。RFC 因此说，按这一点来看，它无需额外的 Content-Transfer-Encoding 头。作者还记录了当时的韩文邮件软件没有支持在已经这样编码的正文上再套 Base64 或 Quoted-Printable。那是 1993 年工具的具体状况。ISO-2022-KR 标签告诉接收端该用什么状态机读正文，不能拿去读取邮件头。

标题的手续另起一行。RFC 1557 要求先用 EUC-KR 表示邮件头中的韩文，再按 RFC 1522 把它包装为 B 或 Q 编码词。外壳写成 =?charset?encoding?encoded-text?=，全部是旧式邮件头易于承受的可打印 ASCII。懂这套格式的阅读器拆开外壳，按里面的字符集还原韩文。于是同一封信的上方写 EUC-KR，下方写 ISO-2022-KR。标题和正文共用的只是读者的眼睛。

这种安排把技术分歧藏得很体面。用户只看见一封流畅的信；邮件头处理器和正文处理器各自完成工作。等其中一处显示错误，接缝才露出来。RFC 1557 的历史价值正是在这里：它把一封信内部的两道边境检查画成了可追踪的字节路线。