未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

プログラマのための文字コード技術入門を読んだ

例えば、次の言葉の意味を知りたい、聞いたことがあるけどよく分かっていないプログラマにとって、お勧めの書籍だ。Unicode/UTF-8/UTF-16/USC-2/JIS X0208/JIS X0212/JIS X0213/SJIS/EUC-JP/CP932/ISO-2022-JP/ASCII/Latin-1/ISO 10646/ISO 8859-1/サロゲートペア/文字化け/機種依存文字/半角カナ/絵文字…

JIS X0208やJIS X0213の解説などは圧巻である。書籍にはWebにない利点がある。Webには即時性があるが、文字コードの解説においては、即時性はそれほど求められない。字体ないし字形の差異についてWebではその字体ないし字形がなければ表現しようがないが、書籍であれば細部までこだわって表現できる。

例えば、包摂された「辻」という字の一点しんにょうと二点しんにょうの字体の差はWebでは表現しようがない。Unicodeに含まれていない文字もWebでは表現しようがない。それが書籍であれば、文字通り、その字形が表現されているので、一目瞭然である。

プログラミング言語と文字コードの章ではJavaとRuby 1.8および1.9を題材として取り上げている。Javaは当初からUnicodeをcharとして設計していた数少ない言語である。一方Rubyは1.9において内部コードをCSI(character set independent)にした。それぞれの特徴についてわかりやすく解説している。

また、第8章には、「はまりやすい落とし穴とその対処」というトラブルシューティングの傾向と対策が記されているし、Appendixには、ISO/IEC 2022のもう少しだけ詳しい説明や、JIS X0213の符号化方式、諸外国・地域の文字コード概説、（わたしは北朝鮮の文字コードがKPS 9566というのを初めて知った）、そしてUnicodeの諸問題ということで絵文字の標準化なども取り上げている。

プログラマにとって必要な文字コードの技術的課題について網羅的にバランスよく取り上げられていて、入門書としては最適だと思う。さらに突っ込んだことを理解したければ、国際標準など原典にあたればよい。本書の知識があれば、標準なども読みこなせると思う。

良書である。

閑話休題

文字コードというお題でいろいろ昔話をする。おい、また昔話かよ、じいさんの昔話はうんざりだよ、という人は下記どうぞスルーしちゃってください。（ぺこり）

文字コードのお話は、すぐに標準の番号、例えばJIS X0208とかISO/IEC 10646とかわけのわからない番号が出てきて取っつきにくいし、Webの情報なんかも、本当なのか本当じゃないのか、正しいのか正しくないのかわけがわからない玉石混合のものにあふれていて、初心者には敷居が高いものの一つだと思う。先輩に聞いても、要領が得ないし、困ったなという類のものかと思う。

プロとしては文字コードは押さえて置きたいところであるが、今ひとつ興味がわかない。と勝手に想像して書いているのであるが、文字コードが三度の飯より好きという人もいなくはないと思うが、それは例外。

わたしがプログラマを始めた80年代中頃には、Unicodeはなかったので、いろいろな人が、世界中の文字を集めた大きな文字コードは、どーあるべきかと試行錯誤していた時代だった。

情報交換用漢字符号（X0208）というJISの規格があって、それの1990年改正の委員会になぜか出ることになったのが1988年のころ。ハードウェアベンダーのエラい人とか国立国語研究所のエラい人とか、錚々たる委員がいる委員会の末席を汚していたのが20代の若造であるわたしだった。まあ、そのおかげで文字コードのアーキテクチャとか、UnicodeあるいはISO/IEC 10646の開発、標準化のプロセスをライブで体験出来たのは本当に僥倖（ぎょうこう）であった。

文字コードの標準を作るというのは情報化時代の辞典を作るような作業であるから、それはそれで大変な作業であるけど、一般には知られていないあれやこれやがある。

本書の3章にJIS X0208の解説があって、過去の改正の概略などが載っている。

多くの人は知らないが、皆さんが日頃利用しているこの漢字符号は1978年に最初に標準になってから、83年、90年、97年と大きな改正をされてきた。83年という時代背景は世の中の情報処理の王道はメインフレームが司っていた。PCは出始めたころで、IT業界のメインストリームではなかった。標準もメインフレーマが決めるものというような時代だった。マイクロソフトはそれほど力を持っていなかったので、シフトJISがその後、業界標準になるということは誰も予想していなかった（マイクロソフトの古川さんとかは予想していたかもしれないけれど、それは少数派だった）。80年代中頃、Unixワークステーションも出始めのころだったので、DEC漢字コードを参考にEUCなどが開発されていたが、業界の秩序はメインフレームベンダーが握っていた。

1983年の漢字符号の改正は、字体の変更と符号位置の入れ替えという、今考えるとありえないだろうそれはというようなラディカルな改正をやってのけた。

字体の変更というのは、森鴎外の「鴎」の編を「區」から「区」という風に変えてしまった。今でこそ「鴎」という字体も見慣れたが、83年当時、大きな問題になった。例えば、国語の先生がテキストを作るとき「森鴎外」などとやると、間違った文字が出てくるということでベンダーに苦情が行ったりした。この字体の変更というのを大胆にやって、小規模なものを含めると300文字近くの文字の字体が変更されたのである。

符号位置の入れ替えというのは、鴬（うぐいす）、鶯という２つの異体字があって、前者が第1水準に、後者が第2水準に、現在の標準ではなっているのだけれど、1978年の規格では逆になっていて、83年の改正で入れ替えられたものである。それが22組あるとされている。

いくらなんでも、符号位置を入れ替えるのはまずいでしょう。というようなことをかなり無頓着に大胆に行ったのが83年改正なのである。

90年改正は、(1)この83年改正の混乱をどうにか収拾したいというのと、(2)足りない文字を追加するという要求にどう答えるか、という２つの目的で開発された。実のところ、一度規格を作ってしまってそれによる実装が広く世の中に出てしまった以上、83年改正をちゃらにして（本当はちゃらにしたかったのであるが）、78年に戻しましょうというのは事実上できないのである。従って、悪法も法なりということで、その部分については塩漬にして、追加文字についてどうするかというのがJIS原案作成委員会の主なテーマであった。

本書においては、X0208の90年改正についてわずか11行で解説されていて、ほとんどなかったことになっている。実はX0208の改正時にJIS X0212というのが同時に開発されたのである。このX0212こそがX0208の90年改正の目玉になるはづであった。つまり当初X0212というのは独立した規格ではなく、X0208に足りない文字を収拾し、X0208の改正として取り込むという文脈で開発していたのである。

結局X0208の改正として6000文字を越えるあらたな文字の追加することはベンダーの強い反対によって実現せず、X0212という別規格として極めて使いにくい形で制定された。そしてベンダーは補助漢字について使いにくくすることによってなかったことにするのであるが、Unicodeに採用されたので、皮肉なことにUnicodeが普及するにつれてX0212に含まれている文字を利用できるようになったのである。

その後Unicodeが普及して行ったのは皆様の知るとおりである。

合わせて読みたい： そろそろUnicodeについて一言いっておくか -- 未来のいつか/hyoshiokの日記 http://d.hatena.ne.jp/hyoshiok/20090419#p2