ABNF中的替代运算符是可交换的吗？

时间：2016-05-24 11:35:18

标签： parsing abnf

Augmented Backus-Naur Form交换中的替代运算符（/）是否可交换？

例如，s = a / b与s = b / a相同吗？

2 个答案:

答案 0 :(得分：3)

我没有在BNF或ABNF上找到任何主要来源，它们在双方都能产生有效匹配时都明确指定/语义。他们也不暗示上下文无关的语法及其对非确定性的考虑。如果有人知道要澄清参考文献，请分享。

编辑：Tony的answer指出，RFC 3501至少在该文档中使用了ABNF交替的语义。

RFC 5234: Augmented BNF for Syntax Specifications: ABNF（2008）

简介对BNF和ABNF进行了对比（在此处重点强调）：

  

多年来，Backus-Naur形式（BNF）的修改版本，称为增强BNF（ABNF），已在许多Internet规范中流行。它平衡了紧凑性和简单性与合理的表示能力。在Arpanet的早期，每个规范都包含其自己的ABNF定义。其中包括电子邮件规范RFC733，然后是RFC822，这是定义ABNF的常见引用。当前文档将这些定义分开，以允许选择性引用。

     

标准BNF和ABNF之间的差异涉及命名规则，重复，替代，顺序独立和值范围。

“选择性引用”和“顺序独立性”可能与交替排序语义有关，但尚不清楚。

RFC 822: Standard for the Format of ARPA Internet Text Messages（1982）

除非我丢失了所引用的RFC也不指定/语义的方式，否则会有所遗漏。第2.2节规避了这个问题。

  

2.2。规则1 /规则2：替代方案

     

以斜杠（“ /”）分隔的元素是替代方案。那里-   前一个“ foo / bar”将接受foo或bar。

各种规则定义表明它们认识到避免歧义的实际重要性。例如，以下是RFC 822如何定义optional-field及其依赖项：

 optional-field =
             /  "Message-ID"        ":"   msg-id
             /  "Resent-Message-ID" ":"   msg-id
             /  "In-Reply-To"       ":"  *(phrase / msg-id)
             /  "References"        ":"  *(phrase / msg-id)
             /  "Keywords"          ":"  #phrase
             /  "Subject"           ":"  *text
             /  "Comments"          ":"  *text
             /  "Encrypted"         ":" 1#2word
             /  extension-field              ; To be defined
             /  user-defined-field           ; May be pre-empted

 extension-field =
               <Any field which is defined in a document
                published as a formal extension to this
                specification; none will have names beginning
                with the string "X-">

 user-defined-field =
               <Any field which has not been defined
                in this specification or published as an
                extension to this specification; names for
                such fields must be unique and may be
                pre-empted by published extensions>

The Syntax and Semantics of the Proposed International Algebraic Language of the Zurich ACM-GAMM Conference（Backus 1958）

BNF来自IAL表示法。本文介绍了与“ /”直观相关的“金属语言连接词”。但是，它也避免了模棱两可的选择问题，大概只是谨慎地使用它。

推荐

由于语义不明确，我的建议是将alternation规则中的所有可能匹配项都视为有效。如果没有精心设计语法来避免歧义，则这种解释会导致同一输入有多个有效的解析树。解决模棱两可的解析问题要比无意识地有效的解析树向前伪造更安全。

或者，如果您对语法的指定方式有影响，则可以考虑使用语义更清晰的符号。例如，Parsing Expression Grammar: A Recognition-Based Syntactic Foundation（福特2004年）提供了确定性的优先选择语义（最左边的匹配获胜）。

答案 1 :(得分：1)

一些RFC明确地阐明了这一点，例如IMAPv4的RFC3501包含了RFC 3501 section 9中类似PEG行为的规范：

  

在替代规则或可选规则的情况下，使用后一个规则      与早先的规则重叠，早先列出的规则必须采用      优先。例如，当解析为标志时，“ \ Seen”就是“ \ Seen”      标志名称，而不是标志扩展名，即使可以解析“ \ Seen”      作为标志扩展名。此规则的一些（但不是全部）实例是      如下所述。

不过，我不知道这种歧义消除（哈哈）有多普遍。我查看过的许多其他RFC（最近几天一直在实现ABNF解析器库）只是未指定。许多RFC ABNF语法是明确的（例如RFC8259（JSON））；但是，其中许多是模棱两可的（例如RFC5322（Internet消息）），并且需要进行修复才能与保留歧义的解析器一起使用：-（

相关问题
最新问题