「これは絵文字ですか？」「はい、Unicode6.0です」

Posted on 2012-05-16 by takezoux2

携帯向けのWebサービスをやっていく上で、絵文字の対応は頭を悩まされるところです。
最近では、ガラケーことFeaturePhoneに加えSmartPhoneも多く普及してきました。
そこで、現在の絵文字事情がどうなっているかを調べてみました。

現在の絵文字の状況

日本では、docomo, au, SoftBankの３キャリアごとにそれぞれ違った文字コードの絵文字が存在します。
世界に目を向けると、GoogleとAppleが主体となって絵文字の標準化を行なっており、
2010年10月にUnicode6.0で絵文字の国際標準が策定されました。
そのため、現在のスマートフォンを取り巻く絵文字事情は、docomo, au, SoftBank3キャリアの群雄割拠にUnicode6.0も参戦する太陽曰く(」・ω・)」うー!(/・ω・)/にゃーな状況となっています。
最近では、iOSが5.1になって他キャリアに絵文字が送れなくなったなんてことも発生していました。

なお、Unicode6.0で採用された文字コード体系は、Googleのemoji4unicodeがベースになっています。

絵文字の対応方法

通常Webサービスなどで絵文字を保存する場合は、

いずれかのキャリアの文字コードに変換
独自の形式に変換

のどちらかを行ない、内部では１種類の絵文字コードで保存を行います。
日本ではdocomoユーザーが最も多いため、docomoの絵文字コードに統一して保存を行う場合が多いようです。
ちなみに、弊社の提供しているおみせやさんでは内部ではGoogle emoji4unicodeの下位16bitの文字コードに変換して保存をしています。(下位16bitはPUAなのでまず問題は起きません。詳しい説明は後述)

絵文字の変換フロー

各機種絵文字対応状況

現在の、スマートフォンの絵文字対応状況を紹介しておきます。
iPhoneのみが特殊で、OSのバージョンによって送信時の文字コードが違う＋表示はUnicode6.0とSoftBank共に出来る状態になっています。
表示確認は周りにおちてた機種のみでしかしていませんのであしからず。

機種	OS	キャリア	入力時の文字コード	表示できる文字コード
iPhone4	iOS 4.X	SoftBank	SoftBank	Unicode6.0,SoftBank
iPhone4	iOS 5.X	SoftBank	Unicode6.0	Unicode6.0,SoftBank
iPhone4S	iOS 5.X	SoftBank	Unicode6.0	Unicode6.0,SoftBank
Sumsong Galaxy S2 LTE	Android 2.3	docomo	Google	docomo,Google
NEC Medias N06c	Android 2.3	docomo	Google	Google
Sharp Galapagos	Android 2.3	SoftBank	Google	SoftBank,Google
Sharp IS03	Android 2.2	au	Google	Google

- 5/16 19:00 機種を追加＋間違っていた情報を修正

スマートフォン時代の絵文字の取り扱い方は？

既存のサービスを持っているところは現状維持が妥当とは思いますが、これから新規にサービスを立ち上げようとする場合はどのようにするのが良いでしょうか？

方法は、

Unicode6.0標準をそのまま使用する
Unicode6.0標準の下位16bitを使う

のどちらかかと思います。なるべくなら、前者をおすすめします。

理由その1 すべての絵文字を網羅している

3キャリアの絵文字では相互に変換できない絵文字が存在するため、どうしても特定のキャリアで使えない絵文字が出来てしまいます。
Unicode6.0であれば、３キャリアの絵文字 => Unicode6.0への変換はもれなく行うことができます。
またUnicode6.0 => 3キャリアの絵文字へは変換できない場合もありますが、絵文字の名前が定義されているので絵文字の変わりにその名前を表示することも可能です。

理由その2 今後標準になっていく

iOSはUnicode6.0での表示にすでに対応しています。MacでもUnicode6.0ならばそのまま絵文字が表示可能になっています。
WindowsPhoneも同様に徐々に対応してきているそうです。(実機では未確認。wikiから)
また、現在Androidは対応していませんがGoogleが標準化の主要メンバーであるので今後対応していってくれると思います。
なのでUnicode6.0にしておくと、将来的にキャリア別に絵文字の文字コードを変換をしなくても良くなる可能性が高いです。

ただし・・・

Unicode6.0の絵文字はU+1F200 ～　U+1F700台に多くがマップされています。これらのUnicodeはUTF-8でエンコードした場合4byte長になってしまいます。
現時点では、4byte長のUTF-8をうまく扱えないor扱うのが面倒なシステムが多く存在します。
例えば弊社ではMySQLを利用していますが、MySQLのUTF-8は4Byte長の文字を扱えません。MySQL5.5からは「utf8mb4」というCharacterSetが導入されたので4byte長も扱えるようになっていますが、それ以前のバージョンではBLOBを使ってバイナリとして保存をするしか方法がありませんでした。
また、最近はやりのNode.jsも、ベースになってるV8エンジンが4byte長UTF-8を扱えないため、文字列ではなくバイナリデータとして取り扱う必要があります。

このような事情から、現時点ではシステムによっては絵文字が含まれうる文字列は、バイナリデータとして無理やり使う必要があります。しかし、バイナリデータとしてしまうと、ライブラリ等に用意されている文字列関数が使えなくなってしまい取り扱いが面倒になることがあります。
そこで、下位の16bit分だけを利用するというのもひとつの解決策になります。下位16bitはU+F200 ～　U+F700台になり、これはUnicodeのPrivate Use Areaであるので、通常では他の文字とかぶっていません。そのため、下位16bitのみを使用しても問題になることはありません。ただし、入力時や表示時に変換が必須となるのでそのへんの手間を考えて、そのまま使うか下位16bitのみを使うかを決めたほうがいいと思います。

参考にしたサイト

MySQLで4バイトのUTF-8文字を扱ってみる
 絵文字のUnicode6.0と各キャリアの対応表