Augmented BNF for Syntax Specifications: ABNF
構文仕様のための拡張されたBNF: ABNF

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)の現行版とこのプロトコルのステータスを参照してください。このメモの配布は無制限です。

Copyright (C) The Internet Society (1997). All Rights Reserved.

Internet technical specifications often need to define a format 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 have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements.

インターネット技術仕様はしばしば、構文用フォーマットを定義する必要があり、それらの著者が有益であると考えているどのような表記法でも自由に使用します。数年の間に、増大したBNF(ABNF)と呼ばれるバッカス・ナウアの形式(BNF)の修正されたバージョンは多くのインターネット仕様の間で人気がありました。それは合理的な描写的な力と、緊密さと単純性を比較検討します。Arpanet(現在のインターネットの基盤となったネットワーク)の早い日に、各仕様はABNFのそれ自身の定義を含んでいました。これは、ABNFを定義するための共通の引用であるために書かれた電子メール仕様書RFC733、およびRFC822に含まれていました。選択的なリファレンスを許すために、現在の文書はその定義を分離します。これはさらにいくつかの修正および増強が提供されることでしょう。

The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. Appendix A (Core) 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の違いは、規則、繰返し、ほかにとりうる方法、注文独立、および値を範囲と名付けるのを伴っています。付録A(コア)は、いくつかのインターネット仕様書に共通のタイプの中核の語彙の分析、定義および符号づけを規定します。それは便宜として提供され、この文書の本文の中で定義されたメタ言語から分離し、正式な状態から、分離してください。

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).

規則の名前は単に名前自体です。すなわち英字で始まる一連の文字群、英字、数字およびハイフン(ダッシュ)の組み合わせです。

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 will facilitate 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:

規則は次のシーケンスによって定義されます:

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>は1つ以上の定義名かターミナルの詳細であり、<crlf>は行の終わりを示し、終了の行指標(キャリッジリターン(CR)とラインフィード(LF)の組)です。等号は規則の定義から定義名を分けます。要素(elements)は、1つ以上の定義名および(または)値定義のシーケンスを形成します、選択肢と反復のようなこの文書に定義されて、様々な者によって結合しました。

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規則の第1の行に関連があり、文書の左の余白と一致する必要がありません。

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:

ターミナルは、明示的に示された文字の基礎解釈を備えた1つ以上の数値の文字によって指定されます。次の基礎が現在定義されます:

Hence:

従って:

respectively specify the decimal and hexadecimal representation of [US-ASCII] for carriage return.

それぞれ、キャリッジリターン用の[US-ASCII]の10進および16進法の表現です。

A concatenated string of such values is specified compactly, using a period (".") to indicate separation of characters within that value. Hence:

そのような値の連結した文はその値の内の文字の分離を示すためにピリオド(「.」)を使用して、簡潔に指定されます。従って:

ABNF permits specifying literal text string directly, enclosed in quotation-marks. Hence:

ABNFは引用符で囲まれて、文字どおりのテキスト・ストリングを直接指定することを可能にします。従って:

Literal text strings are interpreted as a concatenated set of printable characters.

文字どおりの「command string」は印刷可能な特徴の連結したセットとして解釈されます。

Hence:

従って:

and:

は

will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC" and "ABC".

「abc」,「Abc」,「aBc」,「abC」,「ABc」,「aBC」,「AbC」,「ABC」と一致します。

For example:

例:

or

または

will match only the string which comprises only lowercased 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 A (Core) provides definitions for a 7-bit US-ASCII environment as has been common to much of the Internet.

末尾値の特徴の外部抗議は、記憶装置か送信環境中の制約によって変わるでしょう。従って、16ビットのUnicodeが使用される場合、同じABNFに基づいた文法は、複数の外部のエンコーディング、7ビットUS-ASCIIの環境用の一つ、2進法のオクテット環境用の別のもの、および異なるものを持つかもしれません。詳細のコード化はABNFの範囲外ですが、付録Aはインターネットの多くに共通だったように、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:

規則は規則名のシーケンスのリストにより一連の単純な命じられた値(つまり接触する特徴の連結)を定義することができます。例えば:

Any grammar which 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.

デリミッターあるいはストリング・セグメントのまわりの行の余白を許したいどんな文法も、それを明示的に指定するに違いありません。その後、より高いレベルの規則中に種々に使用される「中核」規則のそのような余白に備えることは多くの場合有用です。「中核」規則は語いのアナライザーを作られるかもしれないし、あるいは単に、主要なrulesetの一部かもしれません。

Elements separated by forward slash ("/") are alternatives. Therefore,

右上がりスラッシュ(「/」)によって分離された要素は代案です。したがって、

will accept <foo> or <bar>.

<foo>あるいは<bar>を受理するでしょう。

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 which derive from the same parent rule set, such as often occurs with parameter lists. ABNF permits this incremental definition through the construct:

片で代わりのリストを指定することは時々便利です。すなわち、最初の規則は代わりのセットへ加えるより遅い規則定義に1つまたはより多くの代わりを、マッチさせるかもしれません。これはパラメータリストと頻繁にのような別の方法で独立した指定のために特に有用同じ親規則セットから生じます。ABNFは構造物を通してこの増加定義を可能にします:

So that the rule set

規則セットのように

is the same as specifying

上記指定は以下と同じです

A range of alternative numeric values can be specified compactly, using dash ("-") to indicate the range of alternative values. Hence:

