日本語の仮名漢字変換精度向上を筆頭に、電波感度の向上やバッテリの持ちなど、嬉しい機能が満載です(電波感度に関しては、通信信号の表示特性が変わっただけの可能性もありますが...)。
その一方で、「今まで表示できていたメイルが文字化けする」という指摘があります。特にauから送られてきた絵文字付きメイルは、過去メイルも含めて軒並み文字化け、とのこと。かく言う私も、auからではないですが、一部メイルが文字化けしていたので、調べてみました。
結論から言うと、恐らく2.1アップデートでは、
- テキスト解釈中、Unicodeへの対応文字が存在しない、と判断された文字へ遭遇した場合、そのテキストはUTF-8で書かれているとして解釈する
例えば、メイル本文中にJISX 0208で「9」を表す文字コードとUTF-8で「あ」を示す文字コードとを書き、Content-Type を「text/plain; charset="iso-2022-jp"」にして iPhone へ送ってみます。「9」は(勿論)Unicodeへ変換可能で、Unicodeコンソーシアムが提供していた対応表ではU+FF19と対応付けられています。つまり、このメイル本文の文字コード列は0x23、0x39、0xE3、0x81、0x82です。
この場合、iPhoneでは「9」という文字が適切に表示されます。一方UTF-8で「あ」と書いた文字コード部は、ã(LATIN SMALL LETTER A WITH TILDE)と表示されました。恐らく0xE3をISO-8859-1と解釈したのでしょう。
一方先のメイル内、「9」の箇所だけを、次の文字コードである0x23、0x3Aへ置き換えてみます。その他は先と同じです。この0x23、0x3AはJIS X 0208では文字が割り当てられ手居ないため、Unicodeへも対応する文字がありません。
この場合、iPhoneは「9」という文字を表示しません。エスケープシーケンス文字は無視され「$B#9(B」と表示されます。一方、その後には「あ」と表示されます。UTF-8で書いた文字コード部を、UTF-8として解釈したのだと考えられます。
この他にも幾つかの組み合わせを試してみましたが、何れの場合にも「Unicodeに対応する文字のないコードが表れた場合には、UTF-8でエンコードされているとして解釈する」と考えられる挙動を示しました。
さてauの絵文字ですが、技術情報を読む限り0x753Aから0x7B6Dの範囲内に割り付けられている様です。この範囲は、JIS X 0208では、文字が割り当てられていないため、対応するUnicode文字も存在しない、ということになってしまいます。結果、絵文字の書かれたauメイルは、ISO-2022-JPで書かれているにも関わらずUTF-8として解釈されてしまい、読めなくなってしまうのでしょう。
また、この挙動はメイル本文だけではなく「mime-attachment.txt」というファイル名を持つ添付ファイルへも適用されるようです。結果「過去に受信した絵文字入りメイルさえも文字化けする」ということになるのだと思われます。
もう、過去のファームへ戻れないので推測に過ぎませんが、恐らく2.0.2までは、指定されたCTに基づいて文字変換を行い、変換できない文字は無視して(または、ゲタに置き換えて)表示する、などの処理だったのではないかな、と。2.1で文字コード自動判別の仕組みでも入れようとしたのかな?
さて回避策ですが、残念ながら「これぞ」という回避策は思いつきません。GMailをメインメイルシステムに使っている人ならば、SafariでGMailにアクセスして読む、という感じでしょうか...?
文字コードを利用者が指定できれば良いのですが、Apple/iPhoneの思想から考えると、その実現は、なかなか難しいかもしれませんね (^^;
0 件のコメント:
コメントを投稿