JIS X 0221:20072008年01月29日 00:19

やや旧聞に属しますが、JIS X 0221:2007が先月出ました。

JISCのサイトから閲覧できるPDFも新しいものに入れ替わっています。初日に覗いてみたら、何にもない状態だったので驚きました。入れ換え中だったのかもしれません。

今回からは、CD-ROMがついてくるので、JSAのサイトではPDFのダウンロード販売をしないようです。CD-ROMの内容をWebから見えるようにしてくれればいいのですが、というのは無理なのですかね。

規定内容としてはWebからダウンロードできるISO/IEC 10646とamendmentふたつとおんなじなので、英語が苦にならない人はそっちに流れるのでしょうね。

基本Unicodeか拡張Unicodeか、それが問題だ2007年08月14日 17:01

今はちょっと落ち着いたようですが、Windows VistaといわゆるJIS2004の対応で、いろいろと困った人もあったかも知れません。でも、困った事態になるのは、よく考えるとちょっと変な気がします。なぜなら、Windows はUnicodeに対応しているから世界中の文字を扱えるんだということになっていたはずなのに、JISで追加された文字を扱うのに何だって新たな対応が必要なのでしょうか? それを説明するためには「基本Unicode」と「拡張Unicode」という区分を導入し、これらを別の文字コードとして扱う必要があるように思います。

「基本Unicode」とは、当初計画された16ビットの範囲内のUnicodeです。Unicodeの基本多言語面(BMP)といってもいいですね。基本Unicodeの範囲内のUTF-8を「基本UTF-8」と称します。つまり最大3バイトの長さになります。同様に、「基本UTF-16」もあります。これはUCS-2と同等です。

一方「拡張Unicode」とは、plane 16までを扱えるようにしたUnicodeです。ここまで対応したUTF-8を「拡張UTF-8」と称します。4バイトまであります。同様に、「拡張UTF-16」はサロゲートペアに対応したUTF-16です。

こういう区別を導入すれば、事態はもっとすっきりします。今までは基本Unicodeに対応していたプログラムを、拡張Unicodeに対応させる必要が生じたので、Vista対応で新たな処置が必要になったわけです。

ここで重要なのは、基本Unicodeと拡張Unicodeは別々の文字コードであるという認識です。そこをごっちゃにするから問題が生じるのです。少なくとも、Shift_JISとShift_JIS-2004とを区別して考えるのであれば、基本UTF-8と拡張UTF-8も区別しないとおかしいのではないでしょうか。

Unicodeのうつわ2007年04月11日 21:31

画像のような文字列をUnicodeで符号化するとしたら、どのようなコードポイントの列になるでしょうか? JIS X 0213でいえば、1-20-79, 1-15-22 です。

日本人、あるいは日本向けのソフトウェアであれば、おそらく U+5668 U+FA38 というコードポイントを用いるでしょう。前者はJIS X 0208の20-79をソースとしており、後者はJIS X 0213で追加された字に相当するからです。ここには何も疑問がなさそうに思えます。

ところが、台湾の人、あるいは台湾向けのソフトウェアであれば、おそらく U+20F96 U+5668 というコードポイント列になるのではないかと思います。なぜか…って、だって、Unicodeの文字表を見ればそうなっているではないですか。ちなみにU+20F96は台湾ソースです。

おや、同じ文字列を同じUnicodeで符号化するのに、日本風のやり方と台湾風のやり方とで違う結果になってしまいました。これは何としたことでしょう。

実際にそんな風になるのか? という向きには、Webで試してみる手があります。テスト用のページを作ってみました。これを表示するには、Unicodeの拡張Bに対応したフォント (Han Nomなど) が必要です。HTMLソースも参照のうえ、吟味してみて下さい。