「−」を含むメールの返信が化けて相手に届く

↓これだと思います。

Snow LeopardのMailはUTF-8のメールを量産する

http://d.hatena.ne.jp/NAOI/20091001/1254376037

バグかどうかは微妙ですけれど、要望は伝えていただけるとありがたいです。現状の動作を不便だと感じている人は多いでしょうし。

Gen さんによる書き込み:

この問題(バグだよね)は、既知の問題という認識で良いのでしょうか？

“バグ”ではなく“仕様”ではないでしょうか？ “既知の問題”だと思います。

要するに、Mac OS X 側では標準に準拠した形で文字コード管理をしているのだが、日本においては圧倒的に Windows 仕様の変則的 JIS (ISO-2022-JP) = CP932 でメールのやりとりが行われているために、いくら「こっちが正しいんだ！」と少数派であるアップルが主張しても、マック・ユーザーたちからは「Windows ユーザーから受信したメールが文字化けする！」と要望（抗議）を受け続け、では、と、対応してみると、今度はまた新たな互換性の問題が出てきてしまい、イタチごっこになっているということなのでしょう。

この問題は、ある意味、変則的な JIS (ISO-2022-JP) によるメールのやり取りが一般的な日本語独自の問題であり、日本におけるメールの送受信のデフォルトが Unicode にならない限りはもはや解決のしようが無いと考えています。10年以内に恐らく日本国内のメールのやりとりも Unicode が一般的になると思いますし、ウェブサイトも海外のように Unicode がデフォルトになって行くと思いますが、それまでは、そういうものだと我慢するしかないのでしょう。

それに、最近の日本人は圧倒的に携帯メールしか使わない者が増えてきてますので、Apple Mail から受信したメールが文字化けするという苦情がネットでも溢れています。（面白いことに、そういう苦情を言っている人々は自分が使っている時代遅れの文字コードに頑迷に固執している機器の仕様の方の問題だとは全く考えないようです。）しかし「使えない！」と文句を言っている人々に（それも膨大な数に上るでしょう。最近、iPhone も売れていますし、その結果マックにスイッチする人々も増大していますので、ある意味で“文字化け被害”に遭遇する人々の数も増えているはずです）いくら筋論を主張しても無駄なわけで、そこでアップルは右往左往しながら、どうしたら一番“マシ”になるかの試行錯誤を続けているのだと想像しています。（それが Apple Mail のバージョンアップの度に日本語の文字コードの扱いがコロコロ変わるように見えることの原因になっているのだと思います。）

いま、一番困っているのは、Apple Mail で受信したメールが文字化けしてた場合（しばしば自分が Apple Mail から送信したメール...。Cc で届いたり、メーリングリストで配信されたりですが）、Thunderbird では強制的に表示文字コードを変更することで（一部が文字化けするだけで）読めるようになるのですが、Apple Mail では何をやってもお手上げになることです。Apple Mail で返信メールを作成し（引用部分は全面的に文字化けして何が何だかわかりません）、そこに Thunderbird で同じメールに「返信」して、そこの編集画面を Apple Mail の返信画面にコピペして、一部の文字化けを修正して、手動で Unicode (UTF-8) で送信するように設定して返信するような面倒くさいことをしています...。

アップルと Microsoft と日本の携帯電話のキャリアで話し合って、

1. メールのエンコードは基本的に Unicode とする。（これはいずれ必ずそうなります。）

2. Unicode 化する時にこれまでの実際の運用でブレがあるような文字に関しては、協議の上、今後は合意した対応を導入する。

ということが必用になってくるのだと思います。

LeopardのMailはcharset=CP932を多用しそう - Mac OS Xの文字コード問題に関するメモ

Apple Mailがcharset=CP932のメールを送信する理由がわからない - Mac OS Xの文字コード問題に関するメモ

>“バグ”ではなく“仕様”ではないでしょうか？

