摘要

  • RFC 3072 的 SDXF 数据块包含标识符、标志位、三字节长度和内容。文中的读取示例忽略未知标识符，再移至下一个数据块。
  • 这项规则保证解析可以继续，却不保证理解：应用仍需共享语义、字符转换、方法实现，以及对数据采取行动的授权。

2001 年 3 月，Max Wildgrube 在 RFC 3072 中介绍了结构化数据交换格式（SDXF），目标是跨平台交换层级数据。对其承诺需要精确理解。文档称程序可以解包 SDXF 数据，而不必知道每个元素的意义；但它的读取示例只在 switch 中处理已知标识符，没有默认分支，随后调用前进到下一个数据块的操作。未知字段被忽略，解析继续。

二进制结构解释了这种机械上的连续性。普通数据块包括一个非零的两字节标识符、一个标志字节、三字节内容长度，随后是内容。结构化数据块可以递归地包含其他数据块。只要读取器能按格式规则定位下一个边界，就可以越过自己不解释的内容继续扫描。它确定的是数据块在哪里结束，而不是这个标识符在某个应用里代表什么。

RFC 3072 建议基于 SDXF 的应用协议忽略未知标识符，并且不依赖数据块顺序。这些规则可以让旧读取器容忍扩展，却无法判断该扩展对发送方的事务是否可有可无、是否会改变应用解释，或丢弃后是否会改变重要操作。继续遍历只是边界明确的兼容行为，并非宣告未知字段对所有场景都无关紧要。

格式本身也揭示了边界以外的其他约定。RFC 3072 将二进制值规范为大端序，提出 ISO 8859-1 内部字符表示，允许配置转换表，并另定义 UTF-8 数据类型。压缩和加密则由标志位、方法编号与函数控制；两者同时使用时先压缩，执行加密还必须提供密钥。因此，即使数据块的结构边界可读，接收端也可能缺少正确字符表、压缩/密码方法实现或密钥。

目前 IANA 的 SDXF 注册表列有 RUN-LENGTH、DEFLATE 压缩方法，以及编号为 01 的 AES 加密方法。注册记录说明了编号分配，却不证明接收端实现了相应方法，也不证明某条消息已被正确变换。RFC 3072 属于 Informational，并未制定 Internet 标准；现有来源也不能证明实际部署或采用。格式提案不是生产环境互操作报告。

应把证据拆成相互独立的层次：长度说明按格式规则字节延伸到哪里；标识符指向应用定义的概念；字符表负责转换；方法编号选择操作，而代码与密钥决定能否执行；授权规则最后决定提取值能否产生后果。后来的 Running-Code Primacy 可作为分析视角，提醒我们观察每一层实际运行的行为，而不是从文档名称推断。Reality Layers 则帮助区分象征性说法与可执行效果。这些是后来的分析镜头，并非 Wildgrube 本人的主张。

库的返回码把这种区分落实到了运行层。迭代器可以报告已经抵达另一个数据块，而内容提取仍可能因为缓冲区过小、无法转换、方法缺失或没有密钥而失败。这些结果分别对应不同控制点，不能压缩成一个“消息已成功解析”的总判断。若这样做，恰好会抹掉 SDXF 暴露出的关键边界：结构遍历可以在遇到未知字段后继续，但语义是否成立、操作条件是否具备仍悬而未决。应用必须保留这份不确定性，直到自身模式与决策规则给出答案。

这也解释了为什么“未知即可忽略”不能脱离具体协议单独成立。只有应用契约能说明该字段是否可选、是否必须原样转发，以及省略后是否仍能安全完成同一项操作；通用解析器仅凭长度无法替它作出这些决定。

来源