一連の代替数値価値は代替値の範囲を示すためにダッシュ(「-」)を使用して、簡潔に指定することができます。従って:

is equivalent to:

は次のものと等価です:

Concatenated numeric values and numeric value ranges can not 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:

連結した数値価値および数値の値範囲は同じ文の中で指定することができません。数値の値は連結のために点のある記法を使用するかもしれません。あるいは、それは、1つの値範囲を指定するためにダッシュ記法を使用するかもしれません。従って、ライン・シーケンスの終了間で、1つの印刷可能な文字を指定するために、明細は次の通りであるかもしれません:

Elements enclosed in parentheses are treated as a single element, whose contents are STRICTLY ORDERED. Thus,

括弧で囲まれている要素は単一の要素として扱われる(厳密に並べられる) 。従って、

which matches (elem foo blat) or (elem bar blat).

(elemのfoo bar)または(elemのbar blat)とマッチしています。

matches (elem foo) or (bar blat).

(elemのfoo)または(bar blat)とマッチしています。

Hence it is recommended that instead of the above form, the form:

従って、それは、上記の形式、形式の代わりにそれを推薦されます:

be used. 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:

要素に先行する演算子「*」は反復を示します。十分な形式は次のとおりです:

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

<a>と<b>が任意の10進の数値であるところでは要素の少なくとも<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* 少なくとも1つを要求する;3*3 3つを丁度可能にし、1*2 1つか2つを可能にします。

A rule of the form:

形態の規則:

is equivalent to

以下と同等です

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は一連の3つのアルファベットの文字です。

Square brackets enclose an optional element sequence:

角括弧(「[」と「]」)はオプションの要素シーケンスを囲みます:

is equivalent to

以下と同等です

A semi-colon 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 and loosest at the bottom:

上で説明された様々なメカニズムは以下の先行を持っています。 下部で先端の最も高さ(最もきつく付いて)から最も低く最もゆるくなるまで:

Use of the alternative operator, freely mixed with concatenations can be confusing.

This syntax uses the rules provided in Appendix A (Core).

この規則は、付録A(基本規則)の中で提供される規則を使用します。

Security is truly believed to be irrelevant to this document.

セキュリティは本当にこの文書と無関係であると考えられます。

This Appendix is provided as a convenient core for specific grammars. The definitions may be used as a core set of rules.

この付録は、特定の入門書のための便利なコアとして提供されます。定義は、規則のコア・セットとして使われるかもしれません。

Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT, ALPHA, etc.

ある基礎的な規則は、SP、HTAB、CRLF(ALPHA、DIGIT)(など)のような大文字にあります。

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" with the higher-valued bytes represented on the left-hand side and being sent over the network first.

外面的に、データは、高い(8番目)ビットを0に設定する状態で「ネットワークバーチャルアスキー」(すなわち8ビットフィールドの7ビットのUS-ASCII)として見せられます。より高く評価されたバイトを左の方に表して、最初にネットワークの上に送っている「ネットワークバイトオーダー」には一連の値があります。

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 which 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 available over the last 15 years and therefore to pursue enhancement. This turned the project into something rather more ambitious than first intended. Interestingly the result is not massively different from that original, although decisions such as removing the list notation came as a surprise.

この最近のプロジェクトは、非メール仕様の作家(すなわち増大したBNFの記述)によって繰り返し引用されたRFC 822の部分をえり分ける単純な努力として始まりました。既存のテキストを単に盲目的に個別の文書に変換することではなく、ワーキンググループは、利点と同様に、過去15年にわたって利用可能な既存の明細および関連する仕様書に、不足に注意深い考察を与えて増強を追求することに決めました。これは、意図したプロジェクトを最初よりむしろ大志を抱いているものに変えました。興味深く、リスト記法を削除するような決定は驚きとして起こりましたが、結果はそのオリジナルとは重く異なりません。

The current round of 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.

この仕様書のの作成にあたり、以下の尽力がありました。DRUMSワーキンググループの一部、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.

Copyright (C) The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

この文書およびその翻訳は他のものおよび派生的な工場にコピーされ供給されるかもしれません、そのコメント、の上で、あるいはそうでなければそれについて説明するか、そのインプリメンテーションを助ける、もし上記の著作権通知およびこのパラグラフがすべてのそのようなコピーおよび派生的な工場に含まれていれば、どんな種類の制限なしでも、全体の中で、あるいは一部が、準備されており、コピーされるかもしれないし、公表されるかもしれないし、分配されるかもしれない。しかしながら、この文書はそれ自身著作権のある通知あるいはインターネット学会あるいは他のインターネット組織への言及の削除によってのように任意の方法で修正されないかもしれません、以外は、求められるような、インターネット基準を開発する目的で、その場合には、インターネット基準プロセスの中で定義された著作権のための手続きに続くに違いありません、あるいは求められるような、それを英語以外の言語に翻訳するために

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上に与えられた、制限のある許可は永続し、インターネット学会あるいはその後継者によって無効にされないでしょう、あるいは割り当てます。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

ここに含まれていたこの文書および情報は、「AS IS」方式およびTHE INTERNET SOCIETY AND THE INTERNET ENGINEERINGで提供されます。特別対策本部は保証、急行をすべて放棄するか、あるいは含めて意味しましたしかしない、株式会社、任意の保証に、それ、情報の使用 ここに、権利あるいは市場性あるいは特別の目的に対する適格性のどんな暗黙の保証も侵害しないでしょう。