摘要

  • RFC 2152 以 + 从直接 ASCII 切入不带 = 填充的 Modified Base64，承载高字节在前的 16 位 Unicode 量；非 Base64 字符结束移位，移位序列绝不能跨行。
  • 该格式故意保留编码选择：Set O 标点可直传也可能遭网关破坏，任意 Unicode 序列又可移位编码。因此解码成功只能证明字符结果，不能证明原 UTF-7 字节、分行、经手路径或作者含义。

设想一批老邮件完成迁移。主题行里的拉丁字母仍清晰，日期与若干标点也没有变成乱码；抽样消息交给 UTF-7 解码器，全部成功。项目经理很容易把这两项事实合并成一句话：“文本完整保存。”

RFC 2152 本身不支持这句结论。它的价值恰在于把一个七位运输难题拆成直接表面与移位状态，而这两部分的证据强度不同。表面可读，可以帮助不认识 Unicode 的系统与人；它不能替代原始邮件对象、逐跳字节哈希或读者端显示记录。

设计对象是七位邮件

David Goldsmith 与 Mark Davis 在 1997 年 5 月发布 RFC 2152，取代 RFC 1642。它是 Informational RFC，不是 Internet Standard。彼时 Unicode 2.0 已覆盖大量书写系统，传统 Internet mail 却仍围绕七位 US-ASCII。若先用 UTF-8，再套 MIME 传输编码，非 ASCII 文本可能经历两次转换并显著膨胀。

UTF-7 的回答是只输出 US-ASCII 八位组。ASCII 较多的消息可以保留直接可读部分，其他字符进入移位序列。RFC 同时给出适用边界：通常只在邮件等七位传输使用；别的环境应优先使用直接 Unicode 或 UTF-8。

旧系统因此获得的是搬运能力，不是多语言理解力。

直接字符并非同一等级

Set D 包含字母、数字和九个特殊字符，允许直接按 ASCII 值发送；+ 与 = 不在其中。Set O 是另一组标点，也可以直接发送，但 RFC 明确警告：其中许多字符在邮件头中非法，或无法正确穿过某些网关。反斜杠与波浪号甚至因为 ASCII 变体常重定义而被排除。

附录的中文示例故意做了两版。第一版使用 Set O，可读性更高，却可能不能穿过某些网关；第二版避开这项风险。这不是脚注式保留意见，而是设计中的选择面：同一字符可以留在纸面，也可以藏入移位编码，两种合法输出面对不同中间设备。

于是，“我能看见这个标点”不能推出“它在每一跳都未被改写”。

加号开启的是状态，不是装饰

+ 告诉解码器，后续 Set B 字符属于 Modified Base64。Set B 沿用 RFC 2045 的 Base64 字母表但去掉 =。遇到非 Set B 字符时移位结束；若结束符是连字符，该连字符被吸收。+- 表示字面加号。加号后若立即出现既非 Set B 又非连字符的字符，序列就是 ill-formed。

移位内部先把 Unicode 16 位量按高字节在前串行化。UTF-16 代理对的两半分别作为 16 位量处理。奇数个解码八位组非法；为对齐 Base64 字符边界而补的尾比特可被丢弃，但它们若非零同样非法。

这些规则让语法可检验，却没有让语法自带来源证明。Hi Mom +Jjo-! 能还原笑脸，说明完整输入可按规则解释；它不说明某个早先编码器是否用了另一种合法表示，也不说明换行、字形或作者看到的版面是否相同。

换行是协议边界

RFC 2152 规定 shifted sequence 在行尾必然终止，绝不能在其中断行，也不能跨行。因此应该先分行再做 UTF-7，或把两者同时完成；编码后仍过长，则应采用合适的 MIME content-transfer encoding。

RFC 还建议邮件使用短行与 SMTP CRLF，并把 Unicode LINE SEPARATOR 与 PARAGRAPH SEPARATOR 转换成 SMTP 换行，以改善旧系统的可读性。对理解 UTF-7 与 MIME 的终端，这一步并非绝对必要；对老系统，可读性会受影响。

这正是“正确迁移”与“逐字节保存”可能分叉的地方。网关统一 CRLF 或转换段落分隔符，可能改善互操作，却改变原始字符或字节。反过来，在移位串中硬折行会直接破坏语法。检查结果必须说清楚自己验证的是哪一层。

解码会压扁历史差异

Rule 2 允许任意 Unicode 序列进入移位编码，Rule 1 与 Rule 3 又允许一部分字符直接表示。多个合法 UTF-7 字节串因此可以得到同一 Unicode 字符串。标准解码器完成任务后，没有义务保留它走过哪条路。

若问题是“应用应该处理哪些字符”，解码结果有意义。若问题是“发件人提交、签名或归档了哪些八位组”，字符结果不够。必须在转换前保存原邮件对象及哈希，再把解码文本作为有来源的派生视图。

行布局和 Set O 也需要独立收据：记录 content-transfer encoding、网关版本、折行策略、解码器版本和错误处理；逐跳比较原始输入与输出；再另行比较解码后的码位。一个绿色的 decode 状态不能覆盖这些差异。

登记名称不是运行结论

IANA 仍登记 UTF-7、MIBenum 1012 与 csUTF7，引用 RFC 2152。它证明名称存在，不证明现代采用率、产品安全或某封邮件被忠实处理。

UTF-7-IMAP 是另一个受限对象。IANA 明示它只用于 IMAP 邮箱名，不应在该环境之外使用；RFC 3501 定义其 modified UTF-7 规则。MIME 正文和 IMAP 邮箱名必须分别取证，不能因名称相似而共用结论。

RFC 2152 的安全章节只说没有讨论安全问题。后来的 Unicode 安全文档说明，不同组件若以不同方式比较或转换文本，可能让前置检查失效；该报告现已稳定化且不再维护，并提示部分建议已有更新。它能限制历史解读，却不能把 1997 年的 RFC 改写成现代安全标准。

RFC Editor 记录两条 verified errata：码位 96 的字符应为重音符，另一个是在“移位序列于行尾结束”的句子中补上漏词。第三条建议被 rejected。证据系统应保留状态，而不是把“3 条”误写成三次有效修订。

Heng Lu 的最小初始规范框架提醒我们，共同层只应承担互操作所需的确定性规则。UTF-7 的移位语法符合这一点；Running-Code Primacy 则要求观察网关实际做了什么；Reality Layers 禁止把 charset=UTF-7 标签或可读片段抬高为已执行的保存结果。

UTF-7 解决的是七位承载。保管问题仍要用原始字节、行边界、解码过程与读者结果分别回答。

来源