关于EBNF表示法和JSON的问题

时间:2010-11-07 15:25:31

标签: json parsing grammar bnf ebnf

最近我一直在研究解析器和语法以及它们是如何工作的。我正在http://www.ietf.org/rfc/rfc4627.txt阅读使用EBNF的JSON的正式语法。我对BNF和EBNF的理解非常有信心,但显然我还是不完全理解它。 RFC定义了一个JSON对象:

  object = begin-object [ member *( value-separator member ) ]
  end-object

我理解这里的意图是表示任何JSON对象都可以(可选)拥有一个成员,然后是0或更多(值分隔符,成员)对。我不明白为什么星号出现在<{em> (value-separator member)之前。是不是星号应该模仿正则表达式,以便项目重复0次或更多次之后?不应该像这样编写JSON对象语法:

  object = begin-object [ member ( value-separator member )* ]
  end-object

3 个答案:

答案 0 :(得分:13)

在上述文件http://www.ietf.org/rfc/rfc4627.txt中,声明

  

本文档中的语法规则应解释为      在[RFC4234]中描述。

RFC4234描述了ABNF(增强型BNF),而不是EBNF。 如果您浏览本文档,您将找到以下定义:

3.6.  Variable Repetition:  *Rule

   The operator "*" preceding an element indicates repetition.  The full
   form is:

         <a>*<b>element

   where <a> and <b> are optional decimal values, indicating at least
   <a> and at most <b> occurrences of the element.

   Default values are 0 and infinity so that *<element> allows any
   number, including zero; 1*<element> requires at least one;
   3*3<element> allows exactly 3 and 1*2<element> allows one or two.

所以,符号

*( value-separator member )

根据ABNF定义是正确的,并允许任意数量的重复,包括零。

答案 1 :(得分:9)

语法是关于某人选择写下具体实体来表示某事的方式。

我同意将Kleene明星实体重复之前推出是非标准的,并且作者选择 要做到这一点,只会混淆习惯惯例的人。但它完全有效;作者 得到定义什么语法的意思,你,标准的用户,只是接受它。

将Kleene星放在他所做的地方有一些争论;它表明有列表 在您可能期望列表的位置跟随。后缀式Kleene星表示 同样的,但它有点意外;首先你读取list元素(从左到右), 然后你发现了这颗星。

实际上,后Kleene-star的惊人因素通常不足以超过违反惯例的意外因素。但该标准的作者做出了选择。

欢迎使用语法。

答案 2 :(得分:1)

标准的好处在于有很多可供选择。

显然,Niklas Wirth想知道与you thirty-some years ago相同的事情:

  

编程人口   语言正在稳步增长,并且   这种增长没有结束   视线。许多语言定义   出现在期刊上,很多都出现在   技术报告,也许是偶数   更多的人仍然局限于   专营圈子。经常   接触这些定义,一   不能不注意到缺乏   “共同点。”唯一广泛的   接受的事实就是语言   结构由语法定义。但   甚至是句法的符号   描述不包括任何共同商定的   标准形式,虽然潜在的   祖先总是Backus-Naur   Algol 60报告的形式。如   它们的变化往往很轻微   他们非常缺乏而烦恼   明显的动机。

是的,RFC-4627中使用的符号不太常见,但并非不可理解。