10.8.2アップデート後に、一部のメールが文字化けする

送信元にお願いして 全角一文字の電話番号文字を、"TEL"としてもらった結果、確かに文字化けは起こらなくなりました。ご報告まで。

しかし、同じ送信元からの過去のメールが、再構築してしまった結果、文字化けしたままです。できれば、アップルからの再パッチでは、再構築でそれらの文字化けを修復する機能を希望します。（フィードバックします。）

TEL の件、全く同様。

フィードバックしました。

いつになれば改善出来るのでしょうか。

全く仕事になりません。。。

無駄で手間のかかる作業ばかりでストレスです。。。

私は幸い文字化けする新規メールがあまり受信しないですが、メインメールをgmailに転送してありそれをmacのメーラで受信しているため、見えない時はwebで見ています。内容は,ipod-touchiでは問題無いので良いのですが、古い保存メールが文字化けしているのは、困ります。

appleでは不具合を認識していますが早急に、アップデートをリリースするしか対応が無い様です。

当方も文字化け。

文字化けメールをいったんGmailに転送。

文字化けせずに表示されるので、

かっこ株などの記号文字を消して自分宛に返信したら

とりあえずは問題なく表示しました。

相手先への返信はこの方法でなんとか対応してます。

私も10.8.2の環境でみなさんと同じ状況になり困っています。

ただ、併用しているiPad2の「メール」では、同じ文字化けのメールも何事もなく表示されますので、現在のところそれで対応しています。

私も10.8.2で同じような文字化けが時々生じており，それはiPhoneにて読んでおります。

私の場合，iPhoneからその文字化けメールを，添付ファイルを外して転送すると本文は読めるようになったということがありました。

その時の添付ファイルはwordとpdfで，本文中には皆様がお書きになっているような特殊文字はありませんでした。

ご参考までに。

m.wakamatsu さんによる書き込み:

確かに CokeABE さんの内容に沿ってエディタで開いてみたところ、「かっこかぶ」や「まるいち」などの特殊文字が含まれているものばかりが化けていました。

ISO-2022-JP の本文を無理矢理 UTF-8 など別の文字コードで解釈しようとするんでしょうかね。

件名は問題ないのに…

「㈱」や「①」等は、JIS (ISO-2022-JP) では定義されていない文字です。これらの文字は、Unicode で送信しないと受信相手によって文字化けが発生します。それらの（ある意味不正の）機種異存文字を Windows 等から送信した場合、Windows では CP932 という独自の文字コードなのに、一方的に「JIS (ISO-2022-JP)」であるという情報をメールのヘッダ部分に付けて送信します。つまり嘘をついている。

この CP932 のメールを JIS (ISO-2022-JP) だといつわって送信したメールを Windows で受信すると、そちらも JIS (ISO-2022-JP) という名目で CP932 の文字コードを使っていますから、文字化けは起こらないのです。

ところが、そのメールを文字コードをきちんと管理している Mac で受信してしまうと、ヘッダ部分にある「JIS (ISO-2022-JP)」という文字コードを生真面目に判定して、JIS (ISO-2022-JP) で表示しようとして文字化けが発生してしまうのです。で、Apple Mail の場合は、受信メールのヘッダに文字コードが指定されていると、そちらを優先させてしまい、手動で文字コードを変更しよとうとしても、無視されてできない仕様になっているようです。

