iPhone間のメールで@i.softbank.jp発のUTF-8が化けるようになった（直りました）

  • Appleのサポートコミュニティで見かけた事例。SoftBank iPhoneの@i.softbank.jpアカウントからau iPhoneの@ezweb.ne.jpアカウントにメールを送ったとき、以前は表示されていた特殊顔文字など（要するに、Unicodeでしか表現できない文字）が豆腐や空白に化けるようになった。


  • 何が原因なのか調べてみた*1結果、SoftBankの@i.softbank.jp用のサーバの仕様が（望ましくない方向に）変更されたようなので*2、SoftBankのサポートに電話で訴えてみたのだけれど、「特殊文字が化ける場合は、特殊文字を使わないようご案内しています」とか言われて埒が明かないので、ブログにまとめた上で再トライしてみようかと。
  • 下図は、太陽の絵文字をiPhoneの@i.softbank.jpアカウントから送信した場合に、各キャリアのサーバによって文字コードがどのように変換されるのかを示したもの。この例は、仕様変更の影響を受けていない。


  • @i.softbank.jpアカウントは、パソコンのメーラーで利用することもできる。下図は、MacのThunderbirdで@i.softbank.jpアカウントから太陽の絵文字を送信した例。以前の仕様では、SoftBankのサーバはUTF-8をスルーしていた。docomoのサーバはUnicode絵文字の変換をサポートしていないので、こういうケースでは、絵文字がdocomoの端末に届かなかった。


  • おそらくこのような状況を改善するために、SoftBankのサーバで（docomoのサーバがやらないぶん、気を利かせて）あらかじめUTF-8をdocomoのシフトJISに変換しておくよう、仕様を変更したのではないかと思う。下図は、仕様変更後の挙動。この例だけなら仕様変更は成功しているように見えるが、docomo宛のメールだけでなく、au宛のメールまでSoftBankのサーバで一律に変換をかけてしまっている点が問題となる（後述）｡


  • 下図は「Unicodeでしか表現できない字」の例として「⌘」を送信した場合の、以前（仕様変更前）の挙動。iPhoneの@ezweb.ne.jpアカウントでは、「⌘」が正しく表示されている（「Unicodeでしか表現できない字」がdocomoの携帯とauの携帯で表示できないのは当然）。auのサーバは受信側の@ezweb.ne.jp端末がiPhoneかガラケーかを知っており、charset=UTF-8のメールを受け取ると、iPhoneにはそのまま渡し、ガラケーに対してはauのISO-2022-JPに変換した上で渡している。


  • 同じく「⌘」を送信した場合の現在（仕様変更後）の挙動が、下図。SoftBankのサーバが@ezweb.ne.jp宛のUTF-8をISO-2022-JPに変換するようになったため、ISO-2022-JPに変換できない情報（U+2318）は消えてしまい、受け手がiPhoneであっても表示できなくなった。


  • まとめ。auのサーバはUnicode絵文字を含めてUTF-8をサポートしているので、SoftBankのサーバがあらかじめcharset=UTF-8のメールをauのISO-2022-JPに変換しておく意味はないと思われる。@ezweb.ne.jp宛のメールに対しては、以前と同様にUTF-8をスルーして、その後の処理を（受信側の端末がiPhoneかどうかを知っている）auのサーバに委ねるよう、サーバの仕様を変更してもらいたい。

*1:akane_nekoさんにご協力いただいてテストしました。ありがとうございます！

*2:①@i.softbank.jpから@ezweb.ne.jpへのメールでしか化けないこと。②送信側、受信側とも複数のメーラーで結果が同じであること。③@i.softbank.jpから@docomo.ne.jpへメールを送った場合の挙動も以前と変わっていること。④docomoのサーバはゲタとして「･」を、auのサーバはゲタとして「?」を用いるが、今回問題としている文字化けでは、結果が空白または豆腐となること。……などから、SoftBankのサーバの仕様変更と推定した。