Yahoo! mail の文字化け

Yahoo! mail（日本語版） を使っ て書かれた日本語の電子メールを受け取ると、ときどき文字化けしていることが あります。ここでは、文字化けが発生する条件と、化けてしまったメールを受け 取ったときの復元法について考察します。

なお、私自身は Yahoo! mail は使っていませんので、以下の内容はかなり推 測を含んでいます。正確性その他についての保証は一切いたしませんので、あく まで参考としてご覧くださるようお願いいたします。

文字化け発生

Yahoo! mail で書かれた日本語の電子メールを受け取ると、ときどき文字化 けしていることがあります。経験上、１行を改行せずに長く書いたときに文字化 けが発生しやすい傾向があるようです。

手元では10通強に渡って「１行が長いこと」に起因すると思われる文字化け が発生しているサンプルがあるのですが、それは１通の例外を除き、すべて以 下の特徴を共有しています。

1. 文字コードが日本語 EUC になっている。
2. 文字化けは行末で起き、さらに次の行が行頭から派手に文字化けしてまっ たく読めず、ASCII 文字か行末に達するまで文字化けは回復しない。
3. 文字化けが始まる行では、行頭から998バイト過ぎた所で行が切られる（改 行（\n）が入って行末になっている）。
4. 前項の、行末の改行（\n）を削除して、次の行とつなげると、正しく読め るようになる。
5. つまり、EUC の２バイト文字の途中に改行が挿入されるため、文字化けが 発生している。

第1項については、正確にはこうです。multipart/alternative の MIME 形式 で、plain text と html が一緒になってやってくるのですが、文字化けを含 んでいる方の part は日本語 EUC になっていて（charset を iso-2022-jp と宣 言していながら）、含んでいない方の part は正しく JIS コードで記述されて います。

上述の「ただ１通の例外」は、行頭から のバイト数が異なるだけで、他の特徴については同じでした。ひどい 思い違いをしていました。もう一度見てみたところ、その１通の中で発生し ていた６ヶ所の文字化けはすべて

• 文字コードは JIS コード。
• 行頭からのバイト数は、すべて989バイト。
• その点で、「! \n SPC」の３文字（16進数表示で 21 0A 20 の３バイト） が挿入されている。

という理由により発生していたものでした。この１通に ついては、以下の考察から除外することにします。

上の特徴から判断して、Yahoo! mail での日本語メールの内部的取り扱いは、 おおよそ次のようになっていると推察されます。

1. 内部コードとして用いられている日本語コードは、日本語 EUC。
2. 何らかの理由で、内部コードの段階で行頭から998バイトが過ぎると自動的 に改行（\n）が挿入されるようになっている（他に何か条件が揃う必要が あるのかもしれない）。
3. その際、２バイト文字の途中に改行が入ってしまうと、日本語 EUC の文書 として規格に反する文書になってしまうが、送信に当たって JIS コード への変換を行う部分の処理が、文字コードを厳格に判定するようになって いて、１ヶ所でも不備があると文書全体（multipart の part 全体）にわ たって変換を放棄するようになっている（これも、他に何か条件があるの かもしれない）。

第2項の「何らかの理由」というのは、大方本家の英語版 Yahoo! mail で 「1000バイト以上の長い行は、読みやすくするため998バイト目で改行する」と いうような、多バイト文字のことなんかまるっきり考えていない杜撰な 仕様になっていて、それをそのまま使っている、といった所なのでしょう。

修復ツール

前項の考察に基づいて、「EUC の２バイト文字の途中で入ってしまった改行 を取り除く」ような script を作ったところ、正しく動作しているようですので 公開いたします。他に同じ症例で困っている方がもしいるようでしたら、お役に 立てば幸いです。

かなりいい加減な perl script で、EUC コードの範囲の判定は厳密ではあり ません。また、２バイトの EUC 文字しか考慮していません。JIS 補助漢字など、 ３バイト以上の EUC 文字の、２バイト目以降に改行が割り込んでしまった場合 は正しく復元できないものと推測されます。

動作はまったく無保証です。使用する場合は、元のメールのバックアップを 必ずとった上で、自己責任でお使いください。なお、perl script である以上、 perl がないシステム上では当然動きません。念のため。

ファイル中に簡単な使用法を書きましたが、文字コードの変換は行っていま せん。この script で文字化けを修復した上で、別のツールで JIS コードへの 変換を行ってください。その場合、EUC と JIS が混在している文書でも正しく JIS コードに変換できるものを用いてください。私が手元で用いている ack は 問題なく動作してくれるようです。

また、本来もっとスマートに書けるのでしょう。お目汚し、お恥ずかしい限 りです。

その他、Yahoo! mail と日本語について

一度添付ファイルを送ってもらったとき、ファイル名に日本語が使われてい たのですが、Content-Disposition: フィールドにファイル名が日本語 EUC でそのまま書かれていたのにはびっくりさせられました。

また、charset として iso-2022-jp を宣言していながら、「半角カナ」の交 じった文書も送って来るようです。ESC ( I の escape sequence はちゃんと入っ ているようなので、JIS コードに真面目に対応したメーラーなら問題なく表示で きるでしょうが、文字コードを厳格に取り扱うメーラーだと、おかしな表示にな ることもありえます。

それから、一度ヘッダーの日付部分に、曜日が漢字で書いてあったことがあ りました。daemon 起動時に日本語 locale が設定されてるって、それってどう なのよ…（笑）。

ここで書いて来た一連の事例はしばらく前のことだったので、最近はまた改 善されているのかもしれませんが、少なくとも 2006年の８月頃までは、Yahoo! mail での日本語の取り扱いにはまだ怪しい所が少なからず残っていたようです。