Apple Mail から「㈱」や「①」等の機種異存文字を含むメールを送信しようとすると、自動的に、それらの文字が正しく表示される Unicode (UTF-8) に変更して、そのメールが Unicode (UTF-8) である旨の情報をメールのヘッダに埋め込んで送信しますので、通常は Windows で受信しても文字化けは起こりませんが、古い Windows や 古い Unicode (UTF-8) に対応していないメーラーで受信したりすると、やはり文字化けを起こしてしまいます。また、いわゆる「ガラケー」は Unicode (UTF-8) に対応していないので、やはり文字化けしてしまいます。（最近はガラケーも Unicode に対応しているとキャリアが宣伝しているので、もうガラケーも Unicode にちゃんと対応していると本気で信じている人が、ベテランも含めて多いのですが、あれはインチキで、ガラケーのメールが Unicode になったのではなく、受信したメールに Unicode でないと表示できない文字が含まれていると、その部分を「?」や「•」、「�」等に置き換えて、残りの JIS (ISO-2022-JP) でも表示できる部分を表示しているだけです。au 等ではかつては1文字でも Unicode 文字が含まれているとメール全文が文字化けしてしまっていたので、Unicode の文字は無視して化けさせたままにして、JIS (ISO-2022-JP) でも読める文字だけは表示できるように改良したことを「Unicode 対応」と謳っているだけです。）

Apple は何年も前からこの日本語によるメールの文字化け問題は認識しており、頻繁に改良を加えてきていますが、「あちらを立てればこちらが立たない」状況のイタチごっこで、明示的に Windows の文字コードに対応した「CP932」のカテゴリーを導入した時期もありましたが、Windows の方が、「CP932」という自分の文字コードを認識しないため（自分では「JIS (ISO-2022-JP)」だと偽っていますから）失敗しました。では、Windows がやっているように、Mac も多数派の Windows に合わせて、本来の「JIS (ISO-2022-JP)」を捨てて、「CP932」を「JIS (ISO-2022-JP)」だと見なせばいいじゃないかと、多くの Windows ユーザーは思うでしょうが、そんなことをすれば、これまでの Mac との文字表示の互換性がなくなってしまいます。何よりも、JIS (ISO-2022-JP) に準拠したファイルが全て文字化けしてしまうという問題が残ります。

iPhone 3G が初めて日本に登場した時には、iPhone では色々な文字コードのメールは表示できましたが、新規メールは Unicode (UTF-8) になっており、他の文字コードの選択の余地はありませんでした。理由は簡単で、Unicode (UTF-8) のみでメールをやりとりすれば、世界中のどの言語もきちんと表示され、文字化けの問題もなくなるからです。

ところが、iPhone が爆発的に売れて、日本のガラケー・ユーザーたちから「メールが文字化けして読めない！」という抗議の嵐が巻き起こり、Apple も問題の大きさに、日本語のメールではJIS (ISO-2022-JP) としてデフォルトで新規作成に使うようになったようです。とは言え、1文字でも Unicode 文字が含まれていると、自動的に Unicode (UTF-8) で送信され、文字化けの被害を最小限に抑えるように試みます。

Thunderbird を使えば、Apple Mail では手動で文字コードを変更できず、文字化けが解消しないメールでも、文字コードの変更を受け付け、読めるようになる場合がほとんどです。では、Thunderbird を使えばいいじゃないかという考え方もあるでしょうが、ところがどっこい、今度は Thunderbird の方で文字化けしてしまい、Apple Mail じゃないと読めないなんていう場合もあるのです。（基本的に Thunderbird は Windows と同じテキストエンジンを使っているようです。だから Windows で作成されたメールとの親和性が高いようです。）また、画面表示は Apple Mail の方がはるかにセンスもよく、美しいので、捨てがたいものがあります。（私の周囲には、この Mac の Apple Mail を見て、その美しさのあまり Mac に乗り換えたという人が何人もいます。）

私自身は背に腹は代えられないので、Apple Mail と Thunderbird の両方でメールを平行受信しています。

受信するのが自分の場合には、このように（多少面倒くさくても）対応できますが、問題は相手の方です。相手に、どのようにするように指示するわけには、特に取引先などの場合にはできませんので、悩ましい所です。とりあえず、私の場合は、メールを送信する時に、手動で文字コードを Unicode (UTF-8) に指定してから送信するようにしています。裏技で、新規メールのデフォルトの文字コードを Unicode (UTF-8) に指定する方法もあります。ライブラリの中の plist ファイルを書き換える必要がありますが。

