絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama｜note

（情報元のブックマーク数 ）

絵文字対応をやることで、UTF-16が正しく動作するプログラムになっていったと。面白い！

この結果何が生じたかというと、バグの多いプログラムである。UTF-16を採用したプログラミング言語などでは当然UTF-16を使って文字列を表すことになるが、そこで単純に2バイトで1文字を仮定してプログラムを書くと、サロゲートペアが入力されたときにそれをうまく扱うことができない。ただしそのような文字はUnicodeに後から収録されただけあって、必然的に使用頻度の低い文字ばかりで（日本語でもほとんどの日本人が見たことのないような漢字ばかりだ）、多くの場合にはなんとなく動くので、いつまでも直らないバグになっていた。あるいは最初から問題解決を諦めていて、サロゲートペアの文字を最初から使えないことにしている手抜きシステムもよくあった（MySQLの自称"utf8"エンコーディングなど）。
この状況を変えたのが絵文字だ。2010年に日本の携帯電話との相互運用のためにUnicodeに追加された絵文字は、その後数年で日本語に関係なく世界中で広く使われるようになった。ほとんどの絵文字は他の最近採用された文字と同じくUTF-16では4バイト必要なのだが、どの言語でも極端に利用頻度が高いので、急に世界中の誰もがサロゲートペアについてきちんと考えざるを得なくなった。絵文字のバグを直すと必然的にマイナーな漢字などもきちんと扱えるようになってしまう。これは絵文字の普及の意図せぬ副作用と言えるだろう。
ある意味、ここ数年でコンピュータの歴史上で初めて、英語圏ですらASCIIの範囲内では日常的に文字が足りないという状況になったともいえる。しかもその足りない文字はよりによってUTF-16では処理がトリッキーなサロゲートペアばかりなのである。
また同時に、絵文字などを使うと結局可変長になってしまうのだから、UTF-16ではなく最初からUTF-8を使う方がいいじゃないかという認識が以前より広まったように思う。今では内部処理であれ外部とのデータ交換用であれ、すべての局面でUTF-8を使うのがよいという認識がかなり広まりつつあるが、絵文字の普及がそれを後押ししているならとてもよいことだ。
というわけで、絵文字は後からUnicodeに収録された文字としては異例に利用頻度が高いので、いろいろなシステムにある種のストレステストを強いることになり、結果として世界的にプログラマの認識の改善とプログラムの品質向上に貢献することになったといえる。これはなかなか面白い話だと思う。