絵文字がUnicode標準に

http://k-tai.impress.co.jp/docs/news/20101013_399811.html

Unicodeのバージョンも知らない間にV6になっていたんですね。

さて、携帯電話でよく使われている絵文字がUnicodeの標準の一部となるという話です。

以前からGoogle等がロビー活動をしていたという話を聞いていましたので、この記事自体にはさして驚きもありません。

ところで、改めて標準になったことで、ほとんどの人々には、どうでも良いことですが、この絵文字のUnicode化について、気がついたこと（気になっていること）があります。

それは、追加されるCJK文字は、基本的に最早16bitでの表現に収まりきらず、UTF-16で表現する時には、サロゲートペアという仕組みで表現しなければならないという事実です。

これは、今回の新しい絵文字にも当てはまります。

Unicodeの既存のマルチバイトエンコーデングに対するメリットは、固定長なので、処理が単純化できて、処理高速化にも繋がる。

という所が最大のポイントですが、

逆にデメリットとして、メモリーやディスク容量が余計に必要というのがあります。

ただし、近年のハードウェアの進歩に伴い、全体から見るとディスク容量やメモリー容量が余分に必要と言う点も大きな問題ではなくなっています。

ところが、サロゲートペアを使うとSJISなどのマルチバイトエンコーデングと同様、Unicodeのエンコーディングとして広く使われているUTF-16であっても固定長とは言えず、可変長となってしまいます。

もちろん、UTF-32のような4バイト（オクテット）のエンコーディングにすると、サロゲートペアを使わずに固定長文字列を実現できます。

しかし、いくらメモリー、ディスク容量が潤沢になったといっても、2バイトが4バイトになる影響は1バイトが2バイトになる以上に大きいです。

しかも、従来、サロゲートペアに割り当てられた新漢字は、ほとんど一般的には使われるものではないので、それらの希少、頻発しない文字のために、余分なメモリー、ディスクを使うのは資源の経済性の観点から疑問符がつきます。

これが、おそらくサロゲートペアが導入されて以降、処理が煩雑になるにも関わらず、従来のUTF-16で内部処理する手法がUTF-32の固定長方式で代替されるケースがそれほど多くない理由ではないかと思っています。

インターシステムズの製品も内部処理では、ほとんどUTF-16で処理しています。

しかし、絵文字は従来のマイナーな漢字とは違い、広く（日本だけですけど）普及している文字なので、使用頻度はぐんと上がることが予想されます。

今後の普及を見ながら、我々の製品での対応を考えないといけないかもしれません。