本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化程
度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(1997).


目錄
1.介紹 2
2.規則定義 2
2.1規則命名 2
2.2規則格式 3
2.3終結符值 3
2.4外部編碼 4
3.操作符 4
3.1連接規則1規則2 4
3.2選擇 規則1/規則2 4
3.3增式選擇 規則1=/規則2 5
3.4值域選擇 %c##-## 5
3.5序列組 (Rule1Rule2) 5
3.6不定循環 *Rule 5
3.7指定循環 nRule 6
3.8可選序列 [RULE] 6
3.9；注釋 6
3.10操作符優先級 6
4.擴展巴克斯范式形式的擴展巴克斯范式定義 7
5.安全考慮 7
6.附錄A-核心 8
6.1核心規則 8
6.2公共編碼 9
7.致謝 9
8.參考 9
9.作者地址 9
10.完整版權聲明 10

1.介紹
互聯網技術規范經常需要定義一種格式化語法并能自由地使用作者認為是有用的任何符
號。多年來，巴克斯范式（BNF）的一個修訂版，即擴展巴克斯范式(ABNF)，已經在許多互
聯網規范中流行。該版本平衡了壓縮性和簡單性，具有合理的表達能力。在早期的ARPA網
絡中，每個規范都包含了自己的一個擴展巴克斯范式定義。這樣的規范包括電子郵件規范
RFC733和之后的RFC822，這些規范已經成為定義擴展巴克斯范式的公共引用。本文檔將
這些定義分離出來，以供有選擇的引用。可以預言，它也進行了一些修改和增強。
標準巴克斯范式與擴展巴克斯范式的區別包括命名規則，循環，選擇，次序獨立以及值
域。附錄A（核心）提供了一組規則定義和編碼，該規則定義和編碼適用于某些互聯網規范
的核心詞法分析器。作為一種便利，在此給出了這些規則定義和編碼，另一方面，將它從本
文正文中定義的元語言中抽取出來，同時也是將它從它的形式狀態中的分離出來。

2.規則定義
2.1規則命名
一個規則的名字簡而言之就是名字本身；即，一個符號序列，該符號序列以字母打頭，
后跟一個字母或數字或連字符（下劃線）的組合。
注意：規則名大小寫不敏感
規則名<rulename>，<Rulename>，<RULENAME>和<rULENamE>都指同一個規則。
與原版的巴克斯范式不同，擴展巴克斯范式中的中括號（“<”，“>”）不再需要。不過，
無論何時只要中括號有利于辨別規則名字的使用，它們都可以用來包括規則名字。這種表示
典型地用于限制自由格式的行文中規則名字的引用，或是區分結合在字符串中的未用空格符
分割的局部規則，這樣的例子，將在后邊討論循環時給出。
2.2規則格式
一個規則是由下面的序列定義的：
name=elementscrlf
此處<name>指規則名，<elements>指一個或多個規則名或是終結符，<crlf>是行結束標
志，回車符后緊跟換行符。等號將規則名和規則的定義分隔開。元素構成一個或多個規則名
（和/或）值的定義的序列，這些規則名（和/或）值依照本文中定義的各種操作符，如選擇
和循環，結合在一起。
為了視覺舒適，規則定義按左對齊格式。當一個規則需要多行時，連續行要縮進。左對
齊和縮進是相對于擴展巴克斯范式規則首行而言的，不必與文檔左邊界相齊。
2.3終結符值
規則分解成一串終結符值，有時也叫字符。在擴展巴克斯范式中，一個字符僅僅是一個
非負整數。在某些特定環境中，將指定從值到字符集（如ASCII碼）的一個特殊映射（編碼）。
終結符由一個或多個數字字符說明，這些數字字符的基本說明由其他字符顯式指出。以
下的基是目前已經定義的：
b=binary
d=decimal
x=hexadecimal
因此：
CR=%d13
CR=%x0D
分別說明了[US-ASCII]中回車符的十進制和十六進制的表示。
下例是一個連續串值的壓縮表示，使用句點（“.”）來說明在值中的符號間的分隔。因此：
CRLF=%d13.10
擴展巴克斯范式允許在雙引號中直接說明文字文本串。因此：
command="commandstring"
文字文本串解釋為可打印的字符連續集。
注意：擴展巴克斯范式字符串大小寫不敏感，并且這些串的字符集使用us-ascii字符集。
因此：
rulename="abc"
以及：
rulename="aBc"
將與“abc”，“Abc”，“aBc”，“abC”，“ABc”，“aBC”，“AbC”和“ABC”相匹配。
為了說明某個規則是大小寫敏感的，請單獨說明該規則使用的字符。
例如：
rulename=%d97%d98%d99
或
rulename=%d97.98.99
將僅與只由小寫字符abc組成的串匹配。
2.4外部編碼
終結符值的外部表示根據存儲或傳輸環境的限制而變化。因此，基于相同的擴展巴科斯
范式的語法可能有多個外部編碼，如其中之一是7位US-ASCII環境下的；另一個是二進制
八位位組環境下的；當使用16位Unicode編碼時，還會有另一個不同的外部編碼。盡管附
錄A(核心)給出了7位US-ASCII編碼環境的定義，該環境在大多數互聯網應用中很普遍，但
是，編碼細節超出了擴展巴克斯范式的描述范圍。
將外部編碼從語法中分離出來，目的是使得可替換的編碼環境能用于同一語法。

