川俣 晶(かわまた あきら)
1964年4月生まれの東京出身。東京農工大化学工学科を卒業後,マイクロソフトでMicrosoft Windows 2.1~3.0の日本語化に従事。現在はピーデー 代表取締役。日本XMLユーザーグループ代表。Microsoft Most Valuable Professional(MVP)。

Windows 95の最大の被害者は誰か?

 本題に入る前に,長々と余談を書いてみよう。Windows 95がいかに多くの禍根を残し,それが今日の私達にも面倒を残したという話題である。そして,今回の本題のような問題が,なぜ深刻な問題として我々の身に降りかかったのか…という理由についての話である。それゆえに解決策を考える際に,少しは役に立つだろう。

 さて,話を始めよう。
 パソコンで漢字を扱いたいというニーズは根強く,ごく初期の8ビット・パソコンの時代にすでにいわゆるJIS第1水準,第2水準(JIS X 0208)という文字を取りそろえ,かな漢字変換によって入力するというスタイルがほぼ完成していたと言える。

 しかし,これがすべてのニーズを満たしたわけではない。常に,第1水準,第2水準だけでは漢字が足りないという欲求があり,これに対応するために,各メーカーが独自に規格外の文字を追加するメーカー外字と,ユーザーが自ら外字エディタを使って文字をデザインするユーザー外字の機能が使われていた。

 このような綱渡りのような方法でしばらくは乗り切れたのだが,電電公社(現NTT)が独占していた通信が自由化されると,そこで綱が切れてしまった。何しろ,パソコン通信のようなサービスを介してコミュニケーションする相手は,同じ外字を使っているとは限らないのである。送ったと思った文字が届かないことも珍しくはない。

 ここで,メーカーやユーザーに依存しない形で,公的に共有された漢字の拡張が強く求められるようになったのである。これが1980年代後期の状況である。

 文字が足りないという要求に対する一つの答が,1990年に制定されたJIS X 0212補助漢字という規格である。これは,第1水準,第2水準と呼ばれるJIS X 0208に追加して使用する符号化文字集合である。

 しかし,これはほとんど黙殺に近い扱いを受けた。なぜかといえば,誰から見ても受け入れがたいものだったからである。まず,メインフレームの世界にはすでに各メーカー独自の膨大な符号化文字集合があり,今さらそれを補助漢字に切り替えることはできなかった。また,パソコンの世界で主流だったシフトJISには,補助漢字の文字をすべて収録するだけの拡張余地はなかったからである。

 ちなみに,補助漢字は主に二つの方向で日の目を見ていくことになる。一つは,UNIXワークステーションで使用されるEUC-JPが補助漢字を利用可能にしたことである。しかし,補助漢字を使うと,ASCIIのアルファベットは1バイト,漢字は2バイトという便利なルールが崩れてしまうため,補助漢字抜きでEUC-JPを使うことも多かったようだ。もう一つは,このあと説明するUnicodeである。

 話を戻そう。
 日本国内にあった漢字が足りないという話は,同時期に米国で起こった符号化文字集合を拡張する話と強く絡み合うことで急速に進み始める。

 しかし,たかだかアルファベット26文字であらゆる文書を書くことができる米国で,なぜ符号化文字集合を拡張しなければならなかったのだろうか?

 その理由は,全世界の言語に対応するためのローカライズの手間とコストが非現実的に拡大してしまった点にある。英語版を作った後,いちいち日本語版,アラビア語版…などなどとソースコードの書き換えを行い,それぞれを別個にメンテナンスするのは膨大な手間がかかる。この問題を解決するために,全世界の文字を一つの符号化文字集合で扱うという構想が支持を集めたのである。これがUnicodeへと結実していく。

 念のために補足するが,初期の時代に「Unicodeは米Microsoftが文化を支配するための陰謀である」という主張が流布されたが,これは全くのフィクションそのもので,根拠がない。事実として,マイクロソフトのライバルである米Apple Computer(現Apple),米IBM,米Sun Microsystemsなども賛同して生み出されたのがUnicodeである。つまり,少なくともUnicodeはアメリカのコンピュータ業界の統一されたコンセンサスとしての解決策なのである。

 実は,初期の段階において,Unicodeとは非現実的な机上の空論以外の何者でもなかった。要するに,日韓中の符号化文字集合の規格の文字を全部足しても16ビットの範囲で表現できるから,16ビットの符号化文字集合を作りましょう…という,まだ符号が与えられていない漢字のことは何も考えていない脳天気なものだったのである。

 それゆえに,Unicodeの構想を持ち込まれた日本のメーカーは激しく批判したという。ちなみに,当時マイクロソフト(日本法人)社員だった私も批判した。Unicodeに対して,日本人は誰も批判をしなかったというのも,よくある都市伝説に過ぎない。

 その後に起こったことを詳しく書く意味はないだろう。実際,私も詳しい事情をすべて知っているわけではない。しかし,多くの日本人のかかわりと努力を含め,Unicodeと,(厳密には一致しないが)それを国際規格としたISO 10646-1は最低限の実用性を備えた形で世に送り出された。

 事実として,Unicodeは日本の日本語ユーザーにとって,二つの決定的な長所をもたらしてくれた。それは,それまでパソコンでは使えなかった補助漢字を丸ごと取り込んで利用可能にしたということと,ユーザーから必須の文字とされながらJIS規格に含まれていなかった丸付き数字などをすべて収録したことである。このおかげで,お役所が丸付き数字を使うルールを強制しているのに,それに従うとJIS規格違反になるというおかしな問題も解消される。

 このような状況に対して,WindowsというOSはどのように対処したのだろうか。

 当然のことながら,Unicodeの採用はOSアーキテクチャの全面的な変更を意味する。これは何回も繰り返せることではない。そこで,すでに時代遅れになった16ビット・アーキテクチャから,32ビット・アーキテクチャへの切り替えと連動して,Unicodeへの切り替えが行われる形となった。

 具体的に言えば,最後の16ビット・アーキテクチャのOSとなるWindows 3.1から,最初の32ビット・アーキテクチャのOSとなるWindows NT 3.1への切り替えタイミングで,Unicodeが全面的に利用可能となるというシナリオである。これなら,16ビット・アーキテクチャのアプリケーション・ソフトを32ビット対応するという大手術の中に,シフトJISからUnicodeへの切り替えという作業を含めることができる。

 このようなアーキテクチャの刷新は,Windowsだけでなく,各所に見られた。例えば,プログラム言語のVisual Basic(VB)では,初の32ビット・アーキテクチャとなるバージョン4.0から文字列型変数に格納する文字をUnicodeに切り替えている。

 まして,その後生まれた新しいプログラム言語やシステムでは,最初からUnicode決め打ちというものも多い。例えば,JavaやJavaScriptの文字列は,言語仕様書でUnicodeが明示されていて,シフトJISを格納する余地はない。

 一部の時系列は前後するが,このような形で進んできたUnicode化の流れに一気に冷水を浴びせたのがWindows 95である。

 Windows 95は,32ビット・アーキテクチャでありながら,非常に限定された機能でしかUnicodeを使用することができなかった。その矛盾は,後継OSであるWindows 98で明確に顕在化する。Windows 98は,補助漢字をフォントに追加して,従来のシフトJISパソコンでは扱えなかった文字を表示可能にした。ところが,表示可能な文字が扱えない機能が山ほどあったのである。

 例えば,ファイルを扱う多くのAPIにシフトJISバージョンしか存在しないために,表示可能な文字をファイル名にしたファイルを扱えないという状況も起こった。ちなみに,ファイル・システムに格納されるファイル名(いわゆる長いファイル名)はUnicodeで格納されるアーキテクチャになっているのだが,APIのレベルでファイル名の受け渡しができねばどうにもならない。

 32ビット版VB 4.0や,Javaで書かれたアプリケーション・ソフトは,文字列型がUnicodeであるため,何もせずとも補助漢字の文字を変数に格納できたが,OSの制約によってその価値を発揮することができなかったのである。

 この状況によってUnicodeの普及は著しく遅れ,当分の間シフトJISは主流であるという誤った印象を多くの人に与えたことは間違いないだろう。これが,Windows 95の「罪」の一つである。

 では,この状況で最も損をさせられたのは誰だろうか。

 まず,WindowsでUnicodeを使おうと思っていた者達が思い浮かぶ。特に,Unicodeを使いたいがために,Windows NT 3.1の後継ソフトとなるWindows NT 3.5~3.51を使うようになった人達から見れば,Unicode対応が不完全というだけでなく,明らかに安定性や性能で劣るWindows 95が世の中にはびこることは納得が行かなかっただろう。

 だが,彼らにはまだ救いがある。少なくとも,Windows NTはシフトJISベースのアプリケーションを実行することができるので,文字の問題さえ妥協すれば,Windows 95用として作られたアプリケーションのそこそこの割合を利用できたのである。

 では,全く救いがない者達はいたのだろうか。筆者は「いた」と考える。

 それが,W-ZERO3のOSであるWindows Mobileに連なるWindows CE系のモバイル系小型Windowsである。

 これらの小型OSは,利用できるリソースが限られているため,最低限の機能に絞り込んで実装されねばならない宿命を持つ。そこで,二つの符号化文字集合をフルサポートするという贅沢は許されない。シフトJIS(あるいは従来のコード体系)とUnicodeのどちらか一つを選ばねばならないのである。

 そして,当然の選択としてUnicodeが採用されている。

 最初のWindows CEマシンは1997年にリリースされているが,もちろんこれはWindows 95が振りまいた「まだまだシフトJISの時代が続く」という幻想と,さしたる根拠のない感情的な「Unicodeバッシング」が横行する時代であった。そういう時代背景の中で,Unicode「しか」使うことができないWindows CEが好感を持って迎えられなかったのは当然の成り行きといえるだろう。

 ここで一つだけ補足しておこう。このように書くと,「いや,Unicodeにはいろいろ問題が…」と言いたくなる読者もいると思う。しかし,1980年代のうちからUnicodeにかかわった立場から言えば,それは討論し尽くされ,とっくに終わった話なのである。情報のインフラがUnicode(とISO 10646)前提で整備されてしまった現状で問われるのは,Unicodeの是非ではなく,いかにUnicodeと付き合うかである。つまり,問題点の指摘ではなく,問題点と上手く折り合って乗り越えていく方法の提案を行うべき時期である。