摘要

  • 1995 年 8 月的 RFC 1843介绍 HZ：用七位数据混排 ASCII 与 GB2312 中文。~{ 进入 GB 模式，~} 回到 ASCII，~~ 才是正文里的一根波浪线。
  • 基础解码器按连续字节流工作，没有行长限制。RFC 另建议编码器为 more 一类终端工具把物理行控制在 80 字符以内；折行时先退出 GB 模式，再用被解码器吞掉的波浪线加换行继续正文。

同一字节，先问它站在哪边

一封混排中英文的邮件，今天看起来只是打字问题。Fung Fung Lee 写下 HZ 格式时，麻烦藏在传输和机器里：许多系统的邮件通道偏爱七位 ASCII，能处理中文的电脑又使用不同的八位内部编码。HZ 选择 GB2312 作交换时的中文字集，让普通 ASCII 保持可读，再用少数转义记号告诉接收方何时按中文解释字节。RFC 在 1995 年发表；摘要说明其内容与作者 1989 年 9 月的一篇同题文章相同。这里的年份标记的是 RFC 的归档时间，办法本身更早。

HZ 只有两种模式。初始是 ASCII：一般字符照原样读，遇到波浪线则要看它后面跟着什么。~~ 还原成一根真的 ~；~{ 打开 GB 模式；波浪线后面紧接换行，则表示物理行在此续接，解码后不产生字符。进入 GB 后，接收方一次取两个字节，直到 ~} 让它回到 ASCII。字节没有自带语言标签；决定如何分组的是读到它时所处的模式。

这根波浪线为何合适，RFC 给出了字节范围。GB 双字节码的第一字节在十六进制 $21 至 $77，第二字节在 $21 至 $7E；可打印 ASCII 与它们重叠。若没有模式，同一个值会有两种读法。而波浪线的 $7E 超出 GB 第一字节的规定范围，能作为显眼的开关出现。一个平时松松垮垮的标点，在这里当上了值班员。

英语片段也因此保留了原貌。除了需要写成 ~~ 的波浪线，其余普通 ASCII 不必绕进双字节形式。全是 ASCII、且没有波浪线的 HZ 文件，看起来就是普通 ASCII 文件。中文可以夹在一句英语中间，之后再切回来。格式的目标是任意混排，让两种文字走同一条七位通道，而不是把整篇文章统一转成某种难辨的代码块。

行尾另有一层小机关。~ 后接 LF 是续行标记，解码时被吞掉；发送者可以把物理文件中的长行折短，却让读者看到连续文本。RFC 明说基础解码器无需依赖“行”的概念。文件可以只有一条极长的行，甚至完全没有换行。解码器需要记住当前模式，再向前最多看一个字符。共同规则处理的是字节流，纸面上的行长是另一件事。

但读文件的人还要面对终端。为了让 Unix 的 more 等逐页工具好用，RFC 建议编码器把物理行压在 80 字符以内。如果 GB 片段正好跨行，写入方可以先用 ~} 关上 GB 模式，加一段被吞掉的 ~ 加换行，再在下一行用 ~{ 重新打开。文件多了几个字节，解出的正文却接得严丝合缝。RFC 把这叫编码“风格”，明确放在基础格式之上。文中的不同写法，最终能还原成同一段文字。

这就给 HZ 留下了弹性。基础读者不用知道发信人的终端宽度，也不用为了某个寻常的翻页程序增加新规则。写文件的一侧，可以照自己的显示条件折行；另一侧照通用语法读流。Lee 还提到，在已知当前模式的条件下，解码器也容易向后扫描，终端模拟器处理退格会用到这一点。这个格式考虑的是日常查看和编辑，不只是一封邮件抵达后的静态保存。

1996 年的 RFC 1922则采用 ISO-2022-CN 的另一套逐行指定与移位办法。HZ 的看点在两态波浪线语法，以及把可选的行宽安排放在编码器一侧。它让中文穿过七位窄门，也让英语继续以原样站在门口。基础规则只管开门和关门，排队的队形由现场自己安排。