摘要

  • RFC 1489 为已被前苏联地区大型 Unix 与网络用户群采用的字符编码登记了 MIME 名称 koi8-r；登记没有把它变成互联网标准或国际标准。
  • 按公布的映射表计算，核心俄文字母字节若被清除第七位，会投影成大小写颠倒的近似拉丁字母。这是映射结构的可复现实验结果，并非 RFC 对某次历史传输的记载。
  • 可读投影不能唯一还原原始字节，也不能在 ASCII 与俄文混排时可靠区分原生 ASCII 和受损西里尔文，更不能证明字符集声明、内容真实性或读者当时所见。

“看得懂”最容易被误写成“恢复了”

设想旧邮件库中出现一行 rUSSKIJ TEKST。它显然不自然，却不完全陌生。懂俄语的人可能立刻联想到“Русский текст”，也就是“俄文文本”。在一次迁移验收会上，这种人类识别能力很容易被压缩成一个绿色状态：恢复成功。

但存档中现存的仍是 ASCII 字节。它们可能来自 KOI8-R 字节被清除最高位，也可能从一开始就是 ASCII。读者给出了一个合理解释，系统却没有找回已经消失的二进制区别。

这不是传说，而是可以从 RFC 1489 的表格直接复现。把“Русский текст”编码为 KOI8-R，可得 F2 D5 D3 D3 CB C9 CA 20 D4 C5 CB D3 D4。将每个高位字节的第七位清零，输出就是 rUSSKIJ TEKST。

实验只证明两串字节之间存在这种变换关系。它不证明眼前任何一串 ASCII 必然经历过这条路径。工程上最关键的边界，恰恰位于“能构造解释”和“有证据证明历史”之间。

先有运行共同体，后有登记名称

RFC Editor 的记录显示，这份备忘录发表于 1993 年 7 月，现归入 Legacy 流，类别为 Informational，作者是 RELCOM Development Team 的 Andrew A. Chernov。文件开篇对自身权威范围说得很坦率。

KOI8-R 不是国际标准，底层规范没有公开发表。它借鉴了 GOST 19768-74、ISO 6937/8、INIS-Cyrillic 和 ISO 5427 等已发表材料。与此同时，包括 RELCOM 在内的庞大用户群已经支持它；在前苏联地区的 Unix 与全球网络应用中，它已是事实标准。Unix 用户团体协会要求登记，是因为一个正在运行的共同体需要共同、可引用的名字。

因此，RFC 并没有凭空创造一种编码。它把既有操作惯例变成可检查的公共映射。这个先后顺序呼应 Heng Lu 对运行代码优先的论述：采用事实约束规范，规范再为互操作提供稳定坐标。

这种制度上的克制必须保留。“已登记”回答的是名称应指向哪张映射表，不是对最佳性、普遍部署、实现正确或适用范围的认证。RFC 自己也没有声称 KOI8-R 是互联网标准，更没有替所有俄文系统作出统一授权。

那张表远不只是字母表

RFC 1489 将八位字节空间分成两半。低半区与 ASCII 一致；高半区除了西里尔字母，还包含制表线段、方块、数学符号、版权符号和其他终端时代图形。Unicode 联盟的 KOI8-R 映射文件后来把 RFC 表格整理成机器可读形式。

字母位置解释了那层可读影子。KOI8-R 的 C1 是西里尔小写 а；清除最高位后成为 ASCII 41，即大写 A。E1 是西里尔大写 А；清位后成为 ASCII 61，即小写 a。大小写颠倒并非字体偶然，而是两组字母在码位安排上的结果。

这种排列只在粗略工程意义上接近音译。俄文 Р 会落向拉丁 R，С 落向 S，Т 落向 T；另一些字母只能借用 W、Q、X 或标点近似。熟悉损坏模式的人能够猜句子，不代表它构成语言学上完整、无歧义的转写。

高半区也并非整体都享有这种韧性。制表符号清位后可能变成控制字符或毫无视觉关联的标点。表格边框、示意图或数学记号会消失，而旁边的俄文词仍勉强可读。因此，“KOI8-R 能经受七位链路”说得过头了。部分字母信息留下了有用影子，八位原始记录并没有幸存。

两个不同来源可以坍缩成同一个结果

有意义的输出会让有损变换显得格外安全。ASCII 大写 A 的字节是 41；KOI8-R 西里尔小写 а 的字节是 C1。最高位清零以后，两者都是 41。仅凭幸存者，档案人员不能判断来源是哪一个。

