/
299.txt
257 lines (193 loc) · 10.5 KB
/
299.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
[1] [[RFC 2234]] の [DFN[[[ABNF]]]] (増補 BNF)
は、非常によく用いられていた [[RFC 822]]
の ABNF を整理・拡張して独立な仕様としたものです。
RFC 2234 は [[IETF]] の[[提案標準]]となっており、
新しい IETF の規格を中心によく利用されています。
[2] 仕様書:
- [[RFC 2234]]
<urn:ietf:rfc:2234>
[12]
改訂版の [[RFC 4234]] が発行されました。
([[名無しさん]] [WEAK[2005-10-16 05:55:41 +00:00]])
[18]
[[RFC 4234]] は更に改訂され、 [[RFC 5234]] ([[インターネット標準]] [[STD 68]])
となりました。(差異については [[RFC 5234]] の項を参照。)
* 仕様書
[REFS[
- [26] [CITE@en[RFC 7405 - Case-Sensitive String Support in ABNF]] ([TIME[2014-12-24 15:03:44 +09:00]] 版) <https://tools.ietf.org/html/rfc7405>
]REFS]
* 文字列リテラル
[27] [[終端]]である [[ASCII]] [[文字列]]について、 [[RFC 2234]]/[[RFC 4234]]/[[RFC 5234]]
は ([[RFC 822]] から引き継いだ) [CODE["]] で括る構文を規定しています。
この場合、[[ASCII大文字・小文字不区別]]を表しています。
[EG[
[28] [CODE["yes"]] は、 [CODE[yes]], [CODE[YES]], [CODE[YeS]] などを表します。
]EG]
[30] [[引用符]]内には、[[ASCII印字可能文字]]のうち [CODE[[["]]]]
以外のものを0文字以上含めることができます。
[FIG(railroad)[
= [CODE(char)[[["]]]]
= *
== |
=== [CODE(char)[[[U+0020]]]]
=== [CODE(char)[[[U+0021]]]]
=== [CODE(char)[[[U+0023]]]]...[CODE(char)[[[U+007E]]]]
= [CODE(char)[[["]]]]
]FIG]
[29] [DFN[[[RFC 7405]]]] はこの構文を拡張し、直前に [DFN[[CODE(ABNF)[[[%i]]]]]]
をつけて[[ASCII大文字・小文字不区別]]を、 [DFN[[CODE(ABNF)[[[%s]]]]]]
をつけて[[大文字・小文字区別]]を表すこととしました [SRC[>>26]]。
なおこの [CODE[i]] と [CODE[s]] も[[ASCII大文字・小文字不区別]]です [SRC[>>26]]。
[FIG(railroad)[
= ?
== [CODE(char)[[[%]]]]
== |
=== [CODE(char)[[[s]]]]
=== [CODE(char)[[[S]]]]
=== [CODE(char)[[[i]]]]
=== [CODE(char)[[[I]]]]
= 引用符で括られた文字列
]FIG]
* 他の仕様書の参照
[34] 他の[[仕様書]]で定義された[[生成規則]]を参照する時に、
[[自然言語]]による説明を表す [CODE[< ... >]] 構文を使うことがあります。
[FIG(quote)[
[FIGCAPTION[
[33] [CITE@en[RFC 7838 - HTTP Alternative Services]]
([TIME[2016-04-17 23:25:39 +09:00]] 版)
<https://tools.ietf.org/html/rfc7838>
]FIGCAPTION]
> OWS = <OWS, see '''['''RFC7230''']''', Section 3.2.3>
> delta-seconds = <delta-seconds; see '''['''RFC7234''']''', Section 1.2.1>
]FIG]
[35] 記述方法に特に規定はなく、 [[RFC 7838]] の例 (>>33)
のように同じ文書でも表記が揺れているものもあったりします。
* 変種
[5] RFC 2234 では[[二重引用符]]で括った[[引用文字列]]は大文字・
小文字を区別しないと定義していますが、その解釈を変えて、
大文字・小文字は区別するとしている仕様書もあります。
- [[RFC 3862]] ([[CPIM]])
- [[RFC 5147]] ([[[CODE(MIME)@en[text/plain]]の素片識別子]])
[6] [[P3P]] で使われている ABNF は RFC 2234 の ABNF の変種です。
詳しくは [[P3PのABNF]] の項を参照してください。
[10] [[RFC 3080]] [SRC[>>17]] と [[RFC 3391]] では [SAMP(ABNF)[0..2147483647]]
のように、整数の範囲指定が使われています。
[16] ちなみに、 RFC 3391 は [[MIME]] 式の ABNF も使っています。
[9]
[[RFC 3981]] など [[IRIS]] RFC では
[PRE(ABNF example)[
unreserved = // as specified by RFC2396
]PRE]
... のように他の規格で定義されていることを表す表現が
[WEAK[(undocumented で)]] 使われています。
[21] [[RFC 3080]] では
[PRE(ABNF example)[
mapping = ;; each transport mapping may define additional frames
]PRE]
... のような表記も使われています [SRC[>>17]]。
;; [14] 変種については [[ABNF]] の項も参照してください。
[REFS[
- [17] [CITE@en[RFC 3080 - The Blocks Extensible Exchange Protocol Core]] ([TIME[2014-08-17 14:28:11 +09:00]] 版) <http://tools.ietf.org/html/rfc3080#section-2.2.1>
]REFS]
[25] [[媒体素片]]の仕様書 [SRC[>>24]] は [[ABNF]] のような方法で構文を記述していますが、
それが何であるのかは明記していません。ただ [[RFC 3986]] を参照しており、
[[IETF]] の [[ABNF]] との類似性を感じさせます。
>
[PRE(ABNF code)[
name = fragment - "&" - "="
]PRE]
... のような構文により使用できない[[文字]]を記述しているようです (が説明がありません)。
[CODE[-]] の左辺は[[文字列]]で、右辺が[[文字]]であることにも注意が必要です。
(右辺の[[文字列]]が認められないのではなく、右辺の[[文字]]を含む文字列が認められないと解釈するのが自然でしょう。)
[REFS[
- [24] [CITE@en-us[Media Fragments URI 1.0 (basic)]] ([TIME[2012-09-27 23:08:40 +09:00]] 版) <http://www.w3.org/TR/media-frags/#general-structure>
]REFS]
* 意味的な変種
[3] RFC 2234 では ABNF によって定義されるものが
([CODE(charset)[[[US-ASCII]]]] を用いた)
[[オクテット列]]または[[ビット列]]としています。
しかし、[[符号化文字集合]]とは独立に[[文字列]]だけを定義したい場合や、
符号化文字集合が [[ASCII]] 以外である場合にも ABNF
を使いたいという要求があります。そのため、 RFC 2234
を参照しながらもこの辺の解釈を変えている仕様書も少なからずあります。
[4] [[RFC 3986]] ([[URI]] 4[SUP[th]]) は、
[[URI]] は符号化からは独立した文字列として定義されるとしています。
RFC 3986 における ABNF は、それによって定義されるオクテット列
[WEAK[(の集合)]] に ASCII で対応する文字列 [WEAK[(の集合)]]
であるとしています。
[8] 同様に [[RFC 3987]] ([[IRI]]) は ABNF
の終端を [[UCS]] としています。
[6] [[RFC 3676]] ([CODE(MIME)[[[text/plain]]; [[format]]=[[flowed]]]])
は [CODE(MIME)[[[charset]]]] 引数によって実際の[[オクテット列]]は変わってくることを指摘しています
[WEAK[(が不完全です)]]。
[20] [[HTML5]] は「[[文字集合]]は [[Unicode]]」としつつ [[ABNF]] を利用しています。
;; [CITE@en-US-x-hixie[HTML 5]] ([TIME[2009-08-01 09:07:43 +09:00]] 版) <http://www.whatwg.org/specs/web-apps/current-work/#inline-documentation-for-external-scripts>
[7] この他、元の仕様が厳密に意味的に RFC 2234 に従って
US-ASCII のオクテット列として定義していても、
それを引用している仕様がそうでなかったりすることもあります。
例えば [[RFC 3066]] の[[言語札]]の構文は RFC 2234 の ABNF
で記述されていますが、言語札を採用している仕様がすべて
US-ASCII のオクテット列による表現を使っているわけではありません。
ほとんどの場合、そのような違いは読めばわかるからか明確に規定されていることはありません。
[15]
[[RFC 4646]] ([[言語札]]) は [[RFC 4234]] を参照していますが、
終端は[[オクテット]]ではなく、[[文字]]だとしています。
[22] 古くからの慣習で、[[空白]] ([[LWSP]] や [[FWS]] など)
の挿入を省略しているものもあります。そのような仕様の中には、
どこに[[空白]]が挿入されるのかを明記していないものも少なくありません。
;; [23] 例えば [[RFC 6690]] は[[空白]]を構文に明記していません。
* メモ
[11] RFC 2234 ABNF を使う場合で、終端として文字列表記
(引用文字列) を使う時は、大文字・小文字の区別の有無を
[WEAK[(区別ありであれ、なしであれ)]] 明記しておいた方が安全です。
[13]
[[RFC 3986]] では[[空文字列]]たることを明示するために
[CODE(ABNF example)@en[0<pchar>]] のような表現を使っています。
* 詐称
[19] [[W3C]] の仕様書の中には [[RFC 2234のABNF]] であるとしながらも実際には [[XMLのEBNF]]
を採用していることがあります。 [[XMLのEBNF]] や [[LEIRIのABNF]] の項をご覧ください。
[FIG(quote)[
[FIGCAPTION[
[31] [CITE@en[RFC 6455 - The WebSocket Protocol]]
([TIME[2015-03-11 20:42:50 +09:00]] 版)
<http://tools.ietf.org/html/rfc6455#section-5.2>
]FIGCAPTION]
> the ABNF in this section is
> operating on groups of bits. The length of each group of bits is
> indicated in a comment. When encoded on the wire, the most
> significant bit is the leftmost in the ABNF
]FIG]
[FIG(quote)[
[FIGCAPTION[
[32] [CITE@en[RFC 6455 - The WebSocket Protocol]]
([TIME[2015-03-11 20:42:50 +09:00]] 版)
<http://tools.ietf.org/html/rfc6455#section-5.2>
]FIGCAPTION]
> The base framing protocol is formally defined by the following ABNF
> '''['''RFC5234''']'''. It is important to note that the representation of this
> data is binary, not ASCII characters. As such, a field with a length
> of 1 bit that takes values %x0 / %x1 is represented as a single bit
> whose value is 0 or 1, not a full byte (octet) that stands for the
> characters "0" or "1" in the ASCII encoding. A field with a length
> of 4 bits with values between %x0-F again is represented by 4 bits,
> again NOT by an ASCII character or full byte (octet) with these
> values. '''['''RFC5234''']''' does not specify a character encoding: "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." Here, the
> specified encoding is a binary encoding where each terminal value is
> encoded in the specified number of bits, which varies for each field.
]FIG]
[36] [CITE@en[RFC 7950 - The YANG 1.1 Data Modeling Language]]
([TIME[2016-09-15 03:32:37 +09:00]])
<https://tools.ietf.org/html/rfc7950#page-206>
[FIG(quote)[
[FIGCAPTION[
[37] [CITE@en[RFC 3651 - Handle System Namespace and Service Definition]]
([TIME[2016-11-06 19:13:47 +09:00]])
<https://tools.ietf.org/html/rfc3651>
]FIGCAPTION]
> <Handle> = <NamingAuthority> "/" <LocalName>
> <NamingAuthority> = *(<NamingAuthority> ".") <NAsegment>
]FIG]