我还没有在 BNF 或 ABNF 上找到任何主要来源来明确指定/双方何时产生有效匹配的语义。他们也没有提到上下文无关语法及其对非确定性的允许。如果有人知道澄清参考资料，请分享。
编辑：托尼的回答指出2003 年的RFC 3501指定了 ABNF 交替的语义，至少在该文档中使用它。
\n引言中对比了 BNF 和 ABNF（此处添加了重点）：
\n\n\n多年来，巴科斯-诺尔范式 (BNF) 的修改版本，称为增强 BNF (ABNF)，在许多互联网规范中很流行。它平衡了紧凑性和简单性与合理的代表性能力。在阿帕网的早期，每个规范都包含自己的 ABNF 定义。其中包括电子邮件规范RFC733和RFC822，它们后来成为定义 ABNF 的常见引用。当前的文件将这些定义分开，以允许选择性参考。
\n标准 BNF 和 ABNF 之间的差异涉及命名规则、重复、替代、顺序无关性和值范围。
\n
“选择性引用”和“顺序独立”可能与交替排序语义有关，但尚不清楚。
\n除非我遗漏了什么，否则引用的 RFC 也没有指定/语义。2.2节回避了这个问题。
\n\n2.2. 规则 1 / 规则 2：替代方案
\n
\n\n由斜杠（“/”）分隔的元素是替代元素。因此，“foo / bar”将接受 foo 或 bar。
\n
各种规则定义表明他们认识到避免歧义的实际重要性。optional-field例如，RFC 822 的定义及其依赖关系如下：
optional-field =\n / "Message-ID" ":" msg-id\n / "Resent-Message-ID" ":" msg-id\n / "In-Reply-To" ":" *(phrase / msg-id)\n / "References" ":" *(phrase / msg-id)\n / "Keywords" ":" #phrase\n / "Subject" ":" *text\n / "Comments" ":" *text\n / "Encrypted" ":" 1#2word\n / extension-field ; To be defined\n / user-defined-field ; May be pre-empted\n\n extension-field =\n <Any field which is defined in a document\n published as a formal extension to this\n specification; none will have names beginning\n with the string "X-">\n \n user-defined-field =\n <Any field which has not been defined\n in this specification or published as an\n extension to this specification; names for\n such fields must be unique and may be\n pre-empted by published extensions>\nBNF 来自 IAL 符号。论文介绍了 \xcc\x85o\xcc\x85r “元语言连接词”，直观上与/. 然而，它也回避了模棱两可的选择问题，大概只是小心翼翼地使用它。
由于未指定的语义，我的建议是将规则中的每个可能的匹配视为alternation有效。当语法没有仔细设计以避免歧义时，这种解释可能会导致同一输入产生多个有效的解析树。在发生不明确的解析时对其进行处理比使用无意的有效解析树更安全。
或者，如果您对语法的指定方式有影响，您可以考虑使用具有更清晰语义的表示法。例如，解析表达式语法：基于识别的句法基础（Ford 2004）给出了替代方案确定性优先选择语义（最左边的匹配获胜）。
\n