仕様書

構文

   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)

変換例

encoded-word の出現場所とそれにまつわる問題

• [5] encoded-word の使用の有無 電子メイル, 電子ニュースにおいて、 encoded-word が使われているか識別する方法はない。 MIME-Version:欄の有無で識別出来るとする考え方もあるが、仕様によればこれは関係ない。 (RFC 2047 参照) RFC 1342 の公布の月の前後で区別するとか? :-p
• [4] quoted-string 内 quoted-string 中に encoded-word もどきを入れる実装がある。それを解読する実装もある。どっちも違法。 但しそれを正当化する仕様も一部ある。 (See Content-Disposition:欄, quoted-string。)

[64] application/x-kddi-auc

言語指定

[35] RFC 2231 で encoded-word の構文が拡張され、 charset の後に * と言語タグを指定できるようになりました >>51, >>56。

From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>

[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 は全体で75文字以内にする必要がある。
• ので、長い文字列を切る必要がある。
• その時、最後は ASCII に戻しておく必要がある。
• おっと、切る時には文字の途中で切ってはいけない。

とかやややっかいだったり。

• [23] RFC 822/MIME と X.400 などとの対応を規定する MIXER などの RFCs では、 RFC1495, RFC2156, RFC2157 が encoded-word に触れています。概要は、 MIME への変換では ASCII 以外があれば encoded-word を使い、 MIME からの変換では相手で表現可能なら decode し、そうでなければ encoded-word のままにするというものです。
• [24] >>23 RFC 2157 は、 2.3.1 で、 MIME への変換の際に、 Content-Disposition:欄の filename parameter 値 (になるもの) のようなものが ASCII 以外の文字を含んでいたら、引用符で囲む (つまり encoded-word にする) か、全部の非 ASCII 文字を疑問符に換えるかしると言っています。
• [25] mailto-URL や IMAP はそれぞれの encoded-word の扱いについて触れています。
• [27] 空白間隔ホワイト・スペースの扱いとか、まじめにやろうとするとかなり面倒ですね。
• [28] 特定の charset 専用の en/decoder なら簡単に書けるけど、汎用的なのを作ろうとするとかなりひどい。
• [29] >>27-28 頭の体操にはなるが素人にはお勧めできない。
• [34] >>23-24 これは MIME の規定に反する虞があるんですが、単なるエラー処理で情報損失を防ぐ措置だと考えればまあ許容範囲なのかな。 (RFC2231 の方法が RFC 化される前だし。)

[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, 2023-04-17T09:00:07.000Z https://github.com/wakaba/perl-mailutils/blob/master/lib/EncodedWord/Encoder.pod

歴史

• RFC1342
• RFC1522
• RFC2047
• RFC2184
• RFC2231
• RFC errata http://www.rfc-editor.org/errata.html

めも

[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 内で認められないのはなぜか?

1. 元々 quoted-string は (引用符と \ と LWS 以外) 文字は (文字通り) 文字通りの意味を持つというものだから、 encoded-word として解釈させようというのはおかしい。
2. 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ブログ (2007-10-07 23:20:17 +09:00 版) 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 ( (2013-07-24 10:18:10 +09:00 版)) http://tools.ietf.org/html/rfc6857#section-6

[60] draft-klensin-encoded-word-type-u-00 - The "U" Encoding for Encoded-Words in Email (2016-01-11 02:26:53 +09:00 版) https://tools.ietf.org/html/draft-klensin-encoded-word-type-u-00

[63] メールの送信元を完璧になりすます「Mailsploit」は何が危険か – 無能ブログ (2017-12-07 22:39:57 +09:00) 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/