摘要

  • RFC 1345 为字符分配由少量通用符号组成的助记名，让传输字符集容不下的字符仍能被标记、传送并还原。
  • 当引导序列设为 0，助记名的起始标记和长名称两侧的下划线会消失。规范明确指出：文字更易读，但信息丢失，转换不再可逆。

假设一封邮件要穿过只能识别少数字符的线路。收件人的名字里有一个线路不会传的字。把它换成相似的字母很容易，事后要证明原来写的是什么就难了。Keld Simonsen 在 1992 年 6 月的 RFC 1345 中提出另一种做法：给字符起可用通用符号拼出的助记名。即使屏幕画不出原字，记录里也可以保留它的身份。

关键不只是名字，还在名字的边界。若一对普通字母既可能是原文，也可能代表另一字符，接收者便无法判断该怎么解码。规范建议用十进制值 38，也就是 ASCII 的 &，作为引导序列。原文真要写这个符号，就把引导序列重复一次。超过两个字符的助记名还要用下划线围起来。这些标记看着啰嗦，却是往返还原的路标。

助记名取材于 ISO 646 各版本共享的 83 个图形字符。两个字符的写法主要面向拉丁、希腊、西里尔、希伯来和阿拉伯等字母文字；日文、中文等非字母文字更多使用变长名称。发送端、传输线路与显示终端可以拥有不同的字符能力，只要边界仍在，接收端就有办法识别被替换的字符。

随后，规范给了一个诱人的开关。第 4.3.2 节允许把引导序列设为 0。这时引导符不再传送，长助记名两边的下划线也被去掉。肉眼读一行文字会轻松些；未来的解码器却分不清哪段字母是原文，哪段是助记替代。RFC 直接写明这会失去可逆性并造成信息损失，还给出等式：mnemonic+ascii+0 等同普通 ascii。

这不是邮件中途遭到意外破坏，而是格式主动提供的取舍。带标记的版本可能刺眼，却留住了字符身份；零引导的版本顺眼，却把某些区分抹平。档案若只保存后者，之后再给它加上漂亮的字符集标签，也补不回那些从未传送的边界。

这份 RFC 对中文字符还踩了刹车。对于源于中文、日文或韩文使用环境的汉字，它不建议使用助记写法：预期接收设备往往能处理原编码，而长助记名会变得难读。表格上能为一个字编出名字，不代表读者就该用那个名字阅读它。所谓通用手段，必须接受实际语言和设备能力的检验。

RFC 1345 是信息性文件。它留下的不是“所有人都该改用助记名”的命令，而是一张清楚的价目表：多留几个标记，保住往返；少几个标记，换来眼前的整洁。一旦选择了零，后来的人无法靠猜把原件完整找回来。

资料：RFC 1345《Character Mnemonics & Character Sets》第 2 节及第 4.3 节；RFC Editor 文档页。