[61] encoded-word は、電子メールや MIME のヘッダーで用いられる、文字列の符号化のための構文です。
[62] 電子メールのヘッダーで非ASCII文字を安全に取り扱うための構文として開発され、 MIME の一部となりました。
encoded-word = "=?" charset ["*" language] "?" encoding "?" encoded-text "?="
; RFC 2231 では「"?" encoding」欠落。 http://www.rfc-editor.org/errata.html
charset = <registered character set name> ; RFC 2047 では token
language = <registered language tag [RFC-1766]> ; RFC 2047 では token
encoding = token ; see section 4
token = 1*<Any CHAR except SPACE, CTLs, and especials>
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
encoded-text = 1*<Any printable ASCII character other than "?"
or SPACE>
; (but see "Use of encoded-words in message
; headers", section 5)「ABC」
「"=?us-ascii?q?ABC?="」
構造化領域では、 quoted-string 内で encoded-word は使えない。非構造化領域では、隣接文字と WSP で離す必要がある。
構造化領域で word の代わりに phrase の一部として出現する 時は「" =?us-ascii?q?ABC?= "」。 comment や非構造化領域では 「" ABC "」 。
構造化領域 (で comment として認められる) 場合 「(ABC)」。 非構造化領域の場合「(=?us-ascii?q?ABC?=)」。
comment の場合は周りの括弧と encoded-word がくっついても良い。
「( ABC )」。
非構造化領域では周りの文字と離す必要があるので、こうする。 comment では、 RFC 2047 に記述はないが、 WSP がそのまま残ると思われる。 (記述が無いということは、例外ではないということでしょう。)
「(=?ISO-8859-1?Q?a?=b)」。
非構造化領域では周りの文字と離さないと encoded-word にならない。 comment では「b」と離さないといけない。
comment の場合 「(a b)」。非構造化領域では 「(=?ISO-8859-1?Q?a?= b)」。
「ab」。
encoded-word 間の (F)WSP は無視される。
「a b」。
encoded-word 間に当たる場所に WSP を入れるには、 どっちかの encoded-word に含めるか、一つにまとめる。
「=?us-ascii?q?ABC?=, DEF」
構造化領域で phrase 内の word の代わりであっても、 encoded-word との区切りに WSP が必要。
「=?us-ascii?q?ABC?=DEF」
同じく。
「ABC DEF」。
これは正しく復号できる。
「=?us-ascii?q?ABC?==?us-ascii?q?DEF?=」。
RFC 2047 の解読処理手順に従うとまず長い一つの encoded-word と 考えるが、 encoded-word 文法に合致しないので、普通の文字列とする。
「=?us-ascii?q?ABC DEF?=」。
encoded-word 文法に合致しない。
encoded-word の使用の有無
電子メイル, 電子ニュースにおいて、
encoded-word が使われているか識別する方法はない。
MIME-Version:欄の有無で識別出来るとする考え方もあるが、仕様によればこれは関係ない。
(RFC 2047 参照) RFC 1342 の公布の月の前後で区別するとか? :-pquoted-string 内
quoted-string 中に encoded-word
もどきを入れる実装がある。それを解読する実装もある。どっちも違法。
但しそれを正当化する仕様も一部ある。 (See Content-Disposition:欄,
quoted-string (>>75)。)[2] 空白間隔の扱いについて色々問題が。 「ABCあいう」という文字列があるとき、これを符号化するには「ABC」も含めないと、間に間隔が入ったり入らなかったり。
[3] encoded-word の周りの間隔についての話は RFC 1342 に無くて、その時以来の実装や手抜き実装は間隔を
(無視していけないのに) 無視したり (無視しないといけないのに) 無視しなかったりする。
しかも単語中だろうがお構いなしにする (RFC 2047 的には妥当だが。)
から、 Subject 中になぜか間隔があって、しかも返信するごとにそれが増えていったりする。
[7] comment 内の encoded-word の解読は厄介。 quoted-pair の unquote と encoded-word の解読のどちらを先にするか。 pair を先にすると encoded-word もどきが出てくる可能性がある。 word を先にすると pair もどきが出てくる可能性がある。だから両方一度にまとめるしかない。
[8] comment 内の encoded-word は linear-white-space で他の ccontent と離すことになっている。でも RFC 822 では comment 内に lws は出現しないはずだ。 (0x09 や 0x20 は ctext に含まれる。)
[9] >>8 上記の解釈は(たぶん)誤り。 ctext は linear-white-space (SP や HTAB そのもの ではなく) を包含している。 RFC 2822 では ctext から lws を追い出して、 ccontent に FWS を入れてもいいと明示。 See comment(注釈)
[10] comment 内の encoded-word は「(」「)」とくっつけることが出来る。 では、 nest した comment の外側とはくっつけることが出来るのか。 (例>>11)
RFC 2047 には明記はない。 BNF は linear-white-space については当てにならない。
考え方としては、 encoded-word
のすぐ外側の括弧にはつけることが出来るとするのが自然と思われる。
つまり >>1 は不正であって encoded-word ではない。
[47] でも encoded-word の本来の意図は非ASCII文字を含む
「word にしたいもの」を
RFC 822 の atom になるように符号化することでしょうから、
まず RFC 822 に従い字句解析を行い、その結果が
encoded-word の構文に合致すれば復号するというのが本来の意図に沿った動作でしょう。
[12] RFC 2047 には次のような記述がある。
この直前には、非構造化領域 (*text), comment, phrase 中の word の置き換え としてのみ encoded-word が使える、と書いてある。 その補足が上記の表なんだけど。疑問点:
わざわざ注記してあるってことは、例外で使ってはいけないのかもしれないし、 あるいは単なるミスなのか。
encoded-word を使わなければならず、解読しなければなりません。 (4.4.1, 8.2)[6] RFC 2616 までは符号化語が HTTP ヘッダーの一部で使えることになっていました。 しかし実際には誰も実装していませんでした。この規定は RFC 723x では削除されています。
TEXT ;; RFC 2616 2.2warn-text = quoted-string ;; RFC 2616 14.46 Warning:欄The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 [22] only when encoded according to the rules of RFC 2047 [14].
TEXT 規則は記述的な欄内容及び値であってメッセージ解析器により解釈されることを意図していないものににも使うことが出来ます。 *TEXT の言葉は、 RFC 2047 の規則に従って符号化される場合に限って ISO-8859-1 以外の文字集合の文字を含めても構いません。 (RFC 2616 2.2)
- TEXT = <any OCTET except CTLs, but including LWS>
>>14 RFC 2616 の「メッセージ解析器により解釈されることを意図していないもの」
をどう解釈するのが良いのか分かりませんが、とりあえず TEXT
が使われているのは、
ctext = <any TEXT excluding "(" and ")">)qdtext = <any TEXT except <">>Reason-Phrase = *<TEXT, excluding CR, LF>)です。このうち quoted-string で使えるのはどんなもんかと思いますな。
[17] >>16 Warning:欄で使われる warn-text = quoted-string
は「If a character set other than ISO-8859-1 is used, it MUST be encoded
in the warn-text using the method described in RFC 2047 [14].」と、
>>15 同様に規定されています。
[35] RFC 2231 で encoded-word の構文が拡張され、
charset の後に * と言語タグを指定できるようになりました >>51, >>56。
[53] 一つの encoded-word では1つの言語しか指定できませんが、
encoded-word の長さは任意に短くできるので、
文字列の任意の部分に任意の言語タグを指定することができます。
[36] ietf-822 や ietf-usefor で MIMEr は、生 UTF-8 header
なんて認められん、 encoded-word
の言語指定の分情報損失じゃないか、と言ってます。
それに対して CharlesLindsey は、どうしても使いたいんなら Unicode 言語タグでも使ってろホ゛ケェと言ってます。 MIME'r よ、お前ら単に7ビットと言いたいだけちゃうんかとか、言語タグとか本気で言ってるのかこの Unicoder めとか、そういう話は置いといて、実際に言語指定に対応した UA とか、言語指定が付いたメッセージなんてどれだけ存在するのか。
mail-people は特に何も言ってこないし、 Charles
はあったとしても日本か中国くらいじゃない? と言っている。
しかし日本でも中国でも、言語指定のあるメッセージなんて見たことが無いよね。
1468bis は ISO-2022-JP な encoded-word で言語指定は使うなとまで言っているのでして。
そもそも日本のほとんどの実装は、 encoded-word
対応といっても ISO-2022-JP の B 符号化にしか対応してないのが普通だったりもしますからな。
(ひどいのになると、 ISO-2022-JP や B
の大文字・小文字の区別をしないのとかもある。)
[37] ということからして、この世界に実質的に encoded-word
の言語指定なんて使ったメッセージは存在しないのでは、と強く疑われます。
[38] >>37 manakai みたいに言語情報をちゃんと扱える UA は他にもあるはずだけど、それを有意義に使えているかどうか。 (manakai は捨ててる同然だし、生成の時には使えないし。)
[39] >>38 生成側としては、言語情報をそもそも持っていなければつけようが無い。 で、言語情報は実質的に利用者に指定させるしか得る方法がない。 (IM と連携して云々とか考えられるけど、現状では無理だな。)
文脈を検討せずに、設定から自動で得て文字列全体に適用する
(conneg 設定の流用とか。) のだと、 日本語れんしゅうちゅう。
に en とかつけかねないし、きめ細かい実装がないとかえって有害。
[40] 構文解析とか、そういう苦労して言語情報つけた割に得られ得る利点が CJK glyph selection くらい (それもたいして役に立たない。) だと、やっぱり実装する気になんてならないよなあ。
符号化は面倒。特に ISO-2022-JP だったりすると、
とかやややっかいだったり。
encoded-word に触れています。概要は、 MIME への変換では ASCII 以外があれば encoded-word を使い、 MIME からの変換では相手で表現可能なら decode し、そうでなければ encoded-word のままにするというものです。filename parameter 値 (になるもの) のようなものが ASCII 以外の文字を含んでいたら、引用符で囲む (つまり encoded-word にする) か、全部の非 ASCII 文字を疑問符に換えるかしると言っています。encoded-word の扱いについて触れています。[41]
encoded-word で符号化された中身は基本的に何でもありなので、実装は勝手な仮定をしてしまわないように注意する必要があります。
たとえば、 encoded-word
で符号化した中身に改行が含まれていることも十分あり得ます。それを想定していない MUA だと、たとえば Subject の表示の際に画面が乱れる虞があります。
(厳密には RFC 822 では quoted-pair を使って改行を生で表現できますが、まともに使えるかは不明です。ですから多くの MUA は unfold した欄本体に改行が含まれることを想定していないと思われます。)
[55] RFC 2231 は将来文字コードレベルで言語の指定ができるようになるので、 その場合はより柔軟に指定できるそちらの方法を MIME レベルの指定の方法よりも利用するべき >>51 としていましたが、そのような方法は後に取り下げられています。
[65] perl-mailutils/Encoder.pod at master · wakaba/perl-mailutils, https://github.com/wakaba/perl-mailutils/blob/master/lib/EncodedWord/Encoder.pod
encoded-word[48] RFC 2616 までは HTTP でも一部で encoded-word
が使えることになっていましたが、実際には誰も使っていませんでした。
[58] RFC 2231 の HTTP への適応について規定する RFC 5987
は、 encoded-word の HTTP における利用には疑問がある >>57 として、
encoded-word の拡張は採用していません。
[49] RFC 723x でこの規定は完全に削除され、現在では HTTP
では encoded-word は使われていません。
[50] ただし HTTP で multipart/* によって MIME実体を埋め込む場合、
その実体の MIMEヘッダーでは encoded-word
を使うことに (理論上は) なります。しかしこちらもやはり使われていません。
[59] Content-Disposition: ヘッダーの
filename 引数の値として encoded-word
を使う方法は Firefox で実装され、広く使われていましたが、後に削除されました。
Content-Disposition: を参照。[42]
Thunderbird 1.5 には、 Atom で題名に encoded-word のような文字列を使うと、
勝手に復号してしまうという不具合があります。
(Thunderbird 1.5 は Atom を 822
に変換して処理していますが、その際に Subject:
に入れる文字列に encoded-word
のような文字列が含まれていることを想定していないようです。)
(名無しさん 2006-07-22 04:14:28 +00:00)
[43]
encoded-word が quoted-string
内で認められないのはなぜか?
quoted-string
は (引用符と \ と LWS 以外)
文字は (文字通り) 文字通りの意味を持つというものだから、
encoded-word として解釈させようというのはおかしい。encoded-word は人間向けで、
機械向けではない。機械向けの場所でも認めるとすると正規化など問題が難しくなる。で、 filename の場合、
そもそももともとこれはヒントなので、その値を参考にファイル名を決める手段として、
encoded-word のようなものを復号するのもありじゃないの? と Keith Moore はいってます。
(名無しさん 2006-08-13 07:27:23 +00:00)
[44]
NAS (RFC 4707) は、 Usefor が RFC
化されるまで、と断りながらも son-of-RFC 1036
と同じ、 encoded-word
が使える (実際にはまったく使われていない) ニュースグループ名の構文を採用しています。
(名無しさん)
[45]
JavaScript で MIME ヘッダをデコード - bkブログ (2007-10-07 23:20:17 +09:00 版) http://0xcc.net/blog/archives/000185.html
(名無しさん)
[46] JavaScript で MIME ヘッダをデコード - bkブログ ( 版) http://0xcc.net/blog/archives/000185.html
[823] fml は Subject: の encoded-word をいったん復号して
ISO-2022-JP で符号化しなおします。このとき ISO-2022-JP として表せない文字があると、
復号したまま放置するので、結果として文字化けすることがあります。
[824] RFC 6857 - Post-Delivery Message Downgrading for Internationalized Email Messages ( ( 版)) http://tools.ietf.org/html/rfc6857#section-6
[60] draft-klensin-encoded-word-type-u-00 - The "U" Encoding for Encoded-Words in Email ( 版) https://tools.ietf.org/html/draft-klensin-encoded-word-type-u-00
[63] メールの送信元を完璧になりすます「Mailsploit」は何が危険か – 無能ブログ () https://blog.cheena.net/2017/12/07/%E3%83%A1%E3%83%BC%E3%83%AB%E3%81%AE%E9%80%81%E4%BF%A1%E5%85%83%E3%82%92%E5%AE%8C%E7%92%A7%E3%81%AB%E3%81%AA%E3%82%8A%E3%81%99%E3%81%BE%E3%81%99%E3%80%8Cmailsploit%E3%80%8D%E3%81%AF%E4%BD%95%E3%81%8C/
encoded-word間の空白の取り扱いは相互運用性が高くないので、実装によっては言語の区切れ目に空白が現れたり、 返信を繰り返すうちに空白がどんどん増えていったりする危険性もあります。