1. Unicode絵文字とキャリア絵文字
大橋 宏章 NAL-6295

2. profile
 大橋 宏章
 NAL-6295(なるひろと読みます)
 @nal_6295
 http://blog.nal-6295.biz
 株式会社グラニ所属
 C#が好き

3. agenda
 携帯絵文字って？
 Unicode絵文字って何？
 携帯電話とスマートフォンが対応している絵文字って？
 相互変換を行うために
 状態を識別しやすくするために
 Unicode絵文字とMySQLの美味しくない話
 最後に

4. 携帯絵文字って？
 Docomoが最初にi-mode絵文字をはじめて、各キャリアがそれに追従す
る形で始めたもの。
 追従するときに互換性を考えればよかったのに、全く互換が無い。
 それぞれ、shift-jisおよびUnicdeの外字として登録されている。
 現在、Softbank,docomoはunicode,auはshift-jisで出力すれば、それぞ
れの携帯で表示される。
 参考：携帯電話の絵文字
http://ja.wikipedia.org/wiki/%E6%90%BA%E5%B8%AF%E9%9B%BB%E8
%A9%B1%E3%81%AE%E7%B5%B5%E6%96%87%E5%AD%97

5. Unicode絵文字って何？
 Apple,Googleが主導となってdocomo,Softbank,kddi３社の絵文字を
Unicodeに収録しようというプロジェクトemoji4Unicodeの成果。
（なぜ、当の本人たちが参加していないのか・・・）
 Unicode6.0で収録
 これで、各キャリアの絵文字を変換するための共通言語ができる。
 Unicode絵文字とキャリア絵文字の対応については以下ページに表がある。
 http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html
 UTF-8の追加面に定義されている4バイトのものが存在する
 2文字あわせて合字で表現されているものがある

6. Google定義の絵文字もあるよ
 Unicode絵文字が合字を採用していることに対して、こちらは１文字で表
現するようにマッピングされている。
 Unicode絵文字はGoogleとAppleが中心となって作られたものなのに更
に作ってどうするつもりなのか。

7. 携帯及びスマートフォンの対応状況
 Docomo,Au
Unicodeで定義されたものを解釈できる機
種もあるが全体としてはShift-jisで定義され
た絵文字を解釈する

8. 携帯及びスマートフォンの対応状況
 Softbank
Unicodeで定義した絵文字を解釈できる

9. 携帯及びスマートフォンの対応状況
 iOS
 5以前
Softbank絵文字での入力となる。
出力はSoftbank絵文字及びUnicode絵文字に対応して
いる
 5以降
Unicode絵文字での入力となる。
出力はSoftbank絵文字及びUnicode絵文字に対応して
いる

10. 携帯及びスマートフォンの対応状況
 Andoroid
4以前
Google絵文字に対応
４以降
Google絵文字、Unicode絵文字に両対応
基本はUnicode絵文字

11. 携帯及びスマートフォンの対応状況
 PC
 Windows8
 OSX
 ともにUnicode絵文字に対応している

12. 相互変換を行うために
 中間言語およびiOS5以降の入力としてUnicode絵文字を使う
 docomoとauはshift-jisでsoftbankはunicodeでの入出力を想定する
 便利なことにUnicode絵文字との相互変換定義が存在
 https://code.google.com/p/emoji4unicode/source/browse/trunk/data/
emoji4unicode.xml
 しかしながらdocomoとauもUnicodeになっている
 更に便利なことにUnicode絵文字とshift-jisの対応テキストが下記にそのその後
変換定義も存在（しかしながらcsv形式のテキスト)
 https://code.google.com/p/emoji4unicode/source/browse/trunk/gener
ated/EmojiSources.txt

13. 相互変換を行うために
 実行時に上記２つの定義ファイルを解釈しても良いがコストがかかる
 ということで、定義クラスを実装することにした
 入力定義、出力定義をそれぞれDictionaryで持つ
 Key？
 符号点を利用して2文字で一文字とする絵文字があるので、バイト配列をBEで
ulongに変換したもので定義
 この時、定義ファイルとulongの値に差があるとめんどくさいのでUTF32を2文字束
ねたものに変換する想定
 Value？
 Unicode絵文字にあってキャリア絵文字にない文字は代替テキストを表示したいの
で変換後のbyte配列と代替テキストとしてのStringを持った簡単なクラスを用意し
た。

14. 相互変換を行うために
 次に実際の変換部分
 符号点を利用して2文字で定義されている絵文字はString型では２文字として
解釈されてしまうという問題
 最初は自分で解釈するロジックを組んでいたが煩雑だった

15. 相互変換を行うために
 System.Globarization.StringInfoクラス
 GetTextElementEnumeratorメソッドを使うと合字を利用した絵文字も1文字
として扱ってくれるので、これにStringを食わせることに・・・

16. 相互変換を行うために
 入力は各キャリアの絵文字からUnicode絵文字に
 出力はUnicodeから各キャリアの絵文字に変換
 定義されているDictionaryのKeyがBEで定義されたUTF32を2文字束ねたulong
 1文字を8バイトの配列に変換し、LEだったら反転させたあとulongに変換
 その後は両方共定義クラスのDictionaryに1文字ずつ当てていくだけ

17. 状態を識別しやすくするために
 Stringのままで扱い続けていると、今、どの状態の文字列を扱っているの
かがわからなくなる
 そのため、変換クラスで入力時は別途定義したクラスに変換出力時に
Stringに戻すという事をしていました
 こうすることで、出力時の変換忘れなどを防ぐようになっています
 出力時はその型を引数としたHelperを用意することで、絵文字表示が行
われるようにしました。

18. MySQLとUnicode絵文字の美味しく
ない話
 Unicode絵文字は一部、 4バイトUTF-8に定義されている
 MySQLの通常のUnicodeはUTF-8 3バイトまで
 なので、Unicode絵文字を扱うときはMySQL5.5.3以降にし、character
setをutf8mb4という4バイトUTF-8を扱うものに変更する必要がある

19. 最後に
 日本のキャリアが最初から互換性を維持してくれれば、めんどくさいこと
は起きなかった
 Unicode絵文字が登場したことで、それを中間言語とすることで相互変換
が楽になった
 System.Globarization.StringInfoクラスは便利