UCSの包摂規準を明確化する試み ― 2007年03月24日 18:57
漢字データベース計画の「UCSにおける包摂規準（α版）」が素晴しいです。JIS X 0213の包摂規準をベースにISO/IEC 10646 UCS (といわれてピンとこない人は、Unicodeのことだと思っていいです) の漢字集合の包摂規準に相当するものを作成しようという試みです。
これは、ISO/IEC 10646の規格の中に盛りこまれて然るべき内容であると思います。規格で規定されて、電子データの形でも入手できるようになれば、文字の入力や検索の際の役に立つことでしょう。こうしたデータが完備して初めてUnicodeは使いものになるのではないでしょうか。
それにしてもこれ、規格票を目で追って手作業で作っていたら死にそうになると思うのですが、どのように作業しているのかが興味深いところです。そこは "Kanji Database Project" だけに、きちんと作業インフラが整っているのでしょうか。
Unicode正規化の問題点(1) ― 2007年03月11日 23:55
「マイクロな話とオングストローム」の中で「正規化を行えば別ですが」と蛇足のように付け加えたのは私の勘違い、誤りでした。
というのは、Unicodeの正規化では実は、マイクロ記号はギリシャ文字μに正規化されないのでした。オングストローム記号は「上リング付きA」に正規化されるのに、です。
なぜこうなっているのかは不明ですが、邪推するに、ISO/IEC 8859-1を特別扱いしたかったからではないでしょうか。マイクロ記号が正規化でギリシャ文字μに変換されてしまうと、「8859-1 → Unicode → 正規化 → 8859-1」という変換を施したときに元に戻らなくなってしまうのです。それを避けるために、敢えて正規化対象から外したということではないでしょうか。
ちなみにJIS X 0208相当の文字では、上記のオングストローム記号が正規化の影響を受けるために、「JIS → Unicode → 正規化 → JIS」と変換するとJIS X 0208の範囲からはみ出してしまいます。こちらの問題については、Unicodeの人は特別な関心を持たなかったのでしょうね。
こういう一件を見ると、国際的な公平性を確保するのは難しいのだなぁという感想を持ってしまいます。
新しい符号化方式って何だろう ― 2007年01月18日 21:32
「JIS X 0213の代表的な符号化方式」を更新しました。2004年改正に対応したときに2000年版の符号化方式名をすっぱり削ってしまったのを反省して、2000年版との対応を記しました。また、Unicodeを使う際の問題点を新たに付け加えました。
これを書いていて思ったこと。JIS X 0213対応を躊躇している人の言い分として、「いまさらUnicode以外の新たな符号化方式に対応するなんて…」ということを聞くことがあります。この「新たな符号化方式」という言葉には要注意だと思いました。
Shift_JIS-2004という「新たな符号化方式」に対応するには何が必要でしょう? 区点位置との計算が必要な場合には、確かに2面の分は新たな計算式を実装する必要があります。でも、それってそんなに難しいですか?
EUC-JIS-2004への対応はどうか? 今までEUC-JPに対応していたのなら超楽勝ですよね。
ISO-2022-JP-2004は? 古いエスケープシーケンスで出力することを考慮しなくていいなら、割に簡単でしょう。
これらは確かに「新しい符号化方式」ですが、対応がそんなに困難だとは思えません。(というか、JIS X 0213自体、そのように設計されているわけです)
翻ってUnicodeではどうか。名前だけは確かにUTF-8でありUTF-16であるかもしれない。でも、今まで対応していなかった結合文字やらサロゲートペアやらにプログラムで対応する必要が新たに生じたのなら、それって事実上「新しい符号化方式」なのではないですか?
もちろん、処理を楽にしてくれるライブラリがあるのならそういうのを活用すれば良いわけですが、どっちみち古いプログラムはそういうのを使ってないわけなので、新たな対応が必要なのは変わりないわけです。大変ですね。
単に名前の違いだけしか見ずに新たな符号化方式だ、いや違う、と言っていると、落とし穴が待っているかも知れませんね。
最近のコメント