纯俄文句子的语言上下文可能很强，混合内容则没有这种便利。源代码、邮件头、产品名、文件路径、原本就是拉丁转写的词和西里尔正文可以出现在同一条消息里。自动给每个“像拉丁字母”的位置补上最高位，会破坏真正的 ASCII；原样保留又会放弃受损的俄文。词典或语言模型可以给假设排序，却不能制造来源证明。

大小写还可能成为第二次损失。运营工具若先做大小写归一，投影规律的线索也会被抹掉；搜索索引可能折叠大小写；日志收集器可能改写控制位置；之后再导出成 UTF-8，则会忠实编码一个错误推断出的拉丁字符串，让旧损坏披上整洁现代格式。

所以，恢复需要原始字节，或足以独立重建原始字节的旁证。可读性适合分流和提示人工复核，不足以填平证据缺口。

字符集标签选择解码器，不会检查正文

今天的 IANA 字符集登记表仍列出 KOI8-R，MIBenum 为 2084，别名为 csKOI8R，引用 RFC 1489。这个持续存在的记录很有价值：系统见到 charset=koi8-r 时，可以知道发送者声称采用哪套字节到字符映射。

RFC 2046汇总的 MIME 规则说明了标签为何重要。charset 参数描述发送者希望接收方如何解释文本正文的八位组；若邮件路径不能保留八位，正文还可能需要内容传输编码。两者是不同控制面：一个命名解释规则，另一个保护传输。

RFC 2046 的状态记录能证明其标准谱系，却不能让消息里一个语法正确的字段自动变真。错误的 koi8-r 声明仍然错误；缺失标签也不等于接收端获得静默猜测的授权；正确标签同样不证明中间节点完整保留了字节。

后来的 RFC 2978进一步划清登记边界：登记把唯一名称与完整描述的字符集联系起来，并说明能否用于 MIME 文本；一般适用性由具体应用协议决定，而不是登记动作决定。RFC Editor 对 RFC 2978 的记录将它列为 Best Current Practice。这是后来的治理澄清，不应倒推成 Chernov 在 1993 年实际遵循的逐项程序。

这也是 Heng Lu 所说的现实分层：登记表证明名字被分配，消息头保存映射声明，存储字节是物质记录，解码器产出字符，字体产出字形，读者产出理解。相邻层完全可能一层正确、一层错误。

本地扩展没有取消共同底座

五年后，RFC 2319描述 KOI8-U。它保持所有 KOI8-R 俄文字母的位置，再利用高半区其他位置加入四个乌克兰字母。RFC 2319 的状态页同样把它列为 Informational。

这段历史很能说明问题：乌克兰编码早在 1992 年一次互联网服务提供商邮政主管会议上获得采用，随后才补全。兼容并不要求某个全球机构重新设计整张表；本地共同体既保留共享的俄文字母表面，又填补自身语言缺口。

它符合最小初始规范与本地未来决策的协调方式：窄而清楚的公共映射足以交换，却不需要取得对未来所有字母、应用和档案的权力。不过兼容范围必须说准。KOI8-U 与 KOI8-R 在俄文字母上的兼容，不等于 KOI8-R 解码器能够表达新增乌克兰字母。把两个标签混成一个，正好删除了扩展想保存的信息。

Unicode 改变了共同目的地，没有改写档案过去

RFC 3629定义面向 Unicode 字符集的 UTF-8。它与 KOI8-R 一样保留普通 ASCII 字节，却以变长序列承载通用字符集，而不是把语言专用字母放入固定高半区。RFC 3629 的状态记录展示了后来形成的标准轨迹。

UTF-8 扩大了互操作表面，却不能追溯识别一个无标签旧文件。正确转换 KOI8-R，仍需源字节与正确源映射。Unicode 映射文件还明确提醒：这份以 RFC 为基础的表不声称与每家厂商所谓 Code Page 878 完全相同。即使字符转换看起来成功，也可能漏掉特定记录依赖的厂商差异。

更可靠的档案可同时保存两张收据：原始 KOI8-R 八位组及其哈希；规范化 Unicode 版本及转换器、映射版本、异常和输出哈希。只因 UTF-8 文本“看起来正确”就删除源文件，是用便利换走将来复核所需的证据。

RFC 1489 的长久价值不在怀旧。它展示了韧性必须有范围：一张码表可以让某类损坏以人类较易识别的方式失败，却不能让有损变换变成无损，不能让登记表检查一封消息，也不能让读者的直觉替代原始记录。

来源