えてにつき

ここのところ、会社でずっと Outlook のヘルプデスクのようなことをしている。「あの Outlook 嫌いが?」と思う人もいるかもしれないが、サラリーマンなんてのはそんなもので... まぁ、現実には、チームのメンバーが精力的にヘルプデスク作業をこなしてくれるおかげで、僕のところに回ってくるのは文字化け系の解析作業ぐらいだけれど。

ところで、ヘルプデスクの中でみかけた「いまだにそんなっ？」なできごとをひとつ。

X-Mailer: Microsoft Office Outlook 12.0 を名乗るクライアント - おそらくは Outlook 2007 - から送られてくるメールの件名が文字化けする、と報告を受けた。調べてみると Outlook 12.0 とやらは、Subject 行に ISO-2022-JP の文字列をそのまま使っている。B-Encode していない。つまり、一昔前によくみた「Subject の生JIS問題」がふたたび起こっている。

いまだにそんなことするのか。

RFC2822 形式のメールでは、Subject 行は unstructured filed と定義されており、unstructured field に使えるのは US-ASCII (の CR/LF を除く部分)だと明記してある。

2.2. Header Fields

Header fields are lines composed of a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon. A field body may be composed of any US-ASCII characters, except for CR and LF. However, a field body may contain CRLF when used in header "folding" and "unfolding" as described in section 2.2.3. All field bodies MUST conform to the syntax described in sections 3 and 4 of this standard.

2.2.1. Unstructured Header Field Bodies

Some field bodies in this standard are defined simply as "unstructured" (which is specified below as any US-ASCII characters, except for CR and LF) with no further restrictions. These are referred to as unstructured field bodies. Semantically, unstructured field bodies are simply to be treated as a single line of characters with no further processing (except for header "folding" and "unfolding" as described in section 2.2.3).

で、US-ASCII との互換性を意識して設計された(※1) ISO-2022-JP には、RFC2822と衝突するようなシークエンスはない。昔はRFC2822 の Unftructured Field の body に許されるのは US-ASCII の printable部分で、そうなると ISO-2022-JP で使われる ESC (0x1B)が実は衝突する、だとか、そもそも US-ASCII の printable とはなにか、そこに ESC は含まれるのか含まれないのか、という論議がずっとあった。これに決着が付いた、という話は聞いたことがない。たんに勉強不足なんだろうけれど、あれはなんだったんだろう。いまRFC2822を斜め読みするぶんには、ヘッダーの名前は US-ASCII の、コロン(:)を除く printable 部分しか許されない、ヘッダーのボディは US-ASCII の CR / LF を除く部分を使っていいよ、CR / LF はヘッダーを折り返す(header folding)ときに使ってね、と書いてあるだけのように読める。

つまるところ、Subject に許されるシンタックスだけに注目するなら、実は ISO-2022-JP をそのまま使うのは是か否かというと、これはどうも「是」であるような気がする。

いずれにせよ、よしんば Subject 行のシンタックスとしてISO-2022-JP が許されるとしても、「これは ISO-2022-JP のシークエンスとして扱ってほしい」というセマンティクスはそこにはない。US-ASCII の文字が羅列されているだけで、その文字列をどの文字符号化方式として解釈してやらなければならないのか、その情報はどこからも与えられない。ISO-2022-JP のようにも解釈できるシークエンスを書いた人が、それを ISO-2022-JP として解釈してほしいのか、それとも US-ASCII として解釈してほしいのか、それは Subject 行そのものからはうかがい知ることはできない。そして、上に挙げたRFC2822の引用部分には重要な記述がある。もう一度みてみよう。重要なのは太字で下線がついている一文だ。

2.2.1. Unstructured Header Field Bodies

Some field bodies in this standard are defined simply as "unstructured" (which is specified below as any US-ASCII characters, except for CR and LF) with no further restrictions. These are referred to as unstructured field bodies. Semantically, unstructured field bodies are simply to be treated as a single line of characters with no further processing (except for header "folding" and "unfolding" as described in section 2.2.3).

セマンティクスとしては、unstructured field のボディ部分は、単純なキャラクターの連続として扱い、それ以上の処理を施すべきではない、と書かれている。つまり、それが ISO-2022-JP のシークエンスのように見えても、それは US-ASCII として扱うべきだ、(RFC2047 の形式で無い限り)、プロアクティブに「何か別のコード体系」として処理してはならない。

いい加減、Microsoft も実践的な解法に従うべきではないのか。つまり、Subject にRFC2047で定義されたセマンティクスを与えてやればよい。たんに ISO-2022-JP を B-Encoding するだけで達成できる。そして、日本語対応を謳うメールクライアントなら、Subject 行の B-Encoding された ISO-2022-JP なら間違いなくデコードできる(※2)。

僕の手元に Outlook 12 (Outlook 2007?)があるわけではないので、送信者がどのような設定をしているのかはわからない。だが、どのような設定であれ、ISO-2022-JP をベアで(つまり生 JISで) Subject に突っ込むべきではないと思う。そのぐらい、もう Outlook を日本市場に投入して長いのだから、いい加減改めろよな、と思う。