numaの日記： メールの文字化け

21世紀にもなって、メールの文字化けなんてものに悩まされるとは思わなかったよ。いい加減にしてくれ、AppleでiPhone Mailを作っているお馬鹿さん お利口さん。こっちは文字化けメールをもらって、状況の把握に手間がかかってしようがない。まったく。

問題：

iPhone/iPadから送信された日本語メールが、受信側では文字化けする。送信者が自分で書き込んだ部分は読み取れ、別メッセージから引用された部分が文字化けすることもある。何をどうすれば、そんなことができるのか。わけがわからないよ。

症状：

メール本文の化け方を見る限り、シフトJISで送ってきている。しかし、ヘッダーを見るとContent-Type: text/plain; charset=cp932になっている。 cp932なるcharset名はIANAに登録されていない非標準のものである（登録されているのはShift_JISおよびWindows-31J）ため、受信側では解釈できず、結果的にエラーとなる。これはiPhone Mailの問題であり、受信側の問題ではない。charset指定をShift_JISまたはWindows-31Jにしてくれれば解決する。

解決方法：

ネットを検索したところでは、解決方法には次の2種類がある。

• iPhone Mailの設定を変更し、常にUTF-8で送信するようにする。いまどきUTF-8を解釈できないお馬鹿さんはいないはずだから、これで問題ない。（ケータイのメールは、ゲートウェイで変換してくれるはず。）とっても間違えたような気がするので追記。あちこちのページで見かける「文字エンコーディングをUTF-8に切り替える方法」というのが、Outlookの設定変更のように思える。みんな同じことを書いているからiPhoneのことだと思ったら。受信側を設定させるにしても、なぜOutlookだけ？
• メール本文に、ISO-2022-JP/Shift_JIS/Windows-31J/EUC-JPには存在しないがUnicodeには存在する文字を挿入し、強制的にUTF-8で送信させる。 ただし、ケータイ絵文字はシフトJISに存在する文字とみなされるらしいので、「⌘」など、絵文字にもない文字を使う必要がある。 （実際には、署名にそういう文字を入れておけばよい。）

具体的にどうやって設定するかは、検索すれば山ほど出てくるから、ここでわざわざ説明しない。iPhoneは使ってないから、説明しろと言われても困る。どちらの方法を採用すべきか？　判断できないなら両方やってくれ。

解決方法としては前者のほうが正統的だが、後者の方法を紹介している例が多い。まあ、とにかくUTF-8で送ってくれればいい。

なお、後者の方法は、プログラムの文字エンコーディング自動判別機能に対して、判別が容易な文字を与えて確実に認識させようとするものだ。 こんなad hocなdirty hack（ああ、バッド・ノウハウって言うんだっけ）がいまだに存在して、エンドユーザーの手を煩わせているなんて、信じられない世界だ。

ところで、文字化けといっても、一般人の住む世界（旧陸軍では「地方」、旧海軍では「娑婆」、ネット用語では「リアル」、日本語では「世間」、英語では「Real World」）では2種類の症状をどちらも「文字化け」と称してくれるので性質が悪い。整理すると：

• メールに含まれる文字のうち、絵文字その他、一部の文字が「?」のような別の文字に置き換えられる。
• メールの本文の文字がすべて意味不明の文字に置き換えられ、完全に読解不能の状態になる。

それが、どちらの話なのかはっきりしないままに、auからSoftBankでは化けたとか、Docomoだと症状が違うとか、Outlookのバージョンがどうだとか、Gmailだとどうなったとか、ぐだぐだとした細かい話になって、何を言っているのかわからない。それも、送られてきたメッセージのサンプルもないままに話が進むため、誰がどんな悪さをしているのか、見当もつかない。素人さんの議論を読んでも埒が明かない。

まず、「絵文字だけが化ける」話。こちらは簡単。化けるのは受信側に存在しない文字だから。ない文字は表示できないんだから、あきらめろ。絵文字や顔文字は、他機種には伝わらないと覚悟すべき。

• charset=UTF-8で送信された場合は、受信側では「絵文字であることはわかるがフォントがない」という理由で表示されない。
• charset=Shift_JISで送信された場合は、絵文字がシフトJISの未定義コードポイント（外字用）を使っているため、受信側は「何の文字が送られたかわからない」ので表示できない（charset=Windows-31Jでも同様）。相手によっては、そのコードポイントには別の文字が登録されているために、違う文字が表示されるかもしれない。ケータイ各社間をまたがって送ると、絵文字の再配置をするので、さらに状況がややこしくなる。
• charset=ISO-2022-JPで送信された場合は、そもそもシフトJISで絵文字に使っているコードポイント自体がISO-2022-JPの有効範囲外なので、まともに変換できない。変換できても「文字として解釈できない」から表示できない。
• charset=cp932で送信された場合は、そもそも「何のエンコーディングで送られたかわからない」から、絵文字だけじゃなくてメールのメッセージ全体が化けるのが正常な動作で、化けなかったら奇跡である。

