*BNF encoded-word = "=?" charset ["*" language] "?" encoding "?" encoded-text "?=" ; RFC 2231 では「"?" encoding」欠落。 charset = ; RFC 2047 では token language = ; RFC 2047 では token encoding = token ; see section 4 token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1* ; (but see "Use of encoded-words in message ; headers", section 5) *変換例 **=?us-ascii?q?ABC?= 「ABC」 **"=?us-ascii?q?ABC?=" 「"=?us-ascii?q?ABC?="」 構造化領域では、 quoted-string 内で encoded-word は使えない。非構造化領域では、隣接文字と WSP で離す必要がある。 **" =?us-ascii?q?ABC?= " 構造化領域で word の代わりに phrase の一部として出現する 時は「" =?us-ascii?q?ABC?= "」。 comment や非構造化領域では 「" ABC "」 。 **(=?us-ascii?q?ABC?=) 構造化領域 (で comment として認められる) 場合 「(ABC)」。 非構造化領域の場合「(=?us-ascii?q?ABC?=)」。 comment の場合は周りの括弧と encoded-word がくっついても良い。 **( =?us-ascii?q?ABC?= ) 「( ABC )」。 非構造化領域では周りの文字と離す必要があるので、こうする。 comment では、 RFC 2047 に記述はないが、 WSP がそのまま残ると思われる。 (記述が無いということは、例外ではないということでしょう。) **(=?ISO-8859-1?Q?a?=b) 「(=?ISO-8859-1?Q?a?=b)」。 非構造化領域では周りの文字と話さないと encoded-word にならない。 comment では「b」と離さないといけない。 **(=?ISO-8859-1?Q?a?= b) comment の場合 「(a b)」。非構造化領域では 「(=?ISO-8859-1?Q?a?= b)」。 **=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?= 「ab」。 encoded-word 間の (F)WSP は無視される。 **=?ISO-8859-1?Q?a_b?= あるいは =?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?= 「a b」。 encoded-word 間に当たる場所に WSP を入れるには、 どっちかの encoded-word に含めるか、一つにまとめる。 **=?us-ascii?q?ABC?=, =?us-ascii?q?DEF?= 「=?us-ascii?q?ABC?=, DEF」 構造化領域で phrase 内の word の代わりであっても、 encoded-word との区切りに WSP が必要。 **=?us-ascii?q?ABC?=DEF 「=?us-ascii?q?ABC?=DEF」 同じく。 **=?us-ascii?q?ABC?= DEF 「ABC DEF」。 これは正しく復号できる。 **=?us-ascii?q?ABC?==?us-ascii?q?DEF?= 「=?us-ascii?q?ABC?==?us-ascii?q?DEF?=」。 RFC 2047 の解読処理手順に従うとまず長い一つの encoded-word と 考えるが、 encoded-word 文法に合致しないので、普通の文字列とする。 **=?us-ascii?q?ABC DEF?= 「=?us-ascii?q?ABC DEF?=」。 encoded-word 文法に合致しない。 *その他実装について 符号化は面倒。特に ISO-2022-JP だったりすると、 -encoded-word は全体で75文字以内にする必要がある。 -ので、長い文字列を切る必要がある。 -その時、最後は ASCII に戻しておく必要がある。 -おっと、切る時には文字の途中で切ってはいけない。 とかやややっかいだったり。 間隔の扱いについて色々問題が。「ABCあいう」という文字列があるとき、 これを符号化するには「ABC」も含めないと、間に間隔が入ったり 入らなかったり。 encoded-word の周りの間隔についての話は RFC 1342 に無くて、 その時以来の実装や手抜き実装は間隔を(無視していけないのに)無視したり (無視しないといけないのに)無視しなかったりする。 しかも単語中だろうがお構いなしにする (RFC 2047 的には妥当。) から、 Subject 中になぜか間隔があって、しかも返信するごとに それが増えていったりする。 encoded-word が使われているか識別する方法はない。 MIME-Version: 領域は関係ない。 (RFC 2047 参照) RFC 1342 の公布の月の前後で区別するとか? :-p quoted-string 中に encoded-word もどきを入れる実装がある。 それを解読する実装もある。どっちも違法。 但しそれを正当化する仕様も一部ある。 See [[Content-Disposition:領域]] comment 内の encoded-word の解読は厄介。 quoted-pair の unquote と encoded-word の解読のどちらを先にするか。 pair を先にすると encoded-word もどきが出てくる可能性がある。 word を先にすると pair もどきが出てくる可能性がある。だから両方一度にまとめるしかない。 comment 内の encoded-word は linear-white-space で他の ccontent と離すことになっている。でも RFC 822 では comment 内に lws は出現しないはずだ。 (0x09 や 0x20 は ctext に含まれる。) 上記の解釈は(たぶん)誤り。 ctext は linear-white-space (SP や HTAB そのもの ではなく) を包含している。 RFC 2822 では ctext から lws を追い出して、 ccontent に FWS を入れてもいいと明示。 See [[comment(注釈)]] comment 内の encoded-word は「(」「)」とくっつけることが出来る。 では、 nest した comment の外側とはくっつけることが出来るのか。 (foo (hoge)=?us-ascii?q?aiueo?= bar) RFC 2047 には明記はない。 BNF は linear-white-space については当てにならない。 考え方としては、 encoded-word のすぐ外側の括弧にはつけることが出来る とするのが自然と思われる。 RFC 2047 には次のような記述がある。 -「encoded-word」は「addr-spec」のどこにも出現しては'''いけません'''。 -「encoded-word」は「quoted-string」中に出現しては'''いけません'''。 -「encoded-word」は Received (受信) 頭領域中で使用しては'''いけません'''。 -「encoded-word」は MIME Content-Type (内容型), Content-Disposition 領域の parameter 中や「comment」や「phrase」内を除くどの構造化領域本体でも使用しては'''いけません'''。 この直前には、非構造化領域 (*text), comment, phrase 中の word の置き換え として'''のみ''' encoded-word が使える、と書いてある。 その補足が上記の表なんだけど。疑問点: -Received: 領域の comment で encoded-word を使っていいのかどーか。 わざわざ注記してあるってことは、例外で使ってはいけないのかもしれないし、 あるいは単なるミスなのか。 *仕様書 -[[RFC1342]] -[[RFC1522]] -[[RFC2047]] -[[RFC2184]] -[[RFC2231]] *SEE ALSO -[[MIME]] --[[RFC2045]] --[[RFC2046]] --[[RFC2047]] --RFC errata -[[文字コード]]