恐らく、この問題は困りものではありますが、ガラケーや Windows のメールが完全に Unicode に移行するまでは根本的な解決方法はないと思います。Windows は OS レベルでは Unicode なのですが、個別の国産アプリのレベルで Shift JIS というものが多く、トラブルの元になっています。しかし、少しずつ Unicode への移行は進むでしょうし、ガラケーもやがては Unicode に変更せざるを得ないと考えています。ガラケーの文字コードはキャリアの決断次第ですから、意外とある時に「えいやっ！」と一斉に Unicode に替わるのではないかと予想しています。

いずれにせよ、Apple はこの問題に関して無策なわけでも、ユーザーの声を無視しているわけでも、無能なわけでもありません。対策の方法が存在しないのです。

edih_f さんによる書き込み:

ただ、併用しているiPad2の「メール」では、同じ文字化けのメールも何事もなく表示されますので、現在のところそれで対応しています。

iOS 用の iPhone Mail や iPad Mail では、文字コードは「JIS (ISO-2022-JP)」として本来の「JIS (ISO-2022-JP)」ではなく、Windows と同じ「CP932」の方を使っているようです。この２つの文字コードの違いについては上の私の「Re: 10.8.2アップデート後に、一部のメールが文字化けする」をご参照ください。

その理由は、恐らく、iOS はガラケーユーザーとのやりとりが多いだろうと言う想定で、あえて正しくない文字コード処理を選択しているのだと思います。そのお陰で、Windows ユーザーやガラケー・ユーザーは文字化けの不具合が改善されましたが、逆に Mac ユーザーの場合は混乱に拍車がかけられることになっています。（iPhone と Mac の間で機種異存文字が化ける。）

しい坊 様

詳しいご教示ありがとうございます。

テクニカルですが何とか分かります。未だ困っていますが、理由に納得できました。

例えば「①」と「㈱」は Windows では外字領域の文字コード番号 2D21（Shift JIS では 8740）と 2D6A（Shift JIS では 878A）に定義されています。この文字を含むメールを Windows のメーラーで JIS (ISO-2022-JP) の文字コードで送信すると、文字コード番号は 2D21（Shift JIS では 8740）と 2D6A（Shift JIS では 878A）のままです。しかし、送信時に Unicode (UTF-8) を指定すると、Windows のメーラーは自動的に ① を U+2460、㈱ を U+3231 という文字コードに変換します。Unicode は PC（IBM PC/AT 互換機＝Windows マシン）でも Mac でも共通ですから（Unicode は世界共通の規格なので機種依存文字は存在しません）、U+2460 と U+3231 の文字コードの文字は Mac でもきちんと「①」と「㈱」として再現されます。

ところが、「①」や「㈱」を使った Windows から Mac に JIS (ISO-2022-JP) の文字コードを使っていると主張しているメールが届くと、Mac も JIS (ISO-2022-JP) の 2D21（Shift JIS では 8740）と 2D6A（Shift JIS では 878A）に定義されている文字を表示します。これらの文字が定義されているのは「外字」領域です。Mac ではそれぞれ「㈰」と「�」に化けてしまいます。

逆に Mac から JIS (ISO-2022-JP) の文字コードで「①」や「㈱」を使ったメールを送信すると、それらの文字コードは Mac ではそれぞれ 8540 と 874D なので、Windows では「・」と「⑭」に化けてしまいます。（実際には Apple Mail でそのような機種依存文字の含まれているメールを JIS (ISO-2022-JP) の文字コードで送信しようとすると、送信ボタンを押した時に以下の画像のような警告が出て送信できません。この場合には、文字コードを Unicode (UTF-8) に変更するか、あるいは「①」や「㈱」を「(1)」や「(株)」に置き換えて対処するしかありません。）

Windows と Mac で、どの文字がどの文字に化けるのかのわかりやすい一覧表が以下にありますので、ご参考になさってください。

