サロゲート・ペアのトラブルはいつまで続くか

| コメント(0) | トラックバック(0)

先日テレビをなんとなく見ていたら、エンディングのスタッフロールに「𡈽野」という名字が見えて俄然注意を引かれました。

「𡈽」は「土」の異体字で、JIS第3水準漢字、面区点1-15-34にあります。UnicodeではBMPになく、面02、U+2123Dなので、UTF-16ではサロゲート・ペアが必要です。

異体字なので読みや意味は「土」と同じです。読みや意味が同じだったら区別する必要はないだろうという気もしますが、それはまた別の話。テレビでは読みが書いていなかったので推測するしかないのですが、ヒジノかハジノ、あるいはツチノと読むのでしょうか。

そんなことをTwitterでつぶやいたのですが、事件はそのあと起こりました。事件というほど大げさなことでもありませんが。

Twitterには自分の投稿に対するアクションがあるとメールで通知する機能があります。オフにしておこうと思いつつそのままになっていたので、上記「𡈽野」という文字を含んだツイートに対するアクションの通知メールがとんできました。

ところがそのメールには「𡈽野」の「𡈽」がきちんと表示されていませんでした。メーラにもよるのでしょうが、私の環境では問題の文字の代わりに「~」が2個並んで「~~野」となっていました。

はて、どうなっているのか。

このHTMLメールのソースを見ると、疑問はすぐに氷解しました。

「𡈽」にあたる部分が、HTMLの数値文字参照で「��」となっていたのです。10進数で書かれてもよく分かりませんが、2個並んでいることから何が起こっているのか想像はつきます。それぞれの数を16進にしてみると、55364はD844、56893はDE3D。これはUTF-16のサロゲート・ペアの値です。

つまり、上位・下位それぞれのサロゲートの値をHTMLの文字参照にされてしまっていたわけです。どういうロジックを経てそうなってしまったのかは分かりませんが。

テキストエディタやウェブブラウザなどで、UTF-16のサロゲートを表示できたとしても、テキストデータを処理するプログラムがきちんとサロゲートに対応しているかはまた別の話です。私の見るところでは、まだまだこうした、サロゲートがあるとおかしくなることは見かけるように思います。

こういうのは個々のプログラマがちゃんと処理せよというのはなかなか難しい話で、標準的に用意されているライブラリが、普通に使えばサロゲートがきても問題の起こらないような仕組みになっていることが必要でないかと思います。

普通のプログラマにとってサロゲートの必要な場面というのは想像しづらいかもしれないし、また想像できたとしてもそれがあまり頻繁に起こらないことであれば、必要になるまで後回しでいいやと思うのはいかにもありそうなことです。私だって、使い捨てのプログラムなら「あーこれはサロゲートがきたら駄目だねー」と思いながらそのままにすることがあります。それが使い捨てで済まずに生き延びたりすると地雷になるのですが。

悲観的な見方をすれば、UTF-16が使われている限りはこうしたトラブルはなくならないのかもしれません。

トラックバック(0)

トラックバックURL: http://yanok.net/yanok/mt-tb.cgi/480

コメントする

最近のブログ記事

National Geographic Your Shot で Daily Dozen に選ばれた話
ブログをさぼっている間に時間がずいぶん経…
情報処理学会から山下記念研究賞を頂いた話
ブログをさぼっている間に時間がずいぶん経…
Go と Rustの文字列
Go言語における文字列はUTF-8のバイ…
『[改訂新版] プログラマのための文字コード技術入門』のページ作成
発売されてから半年以上経ってようやくのこ…
『[改訂新版]プログラマのための文字コード技術入門』発売!
ばたばたしていて当サイトの更新も怠ってい…

広告