未来のいつか/hyoshiokの日記

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

そろそろUnicodeについて一言いっておくか

文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(2008年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1

もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。
その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。
そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たるベンダーの方と印刷業界の方、それから国立国語研究所の先生とか、そんなような方々がいて、一応この業界で標準作るわけです。
当時は先程お話した通り垂直統合型だから、建前では「標準を作りましょう。標準があればみんな便利ですね」と言うんだけど、どの会社も実は自社の拡張部分があって、文字コードといってもJIS X 0208を素直にインプリメントしてる会社はなくて、メインフレーム用の文字コードが拡張漢字を持っていたから全然互換性があるわけないんですよ。
だから建前では「標準作りましょうね」みたいなこと言うんだけど、メインフレームは如何にして文字コードをロックインして自分のお客さんのスイッチングコストを高くするかということにエネルギーを注ぐわけですよ。
私なんかそういう事情を知らないから「標準化か、みんな理想に燃えてて素晴らしいな」なん思っちゃったわけですよ(笑) しかも外資系だから、そういう空気分かんないわけですよ。30のペーペーのお兄ちゃんなんだからね。それで皆さん大人の言葉を喋ってて、私はもうちんぷんかんぷんなんですね。
それでその0208の改正をするということの意味は2つあって、技術的なものもあるんだけど、もう1つは 0208では足りない文字があって追加要求が来てますということなんですね。でも追加要求が来るっていうことは、「富士通」や「IBM」や「NEC」だって「三菱」だってみんな拡張文字を持ってるんだから、知ってるわけですよ。当たり前の話なんだけどね(笑) だけどX 0208の約6000文字から7000文字に関しては塩漬けで、ここに更に6000文字とか7000文字を新規に追加するのはとんでもないと、本音を言ったらそういうことなんですよね。
自分たちのプロプライエタリ文字コードとかあるから、それから新規に追加した文字コードに移行しようなんて初めから本気で思ってないんですね。

20年前だったら絶対言えない本音を時効が来たのでばりばり言っている。上の発言は20年前だったらオフレコでも多分言えない。若い人は上記の歴史の証言を生まれていないからスルーしちゃうけど、時代は垂直統合と言って、メインフレーマーがハードウェア(メインフレーム)からOSからコンパイラからRDBMSからミドルウェアからアプリケーションのインテグレーションから運用まで一切合切握っていたというころである。
ユーザーをロックインして、スイッチングコストを高くして、利益を確保するというビジネスモデルである。かつての日本のメインフレーマーは、IBMに追いつけ追い越せでハードウェアやOSをいかにパクって、ユーザーを自社ハードに引き寄せるか、そのような商売をしていた。日立製作所三菱電機の社員がIBMのOSのソースコードを違法に米国国外へ持ち出そうとして逮捕されたりした時代である。
本音と建前の標準化の世界である。

それで、私はそういう事情を全然知らないから「そうか6,000文字とか7,000文字もみんなと協力して新規に追加するなんて大変だな・・・」なんて素直に思ってるわけです。「今度の 0208は、文字数倍くらいになっちゃうのか・・・どうやって実装するのかな?ソフトウェアとか書き変えなくちゃいけないのかな?」なんてナイーブに思っちゃってて、会社に戻って「みんなと検討しないと、凄い大変なことになってますよ」なんてことを思ってるわけですよ。大きな勘違いなんだけど・・・。

若いって、業界のお作法を知らないから。

もう一方でISO(国際標準化機構)って組織があるんですね。その中にSC 2/WG 2っていうグループがあって、マルチバイトの文字コードを研究開発して標準を作りましょうっていうグループなんですね。それで1984年の私が新入社員の時に第1回会合が京都で開かれたと思うんです。要するに日本でJISの2バイトの文字コードが非常に成功して、それがあることによって例えばワープロみたいなものを皆が利用できるようになったので「標準化は素晴らしいな」となったんですね。メインフレームの人は建前としてだけで、そうは思ってないんですけどね。パソコンとかが出てきて皆で文字コードを交換できるようになって、パソコンでワープロみたいなのも出てきて、みんな便利になっていいねみたいなのがあったんですね。それで中国とか韓国もある程度参考にして、それぞれGBって規格作ったりKSっていう規格作ったりしたんですね。当然そうなってくると、それを国際標準にしましょうっていうある意味で言うと分かりやすい話になってくるわけですよ。それがSC 2/WG 2っていう所で開発されてました。最初は日本の規格と中国の規格と韓国の規格を1面ずつ持って行って大きなテーブルにマージしようなんていう感じでやってたんだけど、やっぱりなんやかんや言ってそれだけじゃ足りないなっていうことがだんだん分かってきたんですね。

最初は2バイトの国際標準にしようというお話だったのだけど、それじゃあ足りないから4バイトにしよう。しかしバイトというのは何ビットか不明なので、Multi-Octet(8ビット)の標準を作るということになった。

例えば大漢和字典なんていう辞典には親字だけでだいたい50,000文字くらいあるから、そうすると16bitだとベターに使っても64,000ぐらいしか入らないんですね。
大漢和でもういっぱいいっぱいだとすると、中国とか韓国とかを持ってくると16bitではちょっと厳しいかなということが研究していくうちにだんだん分かってきて、今から20年前にですね「Apple」と「Xerox」の人たちが16bitで世界中の文字を表現しようということで、 Unicodeっていう仕様を提案するわけですね。
バージョン1.0のUnicodeっていうのは、あまりにも杜撰だったんで、そのまますぐには使い物にならなくて国際標準の世界では1度は否決されたんだけど、とりあえず16bitでガッツリ行こうぜっていうコンセプトのもとでもってきたんですね。
日本のベンダーをはじめ「IBM」も「DEC」もそうなんだけど、今ある文字コードを全部チャラにして丸っきり互換性のないものを導入するにはあまりにもコストがかかるし、「それはいくらなんでも厳しいんじゃない?」みたいな感じだったんですよ。

当時ISOで議論されていたドラフト(DIS 10646という)はデフォルト2オクテットで各国のJIS/GB/KSなどの標準をそのまま94*94の面を4つ用意してそこに埋めるという案だった。1オクテットのコードとの混在は考えていない、2オクテットのみという使い方。混在したい時はエスケープシーケンスでやってね。という今から考えても実にアバウトな設計だった。94*94なのでコントロールコード(0x00〜0x1f)および空白(0x20)、削除(0x7f)などの部分が避けられていた。

一方Unicodeの方は94*94ではなく、べたに0x0000~0xffffまで使うということで、1オクテットでみると0やコントロールコードなどが入っているので、そのままではCの文字列(char *)に使えないなどという問題もあった。

だけどマルチバイトのユニバーサルな文字コードっていうのは絶対に必要だねっていうのが、ベースのベースではありましたね。でも、ベースのベースではあったんだけどJISのX 0208ですら同意しようとしていない日本のベンダーは「そんなもんは絵空事で、20世紀中に出てくるわけねぇ」みたいな感じで、言うのは簡単だけど誰も使いやしないし実装もコスト高くなるし、いったい誰がそんなもん使うんだみたいな感じでしたね。Unicodeを皆で標準化しようなんていうことに関しては、むしろ足引っ張るみたいな感じだったんですよ。本来なら尊敬すべき偉い人だと思うんですけど、会社の事情でエンドユーザに対して迷惑かけてるなと、そういうことを平気でやるんだこの人たちはと、30歳ぐらいの青臭い私は思うわけですよ。

私は思うわけだ。世界のソフトウェアが初めから世界の言葉をサポートする世界がきたら素敵だなと思うわけだ。思うのは自由だ。それを実装するのは大変だけど。

一方で、Unicode作ってる連中の最初の提案はボロボロだったんだけど、この1つのものを皆で作ればソフトウェアの作りも簡単になるし、一発ソフトウェア書けばそれが世界中の人たちに使われるんだっていう極めて分かりやすい理想を掲げてるわけですよ。
そういうのはメインフレーマーじゃなくて「アップル」とか「マイクロソフト」とか「サン・マイクロ」とかいう割と小さい会社だったりして、徐々に私はそっちの方に共感していくわけですよ。
その16bit の文字を使うためにコンパイラはどういう風に変えなくちゃいけないのかとかね、それをするために「OSはどういうような仕組みにしなくちゃいけないのか」とかっていうのを必死になって考えて、例えば「マイクロソフト」ならWindowsNTUnicodeをはじめから採用しますとか、CのコンパイラUnicode用のwchar_tみたいなのを作りますとかいう色んなことをベースからどんどんどんどん作っていくんですね。
それはそのUnicodeならUnicodeっていうことで、「アップル」も「IBM」も「サン・マイクロ」も「HP」も「DEC」のエンジニアも共同で協力してなにがしかを作るという感じでしたね。
もちろん企業間競争はあるんだけど、足の引っ張り合いじゃなくて、いいものを作るっていうことに関しては腹割ってやるっていうエンジニアの非常に真面目な技術に対するロイヤリティの高さっていうのを垣間見て「おぉこいつらすごいなぁ・・・」と、こういう人たちと仕事したら気持ちいいだろうなっていう風に思いましたね。

会社や国の壁を越えてコラボレーションするのは本当に面白い。素晴らしい経験だったと思う。

そこが非常に私にとってはアイロニーの部分なんです。日本の企画(まま)委員会に入ったが故にそういうものを見て、国際標準の世界を見、180度違うパラダイムがあって、垂直統合から水平統合に世の中が変わっていく瞬間を見、「DEC」っていう会社がなくなっちゃって、90年代になって「オラクル」っていう会社に転職をしたんですね。だからある意味で言うとメインフレーム型の垂直統合の典型的な会社から、水平統合の典型的な会社へ転職したんです。その表と裏にはやっぱりJISの委員会とISOの委員会の表と裏があったんですね。ISOも本音部分ではドロドロした部分があったとしても、いかに建前を尊重して理想に近づけていくかっていうことを各社の標準化委員会に出てきている人たちエキスパートは相当真面目にやってましたね。

国際標準の世界ももちろん政治的かけひきや本音と建前はあるけど、だけど、わたしのユメであるいつの日か世界のソフトウェアが初めから世界の言葉をサポートするんだというものに、本音がどうであれ、皆共感してくれたと思う。ユメをみんなで共有していたような気がする。

日本人は英語が不得意だからとか世界標準を作るのが不得意だからと訳知り顔で言う人がいるが、そんなのは嘘である。本当に標準を作りたいのであれば英語は問題ではない。志の問題だと思う。

で、当時の日本のメインフレーマに所属していた人たちは世界標準を心の底から作ることを望んでいなかった。少なくとも作ることに本気ではなかったように思う。

非常に残念である。

もし、Unicodeをよくすることに、彼らが協力していれば、日本のソフトウェア産業もひょっとしたら輸出産業になったかもしれないが、歴史はそうはならなかった。