「文字化け（機種依存文字）」

繰り返しますが、Unicode を使っている限りにおいて、これらの問題を意識する必要はありません。この Apple サポートコミュニティ も Unicode (UTF-8) ですので、安心して「①」や「㈱」のような文字が使えます。ただし、ガラケーからこのページにアクセスしいてる人の場合は当然、文字化けが発生します。

Facebook にせよ、Twitter にせよ、一般の企業のサイトにせよ、世界ではほとんどが Unicode に移行していますが、日本では、色々な ウェブ サイトでも、ケータイのメールでも（私には全く理解できないことですが）、頑なに JIS (ISO-2022-JP) に固執しています。幕末から明治維新に掛けて、日本は率先して最先端の世界標準を導入しました。例えばメートル法の導入も日本は世界の中でも非常に早く導入した方です。（英米は未だに移行できていませんしね。）ところが、高度成長時代辺りから、日本は世界標準に追随しなくなりはじめました。世界ではもう「ジュール」を使っているのに、日本では未だに「カロリー」だとか...。最近やっと「ミリバール」が「パスカル」に置き換えられました...。文字コードに関しても日本だけが世界に遅れているようです。

「㈱」や「①」等は、JIS (ISO-2022-JP) では定義されていない文字です。

定義されていないのではなく、MacとWindowsでは定義が異なる・・・では？

10.8.2のバグによる文字化けの仕組みについては下記が詳しいので参考にされるといいと思います。

OS X 10.8.2のMail.appで新種の文字化け - Mac OS Xの文字コード問題に関するメモ

HAL さんによる書き込み:

「㈱」や「①」等は、JIS (ISO-2022-JP) では定義されていない文字です。

定義されていないのではなく、MacとWindowsでは定義が異なる・・・では？

JIS で定義されている文字コード表では9区〜15区は空欄になっています。

「Update Registration 87 Japanese Graphic Character Set for Information Interchange」

「JIS基本漢字」

「JIS X 0208 - Wikipedia」

つまり、外字領域としてユーザーが自由に定義して使える領域として用意されたものだと思われます。（だから JIS では定義されていない領域です。）多くの有名な機種依存文字は13区に存在するのですが、そこに Microsoft (Windows) が定義した外字と、Apple (Mac) が定義した外字が異なっていたということだと思います。（ですから、「定義が異なっている」というのは最初からその通りなのですが、いずれにせよ、それらの定義は JIS の与り知らぬ所なわけです。）

同じ Windows でも、事実上の日本の標準であった NEC 外字を採用した NEC PC-9800 ときちんと JIS に準拠した EPSON の PC-9800 互換機ではやはり文字化けが発生していました。

「Microsoftコードページ932 - Wikipedia」

「MacJapanese - Wikipedia」

「JIS X 0208と0213と機種依存文字」

いずれにせよ、Unicode を介在させないで、Mac と Windows 間の文字化けを解消する方法は見当たらないように思えます。何かいい方法はありますか？

HAL さんによる書き込み:

10.8.2のバグによる文字化けの仕組みについては下記が詳しいので参考にされるといいと思います。

OS X 10.8.2のMail.appで新種の文字化け - Mac OS Xの文字コード問題に関するメモ

なかなか有益なリンクですね。ここでも以下のようなコメントが付いていますね (^^)。

grumpy_the_dwarf 2012/10/03 16:09

所詮、iso-2022-jpだと嘘をつく相手方のメーラがゴミって話ですね。utf-8でも使えばいいのに。

全く同感です (^^)。

いずれにせよ、Unicode を介在させないで、Mac と Windows 間の文字化けを解消する方法は見当たらないように思えます。何かいい方法はありますか？

別に完全に解消できなくとも、少なくとも10.8.2に上げる前までは全文文字化けするなんて事体は起きなかった訳ですから前の仕様に戻してもらえれば最善でなくとも最悪は避けられるのではないかと思います。