3.操作符

3.1連接規則1規則2
通過列出一系列規則名，一條規則可用于定義一個簡單有序的值串--即，一連串鄰接的
字符。例如：
foo=%x61;a
bar=%x62;b
mumble=foobarfoo
因此規則<mumble>與小寫字符串"aba"匹配。
線性空白字符：連接操作處于擴展巴克斯范式解析模型的核心。一串相鄰的字符（值）
根據擴展巴克斯范式定義的規則進行解析。就互聯網規范而言，過去允許線性空白字符（空
格符和水平制表符）在主結構，如分界特殊字符或原子字符串，兩邊自由發展以及隱含打印。
注意：本擴展巴克斯范式規范沒有提供線性空白字符的隱式規范。
任何希望允許在分界符或字符串兩邊出現線性空白字符的語法必須顯式說明之。對于那
些被更高層規則多次使用的“核心”規則，在其中提供這些空白字符常常是有用的。“核心”
規則可以編入一個詞法分析器中或簡單地作為主規則集的一部分。

3.2選擇 規則1/規則2
由斜杠（“/”）分隔的元素是可選的。
因此，
foo/bar
將接受<foo>或<bar>。
注意：一個包含字母字符的引用串，是用于說明選擇字符的特殊形式，它被解釋為一個
非終結符，該非終結符用所包含的字符，以指定的順序但可以是任意大小寫的混合方式，來
描述組合串集。

3.3增式選擇 規則1=/規則2
在段落中指定一列選擇有時會很方便。即，通過稍后的規則定義增加選擇集，一個初始
規則可能匹配一個或多個選擇。這對于那些源于同一父規則集而其他方面獨立的規范尤其有
用，如常出現于參數列表中。使用如下結構，擴展巴克斯范式允許這樣的增式定義：
oldrule=/additional-alternatives
因此規則集
ruleset=alt1/alt2
ruleset=/alt3
ruleset=/alt4/alt5
與以下說明相同：
ruleset=alt1/alt2/alt3/alt4/alt5

3.4值域選擇 %c##-##
通過使用連字符（“-”）表明可選值域的方式，可以緊縮說明可選數值域。因此：
DIGIT=%x30-39
等同于：
DIGIT="0"/"1"/"2"/"3"/"4"/"5"/"6"/
"7"/"8"/"9"
連接的數值和數值域不能在同一串中說明。一個數值可以用點號連接或使用連字符說明
一個值域。因此，為了在行序列結束之間說明一個可打印的字符，說明格式如下：
char-line=%x0D.0A%x20-7E%x0D.0A

3.5序列組 (Rule1Rule2)
括號里的元素看作一個單一的元素，其內容嚴格排序。因而，
(elemfoo)或(barblat)符合要求。
注意：當選擇由多個規則名或文字組成時，強烈建議使用分組符，而不要依賴“空”間
隔的正確閱讀。
因此推薦用如下形式代替上述形式：
(elemfoo)/(barblat)
該形式可以避免粗心讀者的誤解。
序列分組符也用于在自由行文中將一個元素序列從行文中分隔出來。

3.6不定循環 *Rule
在元素前的操作符“*”表示重復。完整形式為：
<a>*<b>element
此處<a>和<b>是可選的十進制值，表示元素出現至少<a>次，至多<b>次。
默認值是0和無窮，因此*<element>允許任何數字，包括0；1*<element>需要至少1；
3*3<element>只允許3而1*2<element>允許1或2。

3.7指定循環 nRule
如下形式的規則：
<n>element
等同于
<n>*<n>element
即，<element>正好出現<N>次。因而2DIGIT是一個2位數，而3ALPHA是一個3字
母字符串。

3.8可選序列 [RULE]
方括弧包括了一個可選元素序列：
[foobar]
等同于
*1(foobar).

3.9；注釋
分號起始一行注釋直到行末。這是一個簡單的方法，用于在說明中平行地包括有用的注
解。

3.10操作符優先級
上述各種機制具有以下優先級關系，從上到下，優先級依次從高（結合最緊密）到低（結
合最松散）：
字符串，名字格式
注釋
值域
循環
分組，可選項
連接
選擇
隨意混用選擇操作符與連接操作符，會引起混淆。
再次提醒，推薦使用分組操作符顯式表明連接分組。

