[68] RFC 822メッセージや HTTPメッセージのヘッダーの特定の位置には注釈を挿入できます。
[9] RFC 822 における注釈の構文は、次のように説明できます。 >>61
(
ではじまり、 )
で終わるU+0000
-U+007F
) を使って良い(
と )
は対になっていなければならない (\(
と \)
を除く)(
と対になっている )
の直前が \
ではいけない (\\
を除く)U+0020
か U+0009
が必要U+0009
は非推奨comment = "(" *(ctext / quoted-pair / comment) ")" ctext = <any CHAR excluding "(", ; => may be folded ")", "\" & CR, & including linear-white-space> quoted-pair = "\" CHAR ; may quote any char linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE ; CRLF => folding LWSP-char = SPACE / HTAB ; semantics = SPACE CHAR = <any ASCII character> ; ( 0-177, 0.-127.) CRLF = CR LF LF = <ASCII LF, linefeed> ; ( 12, 10.) CR = <ASCII CR, carriage return> ; ( 15, 13.) SPACE = <ASCII SP, space> ; ( 40, 32.) HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
If a comment is to be "folded" onto multiple lines, then the syntax for folding must be adhered to. (See the "Lexical Analysis of Messages" section on "Folding Long Header Fields" above, and the section on "Case Independence" below.) Note that the official semantics therefore do not "see" any unquoted CRLFs that are in comments, although particular parsing programs may wish to note their presence. For these programs, it would be reasonable to interpret a "CRLF LWSP-char" as being a CRLF that is part of the comment; i.e., the CRLF is kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a backslash followed by a CR followed by a LF) still must be followed by at least one LWSP-char.
[37]
comment
が複数行に「折畳まれている」時は、折畳みの構文をくっつけないといけません。
(上の「長い頭領域の折畳み」の「メッセージの単語分析」の節と、下の「大文字・小文字の区別性」の節を参照。)
従って、公式な意味においては comment
中にある quote されていない
CRLF
を「見る」ことはありません。
但しそうしたものの出現に注意したいと思う解析プログラムもあることでしょう。
そうしたプログラムでは、「CRLF LWSP-char
」を CRLF
が
comment
の一部であると
解釈する、つまり CRLF
は残して, LWSP-char
を棄てるのが適切かもしれません。
Quote された CRLF LWSP-char
(すなわち、 逆斜線に CR
が続いて、 LF
が続くもの)
は依然、最低一つの LWSP-char
が後に続かなければなりません。
[7] 注釈 (comment
) は、
メールプロトコルのサーバーに引き渡すなどの目的で列を再生成する際には、
字句間の区切りとして機能している場合、 SPACE
1つと字句的に等しい >>6 3.4.3.
とされていました。
[8] RFC 822 はこれ以外に注釈が空白と等価であると明言しているところはありません。 厳密に解釈すると実装は注釈を空白と解釈して構いませんが、著者は注釈を生成してはいけないことになります (BNF に一致しないので)。しかしこれは一般的な解釈とは異なります。
[125] RFC822 メッセージでは、 comment
は構造化欄の要素間であればどこにでも挿入出来、 linear-white-space
1個と透過であるとみなされます。
[126] RFC2822 では obsolete-
構文 (受信メッセージ解析用。)
では RFC 822 (>>125) と同じですが、 obsolete-
でない構文
(新規メッセージ送信用。) では特定の場所 (RFC 2822 の ABNF 構文で CFWS
とされた場所。) でしか使えません。
[65] BNF をほぼそのまま正規表現に直したものです。
$822_comment = qr/\((?:[\x00-\x0C\x0E-\x27\x29-\x5B\x5D-\x7F]|(?:(?:\x0D\x0A)?[\x20\x09])+|\\[\x00-\x7F]|(??{${822_comment}}))*\)/
$2822_comment = qr/\((?:(?:(?:[\x09\x20]*\x0D\x0A)?[\x09\x20]+)?(?:[\x01-\x08\x0B\x0C\x0E-\x1F\x21-\x27\x2A-\x5B\x5D-\x7F]|\\[\x00-\x7F]|(??{$2822_comment})))*(?:[\x09\x20]*\x0D\x0A)?[\x09\x20]+\)/;
[66] RFC 2822 ABNF で、 quoted-pair = "\" text / obs-qp となっているけど、 text には obs-text = qr/\x0A?\x0D?([\x00-\x09\x0B\x0C\x0E-\x7F]\x0A?\x0D?)*/ が含まれてるから、これはおかしい。結局のところは全体の構造は破壊しないけど。
[67] いや、実は意図したものなのでは?
[17] RFC 2822 における注釈の構文は、次のように説明できます >>16, >>62。
(
ではじまり、 )
で終わる(
と )
は対になっていなければならない (\(
と \)
を除く)(
と対になっている )
の直前が \
ではいけない (\\
を除く)U+0020
か U+0009
が必要\
のあと U+0000 は理解できなければならない\
のあと CR も理解できなければならない\
のあと LF も理解できなければならないcomment = "(" *([FWS] ccontent) [FWS] ")" FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space obs-FWS ccontent = ctext / quoted-pair / comment ctext = NO-WS-CTL / ; Non white space controls %d33-39 / ; The rest of the US-ASCII %d42-91 / ; characters not including "(", %d93-126 ; ")", or "\" quoted-pair = ("\" text) / obs-qp NO-WS-CTL = %d1-8 / ; US-ASCII control characters %d11 / ; that do not include the %d12 / ; carriage return, line feed, %d14-31 / ; and white space characters %d127 text = %d1-9 / ; Characters excluding CR and LF %d11 / %d12 / %d14-127 / obs-text obs-FWS = 1*WSP *(CRLF 1*WSP) obs-qp = "\" (%d0-127) obs-text = *LF *CR *(obs-char *LF *CR) obs-char = %d0-9 / %d11 / ; %d0-127 except CR and %d12 / %d14-127 ; LF ;; RFC 2234 WSP = SP / HTAB ; white space CRLF = CR LF ; Internet standard newline SP = %x20 ; space HTAB = %x09 ; horizontal tab CR = %x0D ; carriage return LF = %x0A ; linefeed
[63] RFC 2822, RFC 2047 を元に作成。
comment-eword = "(" [FWS] (*ccontent-eword / encoded-word) *(FWS (1*ccontent-eword / encoded-word)) [FWS] ")" ccontent-eword = ctext / quoted-pair / comment-eword
[64] See encoded-word of RFC 2231。
comment = "(" *( ctext / quoted-pair / comment ) ")" ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) obs-text = %x80-FF
[41]
ところがこれでは quoted-pair
と ctext
が区別出来ない。
822 同様に "\"
も除いた方がよさげ。でも直ぐ後に、
The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs.
「単一文字 quote 機構として使ってもよい」と書いてある。 てことは「として使」わなくてもいいてこと?
[42] とか言ってもどーしよーもないので、やっぱり quote 以外には使えないことにする。
[47] quoted-pair
に %x80-FF が使えないことに注意。
[48] RFC1945 によると HTTP/1.0 では quoted-pair
が使えないらしい。
でもって "\"
はふつーに "\"
と解釈されると。
にゃるほど、これが元凶でこーいう変な状況なのね。
[52]
しかしそうなると、 quoted-pair
を正しく扱えない
HTTP/1.0 実装は多そうだ。 (ただ扱えないだけなら文字化け
(のように見える) とかの軽度の問題で済みそうだけど、 "foo\"bar"
みたいな値だと問題だよな。)
[3] HTTP CGI では次のように定義されています >>4。
comment = "(" *( ctext | comment ) ")" ctext = <any TEXT excluding "(" and ")">
[54] HTTP を元にしてる SIP だけど、びみょーに違う。 いやらしーのは HTTP/1.1 と同じ。(たぶん何も考えずに写したんだ。)
[53]
HTTP 派生プロトコルの1つである RTSP/1.0 (RFC 2326) では
comment
は使われていません。
message/global
#✎[2] RFC 5335 により、 message/global
においては UTF-8 の使用が認められるようになりました (RFC 5335 4.3)。
[127] このスレWikiPage, comment と重複なんだが (というかこっちが元祖?)、どうにかならないかな。