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

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


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


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


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


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


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


  • まとめ。auのサーバはUnicode絵文字を含めてUTF-8をサポートしているので、SoftBankのサーバがあらかじめcharset=UTF-8のメールをauISO-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のサーバの仕様変更と推定した。