少なくとも、iso-2022-jpで表現できる文字しか含まれていないのに、送信元のエンコードを無視してまでutf-8にして送り返すのは、「仕様のバグ(合理性のない仕様)」のように私は思います。

返信においては、原則は元メールのエンコードが合理的ではないでしょうか。

>ある意味、変則的な JIS (ISO-2022-JP) によるメールのやり取り

ユニコードが確立する前には、iso-2022-jpが日本語メールの文字コードスタンダードだったのですから、変則的ではないと思います(shift-JISなら変則的ですけど)。欧米でも、現在の標準的なエンコードはiso-8859-1のままです。たまたま(というか互換性を意図して)iso-8859-1とutf-8は基本文字セット部分で同じコードなので問題が顕在化しないだけでしょう。

そもそもタイトルの「返信が化けて」は化けているわけではなく、先方がutf-8表示に対応できてないだけの話ではありますけど...ちゃんとヘッダにutf-8と明記してあるのですから。

ともあれ、最近はWInユーザから化けてると言われることはめっきり無くなりましたね(ここ2-3年経験してない)。少なくとも私がやり取りする相手はutf-8で困ることは無くなっているように感じています。

メール本文より、添付ファイル名の文字化けがしばしば発生することのほうが私にとっては問題です。

また、zip圧縮ファイルのファイル名エンコードが機種依存なのも問題です(対応はできるけど面倒くさい)。

# zipってファイル名のエンコードを記録してないのでしょうか？

ところで、なぜにCP932の話へのリンク？現在のMailはutf-8になりますよね？

Hit-C さんによる書き込み:

“バグ”ではなく“仕様”ではないでしょうか？

少なくとも、iso-2022-jpで表現できる文字しか含まれていないのに、送信元のエンコードを無視してまでutf-8にして送り返すのは、「仕様のバグ(合理性のない仕様)」のように私は思います。

筋論としては全くおっしゃる通りだと思いますが、問題は、Windows 等が Shift JIS: 817C の MINUS SIGN の「−」を Unicode にマッピングする時点で、対応する U+2212 に割り当てず、U+ FF0D の FULLWIDTH HYPHEN-MINUS の「－」に割り当てるようなことをやっていることに対するマック側からの対応の“工夫”だと考えていますが、そう解釈するのは間違っているんでしょうかね？ U+ FF0D の FULLWIDTH HYPHEN-MINUS は JIS (ISO-2022-JP) にマッピングされていましたっけ？ Mac OS X 10.6 [Snow Leopard] の「文字ビューア」で確認した限りにおいては、MINUS SIGN の「−」は Unicode でも JIS (ISO-2022-JP) でも定義されているようでしたが、FULLWIDTH HYPHEN-MINUS の「－」は Unicode でのみ定義されているようでした。

こういうことに対応するために、Apple Mail から送信するメールにMINUS SIGN の「−」のように Windows とのやりとりで解釈が分かれる可能性のある文字が含まれていた場合には安全を見込んで、元メールが JIS (ISO-2022-JP) と表示されていても、解釈を一義的にするために Unicode (UTF-8) にして送信するのではないでしょうか？

ある意味、変則的な JIS (ISO-2022-JP) によるメールのやり取り

ユニコードが確立する前には、iso-2022-jpが日本語メールの文字コードスタンダードだったのですから、変則的ではないと思います(shift-JISなら変則的ですけど)。

でも、Windows は独自の変更を加えた文字コードのメールに JIS (ISO-2022-JP) の標識を付けて送信しますよね？ Unicode が一般的になる以前から JIS (ISO-2022-JP) は事実上複数の定義が流通していたのではないですか？ もちろん、JIS による定義は一義的でしたが、それを守らない企業があり、しかもその企業のやり方がデファクトスタンダードになっていたと...。

欧米でも、現在の標準的なエンコードはiso-8859-1のままです。

すみません、別に上げ足取りをするつもりはないのですが、「欧米でも」ではなく「米英でも」（＝英語圏）でしょうね。私が海外から受け取る非日本語のメールは（米国からのものも含めて）ほとんどが ISO-8859-2 か UTF-8 です。