それから、「メッセージ全体が化ける」話。文字エンコーディングが判別できないことから発生する。判別できない理由は、送信側にあったり受信側にあったりする。

• 送信側の問題は、だいたいがcharset指定を間違えること。charset=cp932のように、わざわざ未定義のエンコーディング名をつければ化けること間違いなし。本文とcharset指定の内容が矛盾すれば、やはり化けるが、いまどきそれはないだろう。それよりも、charsetを指定しないという大技のほうがまだありそうだ。
  マルチパートのパートごとでエンコーディングが違うから問題を起こす、という話があるが、個々のパートでcharset指定が正しく行われていれば、それでも問題はないはず。 テキストの途中で文字エンコーディングを変えるなんて反則技をされると、charsetに何を指定すればいいかわからないけれど。
• 受信側の問題は、charset指定を無視して、わざわざ独自動作をしようとすることで起きる。たとえば：
  • 以前のOutlookでは、テキストの添付ファイルの場合にcharset指定を無視して、無条件にWindows-31Jだと解釈し、そのままユーザーに提示するという悪癖があった。Windows-31Jではないエンコーディングで送られてくると、受信したユーザーの観点では文字化けしているようにしか見えない。
  • また、Internet Explorer 6あたりは、サーバー側のcharset指定にかかわらず、常に自動判別を作動させて、ご丁寧にも判別をしくじるという奇行で知られていた。添付したHTMLファイルが化けるというのは、ひょっとしたらこれかもしれない。
  • Eudoraだったかで、添付ファイルにファイル名を指定するフィールドがあって（Content-Disposition: attachment; filename="foo.doc"とか）、ここに日本語ファイル名を指定しようとしてしくじるという、おふざけをかましてくれたことがある。これは、そもそもfilenameにcharsetを指定する方法が規定されていない。

  こんな場合でも、受信側で表示できてしまうことがある。それは、たいてい文字エンコーディングを自動判別する等の小細工をしているはずなので、余計なことをしていない相手に転送したら化けた、とか、別の問題を引き起こす。こうなると完全な2次災害で、犯人探しも容易ではなくなる。

メールやウェブがらみで文字化けするのは、たいていの場合自動判別が絡んでいる。だいたい、自動判別なんてヤクザな機能に頼るから、かえって文字化けが起こるのだ。100%確実に判別できるはずはないから、どうしても誤判別は避けられない（その結果、文字化けする）。だから、勝手に判別しようなんてせず、charsetに指定してある通りに解釈すればいい。charsetの指定と実際の文字エンコーディングが違っていたら？　そんなもの、送ってくるほうが悪いのだから、化けて当然。下手に救済しようとするからややこしくなる。小さな親切、大きなお世話。

そういう余計なお世話ばかりやっているから、自動判別に甘えて、必要なcharset情報をまともに指定しない、あるいは指定されていても無視する奴らが出てくる。頭の良いことをしようとして、頭の悪い結果を招く。ネットワークのトラブルは、すぐには誰が悪いかわからないから、いちいち調べまわる羽目になる。プロトコルをちゃんと守ってくれないとこっちが迷惑するのだ。

自動判別がらみのトラブルは大昔からある。それに対するバッド・ノウハウも。HTMLのコメントに「美乳」と書いておけばEUC-JPとShift_JISとの間の誤判別が起こりにくい、とか。（ところで、何度変換しても「微乳」になるのはなぜ？）

まったく、いつまでたっても進歩しない世界だ。Microsoft Outlookといい、Apple iPhone Mailといい、なんで、どいつもこいつも標準を無視して俺様スタンダードを作るんだ。それも日本オンリーのガラパゴス俺様スタンダード。グローバル企業の名が泣くぞ。こんな連中の相手ばかり、もう疲れたよ。

長い…

[numa (4467)]

死ぬほど長い。こんなもの、読む奴はいるんだろうか。まあ、怒りにまかせて書いたからそうなった部分もあるが。

単に、メジャーかマイナーかという話であれば、少数派はマイナーに決まっているし、それで軽く扱われるのも、まあ、しようがないと諦めはつく。

ところが、今回のような場合、自分のほうが正しく、相手が間違っているのが明白なのに、多数派に押し切られて少数派が割を食うのだ。そして、いちいち間違っている相手に合わせてやる羽目になる。しかも、「俺のところでは問題は起きてない。だから対応してやる必要はない」といわんばかりの態度を示される。これでは、こっちが悪者扱いだ。なんでこうなるんだ。

一回くらいならともかく、こんなのばかりが続くと、ソウルジェムが濁るよ。