摘要

  • RFC 5198 定义的 Net-Unicode 是一组联合条件：UTF-8、NFC、码位是否已分配、CRLF 以及控制字符限制；“UTF-8 解码成功”只覆盖其中一层。
  • 操作系统或语言库可以在应用代码不变时更新 Unicode 表。要证明一次文本决策，必须记录实际加载的 Unicode/NFC 数据及输入、接纳、规范化和下游动作。

相同构建并不等于相同行为

生产追踪习惯把应用版本当成行为坐标。这个坐标有用，却只证明应用自身的字节。RFC 5198 指出，应用往往不会自行完成 Unicode 转换与规范化，而是调用操作系统或语言库；这些函数能够在应用代码没有变化时升级。更棘手的是，应用可能根本无法知道自己实际使用了哪个 Unicode 版本、哪个规范化过程，也无法保证两者一致。

这并不意味着 Unicode 每次升级都会改写既有字符串。RFC 5198 依赖 NFC 稳定性：只要字符串没有未分配码位并且已经按 NFC 规范化，未来版本仍应把它视为 NFC。真正会移动的是字符库边缘。一个尚未分配的码位先对自身规范化；以后被分配时，它可能参与新的规范化映射。符合规范的发送方不得传输在其依赖版本中仍未分配的码位。因此，底层数据库一换，应用允许发送的集合就可能改变。

所以“应用哈希相同”不是充分的不变证明。它需要与主机或容器镜像、语言运行时、Unicode 字符数据库和规范化数据一起解释。

Net-Unicode 比 UTF-8 多五道判断

RFC 3629 规定 UTF-8 编码。RFC 5198 在其上给网络文本增加具体轮廓。字符必须使用 UTF-8；存在“行”概念时，行结束必须是 CRLF。CR 不应单独出现，只有遗留的 CR NUL 组合被允许但不推荐，而 NUL 又可能成为某些语言的字符串终止符。

C1 控制字符 U+0080 至 U+009F 不得出现。IND、NEL、U+2028、U+2029 也不能替代 CRLF。开头不得带 BOM。发送前应使用 NFC；系统不得发送其 Unicode 版本中尚未分配的码位；Unicode 与 NFC 版本必须一致。

这些不是一个布尔值。UTF-8 检查字节是否合法，字符库判断码位是否有定义，NFC 处理规范等价序列，行与控制策略限制网络文本语法。若日志只写 unicode_ok，事后就无法区分究竟是哪一层接受、拒绝或改写了输入。

勘误也说明了状态分层的重要性。原文把 U+0080 至 U+009F 误称为 ASCII 范围的一部分，相关技术勘误仍是“已报告”而非“已验证”；与此同时，正文对 C1 的独立禁令并不含糊。编号 1402 的已验证勘误只把“见下文”改成“见上文”。实现方不能把所有勘误状态压成一个自创版本。

控制点与应用可能看到不同文本

RFC 5198 明确警告：接收方不能假设输入已经规范化。攻击者可能故意使用未规范化形式，绕过防火墙等系统的朴素文本匹配。如果网关与业务应用依赖不同的 Unicode 表，问题就不仅是“有没有做 NFC”，而是两处对哪一段文本、依据哪套表做了什么。

网关可以先规范化再匹配，应用也可能再次规范化；二者可能转发原字节，也可能转发变换后的文本。单独保存“规则命中”无法证明业务程序比较的是同一序列。签名前规范化与对原始字节验签后再规范化也不是同一流程；行尾转换会改变偏移；BOM 可能被当成签名、数据或错误。

RFC 5198 并不要求覆盖那些已经精确定义 UTF-8 用法的协议。它提供的是缺少定义时的公共网络文本形式。运维要记录实际采用的协议轮廓，而不是把 Net-Unicode 当作任意数据的万能清洗器。

把运行时纳入凭据

可复现凭据首先记录应用版本与哈希，同时记录基础镜像、语言运行时、Unicode 字符数据库、NFC 实现和规范化数据版本。平台若无法暴露这些信息，就应明确写“未知”，不能用产品版本代替。

每次关键处理还要把接收字节哈希连接到 UTF-8 结果、码位序列，以及在指定数据库下的“已分配/未分配”判断。BOM、私用区、C0、C1、CR、LF、CR NUL、U+2028 与 U+2029 分开记。规范化前哈希、NFC 输出哈希和“输入本已是 NFC”三个字段，可以区分验证与变换。

最后记录消费文本的动作：比较、过滤、签名、存储或展示；再把动作权限与观察到的效果分开。Net-Unicode 合规可以提高互操作性，却不能证明身份、授权或业务结果。本文拥有的只是更基础的一条边界：可见应用版本没有变化，不代表执行文本规则的运行时没有变化。

来源

  1. RFC 5198 HTML
  2. RFC 5198 文本
  3. RFC 5198 信息页
  4. IETF Datatracker：RFC 5198
  5. RFC 5198 历史
  6. RFC 5198 引用关系
  7. RFC 5198 勘误
  8. RFC 3629 — UTF-8
  9. RFC 2277 — 字符集与语言政策
  10. RFC 4690 — 国际化域名问题回顾
  11. RFC 3454 — Stringprep
  12. RFC 8264 — PRECIS 框架
  13. RFC 6365 — 国际化术语
  14. RFC 854 — Telnet
  15. RFC 698 — Telnet 扩展 ASCII 选项
  16. Unicode 标准附件 #15 — 规范化形式
  17. Unicode 稳定性政策
  18. Heng Lu — 现实分层与符号权力
  19. Heng Lu — 最小初始规范
  20. Heng Lu — 运行代码优先