摘要

  • RFC 2234 让 ABNF 有了独立文档，此前互联网规范往往各自收录这套记号的定义。
  • 共享语法语言让规则更容易被引用和组合，却不能证明不同实现会以相同方式解释协议。

一份规范可以描述协议消息的形式，同时还解释表达这些规则的记号。RFC 2234 回顾说，在 ARPANET 早期，各份规范都带有自己的 ABNF 定义；电子邮件规范 RFC 733、随后 RFC 822，后来成了常见的引用来源。但一般性的语法语言若藏在某个特定协议文档里，读者就得先找到那个协议，才能查语法本身。

RFC 2234 于 1997 年 11 月发布，把这套定义分离出来，以便其他规范按需引用。变化并非“互联网统一采用了一个解析器”，而是给规则名、终结符、重复、备选项、数值范围和分组提供了共同参照。ABNF 用来描述可接受的字符串；它并不是某个已部署程序究竟接受什么内容的证据。

这几层不能混为一谈：ABNF 描述语法；协议规范决定哪些规则定义消息；传输环境决定终结值如何编码；解析器则把这些选择落实到程序里。RFC 2234 明确指出，同一套语法可以对应不同的外部编码，并将编码细节留在 ABNF 范围之外。因此，语法记号能够跨协议复用，却不能仅凭自身解决线路上实际字节如何解释的所有问题。

规则也可以分段组合。=/ 运算符把新的备选项追加到别处定义过的规则中；RFC 2234 说，这对建立在共同父规则集之上的独立规范可能有用。这只是文档组合方式，不是让解析器在运行时自动发现扩展的指令。规范作者仍需交代哪些文档共同构成规则，以及组合的边界在哪里。

这是一种很有限、也很实用的互联网协调：统一书写规则的词汇，把各协议自己的规则分开放置，并且显露编码选择。RFC 2234 没有靠命名来消除分歧，而是让其中一个层次更容易被指出。它之后经历 RFC 4234、RFC 5234 等修订，也说明共享语言仍可演进。RFC 7405 后来处理了与 UTF-8 有关的语法；不能把这些后续内容倒推到 1997 年的文本里。

所以，ABNF 的历史不是“数学取代了文字”。文字仍解释协议的用途与上下文；语法则简洁地描述形式。真正改变的是：书写语法语言的定义，不再必须寄居于每份使用它的协议规范中。复用因此有了明确可引的出处，而关于实现的断言，仍须由实现本身的证据支撑。

来源：RFC 2234；Datatracker 中的 RFC 2234 记录；RFC 2234 历史记录；RFC Editor 的 RFC 2234 条目；RFC 733；RFC 822；RFC 4234；RFC Editor 的 RFC 4234 条目；RFC 5234；RFC Editor 的 RFC 5234 条目；RFC 7405；RFC 2119；Lu Heng：运行中的代码优先；Lu Heng：最小初始规范；Lu Heng：现实层次。