4.擴展巴克斯范式形式的擴展巴克斯范式定義
本語法使用附錄A（核心）中提供的規則
rulelist=1*(rule/(*c-wspc-nl))
rule=rulenamedefined-aselementsc-nl
；若下一行以空白字符開頭則繼續
rulename=ALPHA*(ALPHA/DIGIT/"-")
defined-as=*c-wsp("="/"=/")*c-wsp
；基本規則定義以及增式選擇
elements=alternation*c-wsp
c-wsp=WSP/(c-nlWSP)
c-nl=comment/CRLF
；注釋或新的一行
comment=";"*(WSP/VCHAR)CRLF
alternation=concatenation
*(*c-wsp"/"*c-wspconcatenation)
concatenation=repetition*(1*c-wsprepetition)
repetition=[repeat]element
repeat=1*DIGIT/(*DIGIT"*"*DIGIT)
element=rulename/group/option/
char-val/num-val/prose-val
group="("*c-wspalternation*c-wsp")"
option="["*c-wspalternation*c-wsp"]"
char-val=DQUOTE*(%x20-21/%x23-7E)DQUOTE
；SP和VCHAR的引用串，不使用DQUOTE
num-val="%"(bin-val/dec-val/hex-val)
bin-val="b"1*BIT
[1*("."1*BIT)/("-"1*BIT)]
；一系列的連續位值或單個ONEOF域
dec-val="d"1*DIGIT
[1*("."1*DIGIT)/("-"1*DIGIT)]
hex-val="x"1*HEXDIG
[1*("."1*HEXDIG)/("-"1*HEXDIG)]
prose-val="<"*(%x20-3D/%x3F-7E)">"
；括起來的SP和VCHAR字符串，不含尖括號
；行文描述，作為最后的方法來使用

5.安全考慮
本文檔確信與安全無關。

6.附錄A-核心
本附錄給出一個特定語法的便捷核心。附錄中的定義可作為規則的核心集使用。

6.1核心規則
某些基本規則使用大寫，如SP,HTAB,CRLF,DIGIT,ALPHA,等等。
ALPHA=%x41-5A/%x61-7A;A-Z/a-z
BIT="0"/"1"
CHAR=%x01-7F
；除NUL以外的任何7位US-ASCII字符
CR=%x0D
；回車
CRLF=CRLF
；互聯網標準格式的換行
CTL=%x00-1F/%x7F
；控制字符
DIGIT=%x30-39
；0-9
DQUOTE=%x22
；"（雙引號）
HEXDIG=DIGIT/"A"/"B"/"C"/"D"/"E"/"F"
HTAB=%x09
；水平制表符
LF=%x0A
；換行
LWSP=*(WSP/CRLFWSP)
；線性空白字符（過去的換行）
OCTET=%x00-FF
；8位數據
SP=%x20
；空格符
VCHAR=%x21-7E
；可見（可打印）字符
WSP=SP/HTAB
；空白字符

6.2公共編碼
形式上，數據被描述成“網絡虛ASCII”，即有8位域的7位US-ASCII編碼，其中最高
位（第8位）置0。值串按“網絡字節順序”排列，高位字節在左邊并且在網絡中首先發送。

7.致謝
擴展巴克斯范式的語法最初在RFC733中說明。SRTInternational的KenL.Harrenstien
負責將巴克斯范式重新編碼成擴展巴克斯范式，這樣使得描述更簡短且更容易理解。
該新近項目始于一項簡單的工作，希望從RFC822中精選出反復被非電子郵件規范作
者引用的部分，即，擴展巴科斯范式的描述。工作組并非簡單盲目地將已存在的文本轉變成
單獨的文檔，而是經過15年對已有規范及相關規范優缺點的仔細考慮，以求進一步提高。
這使項目變得比最初的想法艱巨得多。有趣的是，盡管作出諸如刪除列表符這樣的讓人意外
的決定，結果并非與原作非常的不同。
最近一輪的規范由DRUMS工作組完成，感謝JeromeAbela,HaraldAlvestrand,Robert
Elz,RogerFajman,AvivaGarrett,TomHarsch,DanKohn,BillMcQuillan,KeithMoore,
ChrisNewman,PeteResnick和HenningSchulzrinne的杰出貢獻。

8.參考

[US-ASCII]CodedCharacterSet--7-BitAmericanStandardCodefor
InformationInterchange,ANSIX3.4-1986.

[RFC733]Crocker,D.,Vittal,J.,Pogran,K.,andD.Henderson,
"StandardfortheFormatofARPANetworkTextMessage,"RFC733,
November1977.

[RFC822]Crocker,D.,"StandardfortheFormatofARPAInternetText
Messages",STD11,RFC822,August1982.

9.作者地址
DavidH.CrockerPaulOverell

InternetMailConsortiumDemonInternetLtd
675SpruceDr.DorkingBusinessPark
Sunnyvale,CA94086USADorking
Surrey,RH41HN
UK

Phone:+14082468253
Fax:+14082496205
EMail:dcrocker@imc.orgpaulo@turnpike.com

10.完整版權聲明
Copyright(C)TheInternetSociety(1997).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNET
ENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,
INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHE
INFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIES
OF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.