たまたま(というか互換性を意図して)iso-8859-1とutf-8は基本文字セット部分で同じコードなので問題が顕在化しないだけでしょう。

いや、Latin-1 以外の Latin-2〜6 ないし、ISO-8859-1 以外の ISO-8859-2〜10 の言語では文字化けは日常茶飯事でしたよ。受信したメールのヘッダ部分やウェブサイトのソースに charset= の定義が埋め込まれている場合には文字化けしませんが、それがない場合は日本語ほど酷くはありませんが、文字化けを起こします。

そもそもタイトルの「返信が化けて」は化けているわけではなく、先方がutf-8表示に対応できてないだけの話ではありますけど...ちゃんとヘッダにutf-8と明記してあるのですから。

その通りですね。ヘッダに utf-8 という標識が埋め込まれているのに文字化けを起こすというのは、相手が国産携帯メールで受信しているか、非常に古い OS ないし、Eudora のように未だに一定の人気はあるけれども、Unicode に（どころか JIS (ISO-2022-JP) 以外には一切）対応していないメーラーを使っているか、メーラーを使った POP 受信では問題はないけれども、ブラウザでウェブメールとして表示させるとどうやっても文字化けを解消できない Yahoo! Mail のアカウントを使っているか等が考えられるでしょうね。いずれにせよ、問題は受信者側にあります。

ともあれ、最近はWInユーザから化けてると言われることはめっきり無くなりましたね(ここ2-3年経験してない)。少なくとも私がやり取りする相手はutf-8で困ることは無くなっているように感じています。

Windows ユーザーではその通りだと思います。仮に多少文字化けを起こしていても気付かない程度になっているということもあるでしょうが。しかし、私の場合は苦情が増えています。いや、もっと正確に言うと苦情ではないのですが...。私がメールを送る相手の圧倒的多数は大学生世代です。今の世代はインターネットメールは、仮にアカウントを持っていてもまず使いません。あるいは、インターネットメールのアカウントに送信しても、自動で自分の携帯メールの方に転送する設定にしています。その結果、非常に多くのメールが文字化けをしてしまうようです。（かつては au で受信した場合には悲惨でした。1文字でも JIS (ISO-2022-JP) で表示できない文字が含まれていると、メール全体が化けてしまっていましたから。）で、実際に苦情につながらないのは、最近の世代は、読めなければ“気にならない”のでスルーしてしまうからです。恐らくこの問題は、国産携帯メールが Unicode に対応するまでは解決しないと思っています。

ところで、なぜにCP932の話へのリンク？現在のMailはutf-8になりますよね？

いや、Windows の場合、JIS (ISO-2022-JP) と言っても実は変則的だと言うことの説明のためです。

ちなみに、最新の Apple Mail では Unicode (UTF-8) になるのですか？ と言うことは、CP932 化の評判があまりにも悪かったために、“元に戻した”ということですかね？ 確か、以前も少しでも解釈に問題がありそうな文字が含まれていると、Apple Mail は Unicode (UTF-8) にして送信していましたからね。

Apple Mail の不便なところは、アップルの解釈で問題ありと思われる文字が含まれていると、Unicode (UTF-8) でしか送信できなくなってしまうことです。例え文字化けしても良いから、強制的に JIS (ISO-2022-JP) のまま送信したいと思ってもそれができないのは不便です。

同時に、かつて iPhone の iPhone Mail は登場時期には Unicode (UTF-8) 以外では送信できなかったのに、最近では JIS (ISO-2022-JP) がデフォルトになってしまったようで、確かに便利になったのかも知れませんが、私的には時代に逆行している行為だと思っています。

メールのエンコードについては、しい坊さんにお任せするとして。

また、zip圧縮ファイルのファイル名エンコードが機種依存なのも問題です(対応はできるけど面倒くさい)。

# zipってファイル名のエンコードを記録してないのでしょうか？

