Around the System and Development》データと文字コード(6)ISO-2022-JP
カテゴリー
テキスト/フォント, Around the System and Development
作成日
2002/3/20 19:7:44
作成者
新居雅行
いままで、いろいろな漢字コードの話をしてきたが、その話を受けて、ISO-2022-JPの説明をしなければならない。ISO-2022-JPはメールのデータフォーマットあたりででくるので、目にすることも多いかもしれないが、単純にこれをJISコードであるというのはやや間違いである。そもそも、ISO-2022というのは、文字コードの体系の中で言えば、平たく言えばエスケープシーケンスの規格である。さまざまな文字コード体系を切り替えるにはどうするかといったことを子細に規定した規格である。そこでは、JISとかASCIIといった問題ではなく、汎用的なデータの扱いが定義されている。 こうした規格がある中、インターネットの普及とともに、インターネットで日本語をやり取りすることを可能にするコード体系の必要性が生じた。90年代前半のことであり、当時は、インターネットの通信は7ビットでも問題がないようにするということが基本であった。まず、漢字の表現はJISコードがちょうど7ビット×2だったのでちょうどいい。ただし、新JISと旧JISで同じコードなのに文字が違う場合があることから、これらを明白に区別することを意図した。また、アルファベットや数字の表現にはASCIIコードを利用するのであるが、一方で、JIS X 0201もある。これらをまとめたのがISO-2022-JPなのである。ここで、1バイトのコードでも7ビットを原則と考えれば、JIS X 0201に定義されているいわゆる「半角カナ」つまり、A0H〜DFHまでの文字コードは排除される。従って、ISO-2022-JPにおけるJIS X 0201というのは、その中の7ビットで表現可能な範囲の文字だけという限定されているのである。そして、ここで、4つのコード体系、つまり、新JIS、旧JIS、ASCII、限定されたJIS X 0201が集まった。それらの切り替えを、決められたエスケープシーケンスで行うというわけだ。 つまり、これまでも、JISコードで漢字を表現するとき、そこにASCIIコードの文字を混入させるために、エスケープシーケンスを使っていたが、そうした暗黙の複合コード体系を、1つにきちんとまとめたのがISO-2022-JPであるとも言えなくもない。また、エスケープシーケンスとして使っているコード群も従来と違いがないわけではなく、みかけ上は、今までの「JISコードで記述した文字列」とまったく同じになっているのである。ただ、新JISと旧JISを切り替えたり、あるいは同じコードでもASCIIならバックススラッシュだけど、JIS X 0201では￥記号といった場合でも、その気になれば切り替えることができるというわけである。もっとも、うして切り替えてきちんとISO-2022-JPにのっとったデータを作ったところで、たとえばそれを受信して保存する段階でシフトJISにしてしまうと、結果的にバックスラッシュか￥のどちらかにせざるを得なくなるのである。
文字列については、さらにここからUnicodeという長い長い説明が必要になるが、残念ながら、それを説明している余裕がない。おおまかなところを説明しておこう。Unicodeは、世界中にある文字にそれぞれ番号を割り振ることで、文字列データの他言語対応を可能にするものだ。もともと英語のことしか考慮していない文字コード体系を世界の言語に対応させようというものである。日本語、韓国語、中国語といった文字の種類がたくさんある言語のことを考えて、当初は16ビットの番号をつけるということになっていたが、さらにいろいろな事情で32ビットに拡張されるなど、まだ固まり切ったものではない。それに、単に文字にコードを割り振るということだけでも、言語ごとの複雑な事情が絡む。英語はアルファベットで構成されるという非常にシンプルだが、日本語独特の複雑さは当然御存じのことだろう。たとえば、人名では「斉藤」「斎藤」などのバリエーションがあるし、日本語と中国語で同じに見える文字が、はたして文字として同じなのか違うのかといった議論など、Unicodeにまつわる問題はたくさんある。 人名ではある意味では同じ文字なのに、実にさまざまなバリエーションがある。それは、発音するという意味では同じでも、固体識別に使う上では違うものである。だから、それぞれ違う文字である。それらの文字を全部別々のコードに割り当てるというシンプルな考え方もあれば、それをある程度にしぼってつまりは微妙な違いでも同じ文字と見ようとするという考え方もある。こうした、コードとどんな文字が割り当てられるのかと言ったことは、ABC…に順番に番号を振るといった事情を超え、結果的に文化的な背景の議論になってしまったり、さらにはよく言われる「宗教的」な議論にもなりがちである。議論は必要だけど、固まらない規格ほど無意味なものはないだけに、早急に決めてしまうことが先決だという考え方もあるだろう。とにかく、Unicodeの世界に入ると、割り切れないことが出てきてしまうということである。 ただそれでも、プログラミングを行う上では、Unicodeの存在を抜きにして語れなくなってしまった。OSの内部は、もはや、Unicodeをベースにして動いているのは、Mac OS XもWIndowsも同様である。そして、プログラミングでの問題点は、結果的に作るプログラムの内容に対応して、必ずしも他のひとたちと問題は一致しないだろうし、利害も一致しないかもしれない。こうして、業界内で対立が生まれるということもある。そうしてUnicodeと言えば、みんな腰が引けてしまうという状況になってしまったのである。