Network Working Group D. Crocker, Ed.
Request for Comments: 5234 Brandenburg InternetWorking
STD: 68 P. Overell
Obsoletes: 4234 THUS plc.
Category: Standards Track January 2008
Network Working Group D. Crocker, Ed.
Request for Comments: 5234 Brandenburg InternetWorking
STD: 68 P. Overell
Obsoletes: 4234 THUS plc.
Category: Standards Track January 2008
Augmented BNF for Syntax Specifications: ABNF
语法规范的扩充BNF:ABNF
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.
互联网技术规范通常需要定义正式的语法。多年来，一种被称为增强型BNF（ABNF）的巴科斯诺尔形式（BNF）的修改版本在许多互联网规范中广受欢迎。当前规范记录了ABNF。它平衡了简洁性和合理的表现力。标准BNF和ABNF之间的差异涉及命名规则、重复、备选方案、顺序独立性和值范围。该规范还为几种Internet规范共有的核心词法分析器提供了额外的规则定义和编码。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rule Definition . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Rule Naming . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Rule Form . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terminal Values . . . . . . . . . . . . . . . . . . . . . 4
2.4. External Encodings . . . . . . . . . . . . . . . . . . . . 6
3. Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Concatenation: Rule1 Rule2 . . . . . . . . . . . . . . . 6
3.2. Alternatives: Rule1 / Rule2 . . . . . . . . . . . . . . . 7
3.3. Incremental Alternatives: Rule1 =/ Rule2 . . . . . . . . . 7
3.4. Value Range Alternatives: %c##-## . . . . . . . . . . . . 8
3.5. Sequence Group: (Rule1 Rule2) . . . . . . . . . . . . . . 8
3.6. Variable Repetition: *Rule . . . . . . . . . . . . . . . 9
3.7. Specific Repetition: nRule . . . . . . . . . . . . . . . 9
3.8. Optional Sequence: [RULE] . . . . . . . . . . . . . . . . 9
3.9. Comment: ; Comment . . . . . . . . . . . . . . . . . . . 9
3.10. Operator Precedence . . . . . . . . . . . . . . . . . . . 10
4. ABNF Definition of ABNF . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Appendix B. Core ABNF of ABNF . . . . . . . . . . . . . . . . . . 13
B.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . . . 13
B.2. Common Encoding . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rule Definition . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Rule Naming . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Rule Form . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terminal Values . . . . . . . . . . . . . . . . . . . . . 4
2.4. External Encodings . . . . . . . . . . . . . . . . . . . . 6
3. Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Concatenation: Rule1 Rule2 . . . . . . . . . . . . . . . 6
3.2. Alternatives: Rule1 / Rule2 . . . . . . . . . . . . . . . 7
3.3. Incremental Alternatives: Rule1 =/ Rule2 . . . . . . . . . 7
3.4. Value Range Alternatives: %c##-## . . . . . . . . . . . . 8
3.5. Sequence Group: (Rule1 Rule2) . . . . . . . . . . . . . . 8
3.6. Variable Repetition: *Rule . . . . . . . . . . . . . . . 9
3.7. Specific Repetition: nRule . . . . . . . . . . . . . . . 9
3.8. Optional Sequence: [RULE] . . . . . . . . . . . . . . . . 9
3.9. Comment: ; Comment . . . . . . . . . . . . . . . . . . . 9
3.10. Operator Precedence . . . . . . . . . . . . . . . . . . . 10
4. ABNF Definition of ABNF . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Appendix B. Core ABNF of ABNF . . . . . . . . . . . . . . . . . . 13
B.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . . . 13
B.2. Common Encoding . . . . . . . . . . . . . . . . . . . . . 15
Internet technical specifications often need to define a formal syntax and are free to employ whatever notation their authors deem useful. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. It balances compactness and simplicity with reasonable representational power. In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, [RFC733] and then [RFC822], which came to be the common citations for defining ABNF. The current document separates those definitions to permit selective reference. Predictably, it also provides some modifications and enhancements.
互联网技术规范通常需要定义正式的语法，并且可以自由使用其作者认为有用的任何符号。多年来，一种被称为增强型BNF（ABNF）的巴科斯诺尔形式（BNF）的修改版本在许多互联网规范中广受欢迎。它平衡了简洁性和合理的表现力。在Arpanet的早期，每个规范都包含其自身对ABNF的定义。这包括电子邮件规范[RFC733]和[RFC822]，这是定义ABNF的常见引用。当前文件将这些定义分开，以允许选择性引用。可以预见，它还提供了一些修改和增强。
The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. Appendix B supplies rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. It is provided as a convenience and is otherwise separate from the meta language defined in the body of this document, and separate from its formal status.
标准BNF和ABNF之间的差异涉及命名规则、重复、备选方案、顺序独立性和值范围。附录B提供了几种Internet规范共有的核心词法分析器的规则定义和编码。它是为了方便起见而提供的，并且与本文档正文中定义的元语言分离，并与其正式状态分离。
The name of a rule is simply the name itself, that is, a sequence of characters, beginning with an alphabetic character, and followed by a combination of alphabetics, digits, and hyphens (dashes).
规则的名称只是名称本身，即一系列字符，以字母字符开头，后跟字母、数字和连字符（破折号）的组合。
NOTE:
注:
Rule names are case insensitive.
规则名称不区分大小写。
The names <rulename>, <Rulename>, <RULENAME>, and <rUlENamE> all refer to the same rule.
名称<rulename>、<rulename>、<rulename>和<rulename>都引用相同的规则。
Unlike original BNF, angle brackets ("<", ">") are not required. However, angle brackets may be used around a rule name whenever their presence facilitates in discerning the use of a rule name. This is typically restricted to rule name references in free-form prose, or to distinguish partial rules that combine into a string not separated by white space, such as shown in the discussion about repetition, below.
与原始BNF不同，不需要尖括号（“<”、“>”）。但是，只要尖括号的存在有助于识别规则名称的使用，就可以在规则名称周围使用尖括号。这通常仅限于自由格式散文中的规则名称引用，或用于区分组合成不以空格分隔的字符串的部分规则，如下面关于重复的讨论所示。
A rule is defined by the following sequence:
规则由以下顺序定义：
name = elements crlf
name = elements crlf
where <name> is the name of the rule, <elements> is one or more rule names or terminal specifications, and <crlf> is the end-of-line indicator (carriage return followed by line feed). The equal sign separates the name from the definition of the rule. The elements form a sequence of one or more rule names and/or value definitions, combined according to the various operators defined in this document, such as alternative and repetition.
其中，<name>是规则的名称，<elements>是一个或多个规则名称或终端规范，<crlf>是行尾指示符（回车后是换行符）。等号将名称与规则的定义分开。这些元素构成了一个或多个规则名称和/或值定义的序列，并根据本文档中定义的各种运算符（如替换和重复）进行组合。
For visual ease, rule definitions are left aligned. When a rule requires multiple lines, the continuation lines are indented. The left alignment and indentation are relative to the first lines of the ABNF rules and need not match the left margin of the document.
为便于查看，规则定义是左对齐的。当规则需要多行时，将缩进连续行。左对齐和缩进相对于ABNF规则的第一行，不需要与文档的左边距匹配。
Rules resolve into a string of terminal values, sometimes called characters. In ABNF, a character is merely a non-negative integer. In certain contexts, a specific mapping (encoding) of values into a character set (such as ASCII) will be specified.
规则解析为一个终端值字符串，有时称为字符。在ABNF中，字符仅仅是一个非负整数。在某些上下文中，将指定值到字符集（如ASCII）的特定映射（编码）。
Terminals are specified by one or more numeric characters, with the base interpretation of those characters indicated explicitly. The following bases are currently defined:
终端由一个或多个数字字符指定，并明确指示这些字符的基本解释。目前定义了以下基础：
b = binary
b = binary
d = decimal
d = decimal
x = hexadecimal
x = hexadecimal
Hence:
因此：
CR = %d13
CR = %d13
CR = %x0D
CR = %x0D
respectively specify the decimal and hexadecimal representation of [US-ASCII] for carriage return.
分别为回车指定[US-ASCII]的十进制和十六进制表示形式。
A concatenated string of such values is specified compactly, using a period (".") to indicate a separation of characters within that value. Hence:
此类值的串联字符串是紧凑指定的，使用句点（“.”）表示该值内的字符分隔。因此：
CRLF = %d13.10
CRLF = %d13.10
ABNF permits the specification of literal text strings directly, enclosed in quotation marks. Hence:
ABNF允许直接指定文字文本字符串，并用引号括起来。因此：
command = "command string"
command = "command string"
Literal text strings are interpreted as a concatenated set of printable characters.
文字文本字符串被解释为一组串联的可打印字符。
NOTE:
注:
ABNF strings are case insensitive and the character set for these strings is US-ASCII.
ABNF字符串不区分大小写，这些字符串的字符集为US-ASCII。
Hence:
因此：
rulename = "abc"
rulename = "abc"
and:
以及：
rulename = "aBc"
rulename = "aBc"
will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and "ABC".
将匹配“abc”、“abc”、“abc”、“abc”、“abc”、“abc”、“abc”、“abc”、“abc”和“abc”。
To specify a rule that is case sensitive, specify the characters individually.
要指定区分大小写的规则，请分别指定字符。
For example:
例如：
rulename = %d97 %d98 %d99
rulename = %d97 %d98 %d99
or
或
rulename = %d97.98.99
rulename = %d97.98.99
will match only the string that comprises only the lowercase characters, abc.
将仅匹配仅包含小写字符abc的字符串。
External representations of terminal value characters will vary according to constraints in the storage or transmission environment. Hence, the same ABNF-based grammar may have multiple external encodings, such as one for a 7-bit US-ASCII environment, another for a binary octet environment, and still a different one when 16-bit Unicode is used. Encoding details are beyond the scope of ABNF, although Appendix B provides definitions for a 7-bit US-ASCII environment as has been common to much of the Internet.
终端值字符的外部表示形式将根据存储或传输环境中的约束而变化。因此，相同的基于ABNF的语法可能具有多个外部编码，例如一个用于7位US-ASCII环境，另一个用于二进制八位字节环境，并且在使用16位Unicode时仍然是不同的。编码细节超出了ABNF的范围，尽管附录B提供了7位US-ASCII环境的定义，这在大部分互联网上都很常见。
By separating external encoding from the syntax, it is intended that alternate encoding environments can be used for the same syntax.
通过将外部编码与语法分离，可以为相同的语法使用备用编码环境。
A rule can define a simple, ordered string of values (i.e., a concatenation of contiguous characters) by listing a sequence of rule names. For example:
规则可以通过列出规则名称序列来定义一个简单、有序的值字符串（即，连续字符的串联）。例如：
foo = %x61 ; a
foo = %x61 ; a
bar = %x62 ; b
bar = %x62 ; b
mumble = foo bar foo
mumble = foo bar foo
So that the rule <mumble> matches the lowercase string "aba".
因此规则<mumble>匹配小写字符串“aba”。
Linear white space: Concatenation is at the core of the ABNF parsing model. A string of contiguous characters (values) is parsed according to the rules defined in ABNF. For Internet specifications, there is some history of permitting linear white space (space and horizontal tab) to be freely and implicitly interspersed around major constructs, such as delimiting special characters or atomic strings.
线性空白：串联是ABNF解析模型的核心。根据ABNF中定义的规则解析连续字符（值）字符串。对于Internet规范，有一些历史允许线性空白（空格和水平制表符）自由且隐式地散布在主要结构周围，例如分隔特殊字符或原子字符串。
NOTE:
注:
This specification for ABNF does not provide for implicit specification of linear white space.
ABNF的本规范不提供线性空白的隐式规范。
Any grammar that wishes to permit linear white space around delimiters or string segments must specify it explicitly. It is often useful to provide for such white space in "core" rules that are then used variously among higher-level rules. The "core" rules might be formed into a lexical analyzer or simply be part of the main ruleset.
任何希望在分隔符或字符串段周围允许线性空白的语法都必须显式指定它。在“核心”规则中提供这样的空白，然后在更高级别的规则中使用，这通常是有用的。“核心”规则可以形成词法分析器，也可以只是主规则集的一部分。
Elements separated by a forward slash ("/") are alternatives. Therefore,
用正斜杠（“/”）分隔的元素是可选元素。因此
foo / bar
foo/bar
will accept <foo> or <bar>.
将接受<foo>或<bar>。
NOTE:
注:
A quoted string containing alphabetic characters is a special form for specifying alternative characters and is interpreted as a non-terminal representing the set of combinatorial strings with the contained characters, in the specified order but with any mixture of upper- and lowercase.
包含字母字符的带引号的字符串是用于指定可选字符的特殊形式，它被解释为一个非终端，表示包含字符的组合字符串集，以指定的顺序，但有任何大小写的混合。
It is sometimes convenient to specify a list of alternatives in fragments. That is, an initial rule may match one or more alternatives, with later rule definitions adding to the set of alternatives. This is particularly useful for otherwise independent specifications that derive from the same parent ruleset, such as often occurs with parameter lists. ABNF permits this incremental definition through the construct:
有时，在片段中指定备选方案列表是很方便的。也就是说，初始规则可以匹配一个或多个备选方案，随后的规则定义将添加到备选方案集。这对于派生自同一父规则集的其他独立规范尤其有用，例如参数列表中经常出现的规范。ABNF允许通过构造进行这种增量定义：
oldrule =/ additional-alternatives
oldrule=/其他备选方案
So that the ruleset
因此，规则集
ruleset = alt1 / alt2
ruleset = alt1 / alt2
ruleset =/ alt3
规则集=/alt3
ruleset =/ alt4 / alt5
ruleset =/ alt4 / alt5
is the same as specifying
与指定相同
ruleset = alt1 / alt2 / alt3 / alt4 / alt5
ruleset = alt1 / alt2 / alt3 / alt4 / alt5
A range of alternative numeric values can be specified compactly, using a dash ("-") to indicate the range of alternative values. Hence:
可以使用短划线（“-”）紧凑地指定可选数值的范围，以指示可选值的范围。因此：
DIGIT = %x30-39
DIGIT = %x30-39
is equivalent to:
相当于：
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
"7" / "8" / "9"
Concatenated numeric values and numeric value ranges cannot be specified in the same string. A numeric value may use the dotted notation for concatenation or it may use the dash notation to specify one value range. Hence, to specify one printable character between end-of-line sequences, the specification could be:
不能在同一字符串中指定串联的数值和数值范围。数值可以使用虚线表示法进行串联，也可以使用虚线表示法指定一个值范围。因此，要在行尾序列之间指定一个可打印字符，规范可以是：
char-line = %x0D.0A %x20-7E %x0D.0A
char-line = %x0D.0A %x20-7E %x0D.0A
Elements enclosed in parentheses are treated as a single element, whose contents are strictly ordered. Thus,
括号中的元素被视为单个元素，其内容是严格有序的。因此
elem (foo / bar) blat
元素（食物/酒吧）布拉特
matches (elem foo blat) or (elem bar blat), and
匹配（elem foo blat）或（elem bar blat），以及
elem foo / bar blat
艾琳·福/巴·布拉特
matches (elem foo) or (bar blat).
匹配（elem-foo）或（bar-blat）。
NOTE:
注:
It is strongly advised that grouping notation be used, rather than relying on the proper reading of "bare" alternations, when alternatives consist of multiple rule names or literals.
强烈建议，当备选方案由多个规则名称或文字组成时，使用分组符号，而不是依赖于对“裸”备选方案的正确解读。
Hence, it is recommended that the following form be used:
因此，建议使用以下表格：
(elem foo) / (bar blat)
（elem foo）/（bar blat）
It will avoid misinterpretation by casual readers.
这将避免偶然读者的误解。
The sequence group notation is also used within free text to set off an element sequence from the prose.
在自由文本中，序列组表示法也用于从散文中设置元素序列。
The operator "*" preceding an element indicates repetition. The full form is:
元素前面的运算符“*”表示重复。表格全文如下：
<a>*<b>element
<a>*<b>element
where <a> and <b> are optional decimal values, indicating at least <a> and at most <b> occurrences of the element.
其中<a>和<b>是可选的十进制值，表示元素至少出现<a>和最多出现<b>。
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.
默认值为0和无穷大，因此*<element>允许任何数字，包括零；1*<element>至少需要一个；3*3<element>正好允许3；1*2<element>允许一个或两个。
A rule of the form:
形式规则：
<n>element
<n> 元素
is equivalent to
相当于
<n>*<n>element
<n>*<n>element
That is, exactly <n> occurrences of <element>. Thus, 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
也就是说，<element>的出现次数正好是<n>。因此，2DIGIT是一个2位数字，3ALPHA是一个由三个字母组成的字符串。
Square brackets enclose an optional element sequence:
方括号中包含一个可选的元素序列：
[foo bar]
[富吧]
is equivalent to
相当于
*1(foo bar).
*1（富吧）。
A semicolon starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications.
分号开始一条注释，该注释一直延续到行尾。这是一种简单的方法，可以在规范中同时包含有用的注释。
The various mechanisms described above have the following precedence, from highest (binding tightest) at the top, to lowest (loosest) at the bottom:
上述各种机制具有以下优先顺序，从顶部的最高（最紧的绑定）到底部的最低（最松的绑定）：
Rule name, prose-val, Terminal value
规则名称、文本值、终值
Comment
议论
Value range
值范围
Repetition
重复
Grouping, Optional
分组，可选
Concatenation
串联
Alternative
可供替代的
Use of the alternative operator, freely mixed with concatenations, can be confusing.
使用替代运算符（与串联自由混合）可能会令人困惑。
Again, it is recommended that the grouping operator be used to make explicit concatenation groups.
同样，建议使用分组运算符创建显式连接组。
NOTES:
笔记：
1. This syntax requires a formatting of rules that is relatively strict. Hence, the version of a ruleset included in a specification might need preprocessing to ensure that it can be interpreted by an ABNF parser.
1. 此语法需要相对严格的规则格式。因此，规范中包含的规则集版本可能需要进行预处理，以确保ABNF解析器可以对其进行解释。
2. This syntax uses the rules provided in Appendix B.
2. 此语法使用附录B中提供的规则。
rulelist = 1*( rule / (*c-wsp c-nl) )
rulelist = 1*( rule / (*c-wsp c-nl) )
rule = rulename defined-as elements c-nl ; continues if next line starts ; with white space
规则=定义为元素c-nl的规则名称；如果下一行开始，则继续；带空格
rulename = ALPHA *(ALPHA / DIGIT / "-")
rulename = ALPHA *(ALPHA / DIGIT / "-")
defined-as = *c-wsp ("=" / "=/") *c-wsp
; basic rules definition and
; incremental alternatives
defined-as = *c-wsp ("=" / "=/") *c-wsp
; basic rules definition and
; incremental alternatives
elements = alternation *c-wsp
元素=交替*c-wsp
c-wsp = WSP / (c-nl WSP)
c-wsp=wsp/（c-nl wsp）
c-nl = comment / CRLF ; comment or newline
c-nl=注释/CRLF；评论还是换行
comment = ";" *(WSP / VCHAR) CRLF
comment = ";" *(WSP / VCHAR) CRLF
alternation = concatenation
*(*c-wsp "/" *c-wsp concatenation)
alternation = concatenation
*(*c-wsp "/" *c-wsp concatenation)
concatenation = repetition *(1*c-wsp repetition)
concatenation = repetition *(1*c-wsp repetition)
repetition = [repeat] element
repetition = [repeat] element
repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)
repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)
element = rulename / group / option /
char-val / num-val / prose-val
element = rulename / group / option /
char-val / num-val / prose-val
group = "(" *c-wsp alternation *c-wsp ")"
group = "(" *c-wsp alternation *c-wsp ")"
option = "[" *c-wsp alternation *c-wsp "]"
option = "[" *c-wsp alternation *c-wsp "]"
char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE
; quoted string of SP and VCHAR
; without DQUOTE
char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE
; quoted string of SP and VCHAR
; without DQUOTE
num-val = "%" (bin-val / dec-val / hex-val)
num-val = "%" (bin-val / dec-val / hex-val)
bin-val = "b" 1*BIT
[ 1*("." 1*BIT) / ("-" 1*BIT) ]
; series of concatenated bit values
; or single ONEOF range
bin-val = "b" 1*BIT
[ 1*("." 1*BIT) / ("-" 1*BIT) ]
; series of concatenated bit values
; or single ONEOF range
dec-val = "d" 1*DIGIT
[ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
dec-val = "d" 1*DIGIT
[ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
hex-val = "x" 1*HEXDIG
[ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
hex-val = "x" 1*HEXDIG
[ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
prose-val = "<" *(%x20-3D / %x3F-7E) ">"
; bracketed string of SP and VCHAR
; without angles
; prose description, to be used as
; last resort
prose-val = "<" *(%x20-3D / %x3F-7E) ">"
; bracketed string of SP and VCHAR
; without angles
; prose description, to be used as
; last resort
Security is truly believed to be irrelevant to this document.
安全性确实被认为与本文件无关。
[US-ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII]美国国家标准协会，“编码字符集——信息交换用7位美国标准代码”，ANSI X3.41986。
[RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, November 1977.
[RFC733]Crocker，D.，Vittal，J.，Pogran，K.，和D.Henderson，“ARPA网络文本消息格式标准”，RFC 733，1977年11月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
The syntax for ABNF was originally specified in RFC 733. Ken L. Harrenstien, of SRI International, was responsible for re-coding the BNF into an Augmented BNF that makes the representation smaller and easier to understand.
ABNF的语法最初在RFC 733中指定。SRI国际的Ken L.Harrenstien负责将BNF重新编码为一个增强的BNF，以使表示更小、更容易理解。
This recent project began as a simple effort to cull out the portion of RFC 822 that has been repeatedly cited by non-email specification writers, namely the description of Augmented BNF. Rather than simply and blindly converting the existing text into a separate document, the working group chose to give careful consideration to the deficiencies, as well as benefits, of the existing specification and related specifications made available over the last 15 years, and therefore to pursue enhancement. This turned the project into something rather more ambitious than was first intended. Interestingly, the result is not massively different from that original, although decisions, such as removing the list notation, came as a surprise.
最近的这个项目一开始只是为了剔除RFC 822中被非电子邮件规范作者反复引用的部分，即增强BNF的描述。工作组没有简单和盲目地将现有案文转换成一份单独的文件，而是选择认真考虑现有规范和过去15年来提供的相关规范的缺陷和好处，并因此寻求改进。这使得该项目比最初的预期更加雄心勃勃。有趣的是，结果与最初的结果并没有太大的不同，尽管删除列表符号等决定令人惊讶。
This "separated" version of the specification was part of the DRUMS working group, with significant contributions from Jerome Abela, Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete Resnick, and Henning Schulzrinne.
该规范的“分离”版本是鼓工作组的一部分，Jerome Abela、Harald Alvestrand、Robert Elz、Roger Fajman、Aviva Garrett、Tom Harsch、Dan Kohn、Bill McQuillan、Keith Moore、Chris Newman、Pete Resnick和Henning Schulzrinne做出了重大贡献。
Julian Reschke warrants a special thanks for converting the Draft Standard version to XML source form.
Julian Reschke特别感谢您将标准版本草案转换为XML源格式。
This appendix contains some basic rules that are in common use. Basic rules are in uppercase. Note that these rules are only valid for ABNF encoded in 7-bit ASCII or in characters sets that are a superset of 7-bit ASCII.
本附录包含一些常用的基本规则。基本规则是大写的。请注意，这些规则仅对以7位ASCII编码的ABNF或以7位ASCII超集的字符集编码的ABNF有效。
Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT, ALPHA, etc.
某些基本规则是大写的，例如SP、HTAB、CRLF、DIGIT、ALPHA等。
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
BIT = "0" / "1"
BIT = "0" / "1"
CHAR = %x01-7F
; any 7-bit US-ASCII character,
; excluding NUL
CHAR = %x01-7F
; any 7-bit US-ASCII character,
; excluding NUL
CR = %x0D
; carriage return
CR = %x0D
; carriage return
CRLF = CR LF ; Internet standard newline
CRLF=CRLF；互联网标准新线
CTL = %x00-1F / %x7F
; controls
CTL = %x00-1F / %x7F
; controls
DIGIT = %x30-39
; 0-9
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote)
DQUOTE = %x22
; " (Double Quote)
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB = %x09
; horizontal tab
HTAB = %x09
; horizontal tab
LF = %x0A
; linefeed
LF = %x0A
; linefeed
LWSP = *(WSP / CRLF WSP)
; Use of this linear-white-space rule
; permits lines containing only white
; space that are no longer legal in
; mail headers and have caused
; interoperability problems in other
; contexts.
; Do not use when defining mail
; headers and use with caution in
; other contexts.
LWSP = *(WSP / CRLF WSP)
; Use of this linear-white-space rule
; permits lines containing only white
; space that are no longer legal in
; mail headers and have caused
; interoperability problems in other
; contexts.
; Do not use when defining mail
; headers and use with caution in
; other contexts.
OCTET = %x00-FF
; 8 bits of data
OCTET = %x00-FF
; 8 bits of data
SP = %x20
SP = %x20
VCHAR = %x21-7E
; visible (printing) characters
VCHAR = %x21-7E
; visible (printing) characters
WSP = SP / HTAB ; white space
WSP=SP/HTAB；空白
Externally, data are represented as "network virtual ASCII" (namely, 7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to zero. A string of values is in "network byte order", in which the higher-valued bytes are represented on the left-hand side and are sent over the network first.
在外部，数据表示为“网络虚拟ASCII”（即8位字段中的7位US-ASCII），高位（第8位）设置为零。一个值字符串是“网络字节顺序”，其中较高值的字节在左侧表示，并首先通过网络发送。
Authors' Addresses
作者地址
Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 US
戴夫·克罗克（编辑）勃兰登堡互联675美国加利福尼亚州桑尼维尔云杉博士94086
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Paul Overell THUS plc. 1/2 Berkeley Square, 99 Berkeley Street Glasgow G3 7HR UK
保罗·奥威尔。英国格拉斯哥G3 7小时伯克利街99号伯克利广场1/2
EMail: paul.overell@thus.net
EMail: paul.overell@thus.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.