記録できないそうです。英語以外の文字コードを使うことを考えずに仕様を策定したのでしょうね。これだから米国のプログラマは…。

Windows日本語版は、zip圧縮ファイル内でファイル名がShift-JISで記録されているものとして動作します。

英語版だと、ASCIIで記録されているものとして動作します。もちろん、Windows日本語版で圧縮したファイルを解凍すると文字化けします。（Windows 7では未確認です。試された方はいますか？）

NTFSファイルシステムがファイル名をUnicodeで扱っているのに、この体たらく。Windows 98時代のサードパーティ製zip圧縮ソフトとの互換性を重視したためでしょうが、なんとも情けない仕様です。

その点、Unicodeを使って言語に依存しないMac OS Xのzip圧縮はスマートです。Windows日本語版で作成したzipファイル（Shift-JIS）も、解凍時に文字コードを自動判別して正しく解凍できます。

Unicodeを介さない日本語Windowsで解凍したときに文字化けするのが玉に瑕ですが。

Windows日本語版のzip解凍ソフトにも、Mac並みに文字コードを自動判別する機能を盛り込んで欲しいところです。（Windows 7では未確認です。試された方はいますか？）

>マック側からの対応の“工夫”だと考えていますが

向こうがiso-2022-jpでMINUS SIGNを送ってきている以上、送り主の意図はMINUS SIGNのはずです。

FULLWIDTH HYPHEN-MINUSを使う必要があるなら、最初からutf-8で送ってくるべきです。

そのままiso-2022-jpで返信すれば、先方はMINUS SIGNとしか解釈しようがない(iso-2022-jpにFULLWIDTH HYPHEN-MINUSはないわけですから)ので、何ら問題ありません。

問題があるのは先方からutf-8でFULLWIDTH HYPHEN-MINUSが送られてきた場合で、この時には文字通りFULLWIDTH HYPHEN-MINUSなのか変換されたMINUS SIGNなのかを区別できなくなります。

>「欧米でも」ではなく「米英でも」

すみません、その通りです。

ただ、私の場合は英米以外の方からのメールでもiso-8859-1が多いです(ただし常に英語での通信です)。

先のコメントは「英語しか使わない環境では問題が顕在化しない」と読んでいただければと思います。

英語以外で問題を生じることはもちろん承知しています。

>あるいは、インターネットメールのアカウントに送信しても、自動で自分の携帯メールの方に転送する設定にしています。

自分のところでは、必ずPCで読ませます(転送設定は私が関与しないとできない)。添付ファイルも常用するので携帯では使い物になりません。

そもそも仕事をするようになれば(少なくともうちの業界では)PCメールを使えないと生きていけませんから。

>いや、Windows の場合、JIS (ISO-2022-JP) と言っても実は変則的だと言うことの説明のためです。

CP932はiso-2022-jpではなくshift-JISのMS独自拡張ですよね？

shift-JIS系(CP932, Windows-31J等も含む)をメールに使うのは以前の慣例(規格?)から言ってもそもそも変則的でしょう(Winでは標準的でしたけど)。

>ちなみに、最新の Apple Mail では Unicode (UTF-8) になるのですか？

先日試してそうなりました。

>例え文字化けしても良いから、強制的に JIS (ISO-2022-JP) のまま送信したいと思ってもそれができないのは不便です。

或は、文字化けの原因となる文字を類似文字へ自動変換してくれるとありがたいですね。

>私的には時代に逆行している行為

そうかもしれませんが、相手がある以上utf-8一本やりは時期尚早でしょう。

>記録できないそうです。

うーん、やはり。

大量のファイルを交換するときの標準的なフォーマットだけに、エンコードサポートは早急に対応して欲しいですね。

>Windows日本語版のzip解凍ソフトにも、Mac並みに文字コードを自動判別する機能を盛り込んで欲しいところです。

全くその通りですね。そうでなければファイルシステムをunicodeにした意味がない。