摘要

  • RFC 1502 说明，X.400 GeneralText 能列出所用字符集，但每个字节的含义还取决于正文中 ISO 2022 的指定和切换状态。
  • 收件程序遇到设备无法呈现的字符，必须把缺口显示出来；不能把本地字符集同一比特位置的字形冒充原字。发件建议不能替代对实际字节流的解析。

空格子会让人停下来。假字却可能被顺手读进一句话。Harald Alvestrand 在 1993 年 8 月处理的正是后一种风险：X.400 邮件早已能携带多种字符集，收件端却可能在最后一步把正确送达的内容显示错。

GeneralText 的信封和正文参数可以列出用到的字符集。正文内部另有 ISO 2022 转义和换挡序列，决定某个位置到底启用了哪一套字形。起始状态默认 IA5 位于 G0、标准控制集位于 C0；若要从别的状态起步，就得先发出相应的声明。字符集清单告诉接收端有哪些可能性，逐字节解释还得沿着正文追踪状态变化。

这份 RFC 给发件方提供一套整齐的做法：尽量让 US-ASCII 固定在 G0，合适时把 ISO 8859 字符集放进 G1。这样 ASCII 字节始终保持熟悉的表示。可它紧接着提醒收件方，不可假定发件人真的照办。网关、旧软件和不同语言传统会带来形形色色的实际邮件，阅读程序必须按收到的状态读。

第四节把显示责任说得更硬：能够处理 GeneralText 的程序应识别 IA5 和本地字符集，无论它们如何被指定；遇到输出设备画不出的字符，要明确标出；遇到未知或无法呈现的字符集，绝不能照同一比特位置从本地字符集中捞个字形放上屏幕。两个字符共享一个数字位置，不代表它们共享一个意思。

RFC 还希望程序提供两种观看方式：一种使用替代表示，另一种明确标记无法呈现的字符；并保存携带字符集信息的原文，供日后重新处理。这些要求也适用于把 GeneralText 转为 MIME 等格式的网关。读者眼前的便利版本，与能够复核原意的档案，是两笔不同的账。

转换环节还有一条硬边界。若目标字符集容不下某个字，正文列出替代控制符、需另行说明的助记形式、供人理解的退化写法，或干脆拒绝转换。若邮件禁止有损转换，只剩拒绝这一条路。RFC Editor 当前记录把 RFC 1502 列为 Historic；1993 年原文则写着当时的标准轨道身份。文档没有列出哪个具体客户端照办。它留下的判断却很鲜明：屏幕本领不足时，把不足交代给读者，别替写信人造字。