Unicodeサポートの現状

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

最近のJavaの更新版のリリースノートを見ていたら、こういうバグが修正されているのが目にとまりました。

XML文書の構造を変換するXSLTの実行において、部分文字列を得る関数にBMP外の文字を与えると結果が正しくないという話です。サロゲート1個を1文字分として勘定した結果になってしまうというものです。今年の3月に報告されています。

いかにもありそうなバグです。2015年になってもまだこういうバグが出てくるのだなあという感想を持ちました。

先日、拙著「プログラマのための文字コード技術入門」のEPUB版に関して、Unicodeで結合文字を用いる必要のある文字がEPUBの処理環境でうまくなくてPDF版よりも提供が大幅に遅れたということを書きました。サロゲートだけでなく結合文字についても、というか多分こちらの方がより長く(あるいは多く、またはその両方)、トラブルが続きそうに思えます。

悲観的にいえば、Unicodeあるいはその処理環境が今と同じ仕組みであれば、こうした種類のトラブルは半永久的に続くのかもしれません。

トラックバック(0)

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

コメント(7)

> 悲観的にいえば、Unicodeあるいはその処理環境が今と同じ仕組みであれば、こうした種類のトラブルは半永久的に続くのかもしれません。

後付けのサロゲートペアはともかく、結合文字はインド系の文字等を扱うためには必ず必要になる (かつ、それらの国々で運用されてきた実績を持つ) ものなので必要悪のような言い方は違うのではないかと思いました。

結局、『小形克宏の「文字の海、ビットの舟」』の第一部、第5回 (http://internet.watch.impress.co.jp/www/column/ogata/part1_5.htm) で芝野さんが述べておられるように「Unicodeは未完成」なのだと思います。世界中の文字を扱うのであれば、当然、永久に未完成にならざるを得ないと思います。それでも確実に成果はあがっているとも思います。

結合文字については、元々そうした仕組みありきで成り立っているケース(インドの言語が該当するかもしれません)であればそれは一理あるかもしれません。しかし、欧州言語や日本語の文字のように元々合成済みの符号位置を用意しておいて「これは16ビット版のASCIIだよ」という触れ込み(Unicode Standard, Version 2.0)であたかも騙すようなことをしてきたので、結合文字のサポートが遅れるのは仕方ないと思います。だって実際、私はこの十何年、この問題によるトラブルをいくつもいくつも経験してきて、今現在だってOS XのEmacsでアイヌ語表記に頻出する「ㇷ゚」がまともに表示されなかったり、記事本文に書いたようにEPUB版の発売が半年も遅れたりしているわけですよ。観念的な話でなく、実務上の話です。

追記。私だって、自分用の使い捨てのプログラムなら「これはサロゲートが来たらアウト」「結合文字が来たらアウト」「互換漢字が来たら残念」というコードをいっぱい書いています。その方が楽ですし、問題がごく稀であるなら経済的な理由で正当化されます。そういう仕組みになってしまっていることが問題だと考えています。

私の言い方が悪かったために不快感を与えてしまったようでお詫びします。JIS X 0213の実装の普及が遅れているために 多くの不利益を受けておられることは理解しているつもりです。

観念的な理想論ではなく、あくまでも実務上の手段について述べているつもりでした。確かに (例えば) Shift_JIS-2004 等の実装が普及すれば問題は解決すると思います。ただし、現時点で Shift_JIS-2004 の実装が広く普及する可能性は低いと考えています (私見です)。それよりは、Unicodeの実装を進めた方が現実的だと思っています。

別にUnicodeを使うなということは一言も言っていませんし、そんなつもりもありませんよ。ただ、今のUnicodeやそれによるプログラミングの現状を踏まえると、サロゲートや結合文字を用いる文字(特にアイヌ語表記用片仮名)のサポートがどうしても後手に回ってしまう構造になってしまっているということです。

Shift_JIS-2004は当記事では一言も触れていないのでなぜここに出てきたのか分かりませんが、これをきちんとサポートすることは重要です。なぜなら、内部的にUnicodeを使う実装でShift_JIS-2004の文字が全部きちんと扱えるようにすれば、本記事で触れたサロゲートや結合文字を使う文字の扱いも必然的にサポートされることになるからです。

なぜかShift_JIS-2004とUnicodeを対立するもののようにとらえていらっしゃるようですが、そんなことはないですよ。現にPythonやJavaでは内部処理がUnicodeで入出力にShift_JIS-2004を用いることが可能です。

Shift_JISは関係ないということは了解しました。JavaでShift_JIS-2004を用いることが可能なのは存じております。Javaだと結局のところプログラムで処理するコードはUTF-16になるので、扱いが大変で駄目なのかと誤解していました。

ちょっと仰っている問題点が解らなくなってしまっています。もしよろしければ、もう少しお付き合い頂ければ幸甚です。

問題としておられるのが、
・Unicodeは実装が大変なので困る
・Unicodeは本当は実装が大変なのに、手抜きの実装でもそこそこのことができてしまうのが良くない
のどちらなのでしょうか。(どちらでもない?)

この記事で言っているのは、「現状Unicodeサポートにはこの手のトラブルが起こりがちで、こういう状況は多分まだ続くんじゃないかなあ」ということだけです。ただそれだけです。

あと強いて言えば、その背景として私が考えているのは、挙げられた後者の方に近いのだと思います。(ただそれはこの記事本文が主張していることではありません)

コメントする

最近のブログ記事

どうせクレジットカードを持つなら出身大学の支援になるものはどうか
大学カードというものがある 今や生活に欠…
「など」の使い方
曖昧な言い方が好まれる風潮があると感じて…
日本の文字は「表イメージ文字」でいいのか
笹原 宏之『漢字に託した「日本の心」』 …
Creative Commonsライセンスの作品は無条件で使って良いわけではない
他人の写真や文章を盗用・コピペする「キュ…
「小樽雪あかりの路」の魅力
北海道の冬のイベントというと札幌の雪まつ…

広告