未来のいつか/hyoshiokの日記

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

仕様と実装の続き

昨日のお話の続き。
70年代の後半、主に日本のハードウェアベンダーは日本語をコンピュータで容易に扱えるようにするため様々な努力をしていた。先日日記で富士通のJEFの事を紹介したが、同様なことを日立、NECなどのメインフレーマも当然行っていた。
プログラミング言語(FORTRANやCOBOLなど)で日本語を簡単に扱えるようにするための独自拡張を各社行っていた。しかしプログラミング言語を独自拡張するとプログラムの可搬性が損なわれるのでそれを標準化しようという機運が80年代にはいってから盛り上がってきた。各社の実装は文字型のデータ型を日本語も扱えるように拡張するというものだった。具体的に言うと日本語文字型とでもいうべき別のデータ型を用意しそこに漢字などを格納するようにした。従来の文字型はアルファベット、数字、カナなど１バイトで表現するデータに利用し、漢字など２バイトを表現するために、いわば２バイト用のデータ型を別途用意するという仕様(というか実装)であった。FORTRANではCHARACTER型の２バイト用としてNCHARACTER型、COBOLではPICTURE句にX(アルファベット、数字)に対応する２バイト用としてN(漢字用)というものを用意した。Nというのは日本語のNあるいはNATIONALのNと言われていた。日本国内で各社の調整をしたのはJEIDA(社団法人日本電子工業振興協会)などの業界団体および情報処理学会のプログラミング言語の標準化を検討しているグループなどであった。当初は日本語処理ということで議論されていたが徐々にダブルバイトということで中国語などの漢字圏の処理に一般化できるし、さらにいうとダブルバイトだけでなく、マルチバイトという風により一般化できるというように議論がひろがっていった。(googleするとhttp://www.itscj.ipsj.or.jp/topics/hyojun.htmlという資料を発見)
当初はマルチバイトという用語を使っていたのだがバイトというのは必ずしも8ビットを意味しないのでマルチオクテットという用語をよく使うようになっていった。プログラミング言語におけるマルチオクテット処理機能の拡張についてなんて使い方である。
それはともかく。そのような中で国内での議論はアルファベット、数字などを表現する文字型とは別にマルチオクテットを表現するデータ型を別途用意するというのが主流の考えであった。実装はほとんどそのようなものであった。例外としてCommon Lispは一般化したstring型を持っていたので仕様上別データ型を持たなくても実装を拡張することができそうであった。
DEC社内ではVAX Calling Standardというのがあってそれが全てのプログラミング言語とOS(VMS)との呼び出し規約を定義していたのであったが、そこにテキストデータ型(DTYPE_T)とは別に２バイトテキストデータ型(DTYPE_T2)を新規に作ろうという機運が高まっていた。80年代中ごろの話である。当時ISO SC22/WG2というところでマルチバイト文字集合(後にマルチオクテット文字集合)の開発を行っていて、その文字集合を入れるのにこのDTYPE_T2というのはよろしかろうというような事である。後にこのマルチオクテット文字集合はいろいろな紆余曲折を経てISO 10646(Unicode)として知られるようになる。
さてDTYPE_T2なのであるがDTYPE_T型が利用できるところはすべて利用できるようにしたいというのが人情である。全てのシステムコールのなかでDTYPE_T型を引数とするものをDTYPE_T2も利用できるようにすると言う事は大雑把に言って２倍のシステムコールを実装しなければいけなくなる。これははっきり言って実装のコストが馬鹿高くなるので現実的な解とはお世辞にも賢い方法とは言えない。後にWindows NTは全てのシステムコールをUnicode化したので、ある意味80年代にDECがやりたかった事を実装したとも言えなくもない。
ということでDTYPE_T2を作ったはいいがOSやプログラミング言語の中では使われずになっていた。VAX日本語COBOLの実装ではPICTURE NをPICTURE X(2)として解釈をするという実装になっていた。COBOLの文法を知らない人向けの解説をすると「N」で漢字一文字を表現するのだけどそれをX(2)と解釈する。X(2)というのはアルファベットないし数字２文字をあらわす。すなわち漢字一文字はアルファベット数字２文字分であるということである。この実装では漢字は２バイトとなる。VAX Calling Standardは全く拡張しないで、 DTYPE_Tのデータとしてやりとりする。実装の容易性でそのような判断をした。
SQLの国際化の議論が行われていたのはまさにそのころ87年〜89年ごろからだったと思う。