小形克宏の「文字の海、ビットの舟」
|
|
●0213の規格化に反対するメーカー委員たち
のちにJIS X 0213:2000（以下、0213）となる原案の最終審議をおこなうために、'99年9月27日に開催された第83回情報部会は、まずは型どおりに原案作成を担当した芝野耕司委員長から趣旨と経過の説明がされた後、JIS化反対とテクニカル・レポート化[*1]を提案する日本アイ・ビー・エム（以下、日本IBM）斎藤輝委員代理の発言によって、その審議の幕を開けた。
では、最初の斎藤委員代理の発言を以下に引用しよう。なお〈 〉は引用者の注であり、【 】は工業技術院（以下、工技院）の了解のもとに引用者が読解のために補った言葉だ。また、議事録中の用語と、この原稿での用語が異なることがあるが（ShiftJISとシフトJIS、ISO2022とISO/IEC 2022等）、そのままとした。
北城委員（代理斎藤）
・本規格原案の規格化は、反対で、TR化〈テクニカル・レポート化〉を提案する。
原案に対する要望書は、部会〈メーカー〉委員の他に、電子協会員である東芝、沖電気、三菱電機も連名。
・我が国のパソコンは、年間1千万台の出荷があるが、大部分がWindows 95/98である。それらのOSが実装する文字コードは、メーカ拡張文字及び外字を含むWindows【に実装されている】ShiftJISであり、そのルーツは、MS/DOS〈MS-DOS〉、Windows 3.1に遡る。1997年改正のX0208[*2]でShiftJISを取り込んだ〈附属書としてJISの規定とした〉ことからもわかるとおり、この実装方法が広く日本で普及していると言える。
X0213においても、附属書1においてShiftJISが規定されており、言わば20年間に渡って、我が国の情報処理を支えてきたデファクト標準たるメーカ標準外字2600字を否定して、その領域に第3、第4水準の4,300字を配置した上で、一切、外字の追加を認めないと言うものである。
パソコン上では、Windows ShiftJISなのかX0213 ShiftJISなのかを区別する仕組みはないため、X0213が実装されれば、文字化けが広範に生じ、日本の情報産業にマイナスのインパクトを与えることは明らか。程度の差はあるものの、EUCも文字化けの問題は生じる。
一方、インタネットを中心とした今後の情報産業の中核的ソフトウェアは、Java、XMLであるが[*3]、その文字コードがユニコード[*4]に向かっていることは明らかであり、Windows 98、Windows NT、Windows 2000も、その方向であることもはっきりしている。
・メーカとしては、開発予算をユニコードの方にどんどんシフトしており、少なくともX0213と言うのは、メーカがシステム設計に関与するようなシステムでは使えない、あるいは使われない標準ではないか。にもかかわらず、特定のグループ、例えば日本文藝家協会、ペンクラブ、あるいはベンチャー企業が、JISだからと言うことで使ってくることがあって、その場合、文字化けに対するクレーム処理に費やすメーカの負のエネルギーというのは馬鹿にならない。
・今回のJISの調査で一番素晴らしいのは、4,300文字の第3、第4水準のうち、約90％が既にユニコードに存在していることが確認できたことである。したがって、残り10％を早く【実装が容易な第0面の】BMP[*5]に登録してもらって、【ISO/IEC 10646(Unicode)の翻訳JISである】X0221を改正して、これ一本で進むのが日本の道ではないかと言うことを考え、規格化には反対しているわけです。
・一旦、X0213をTR〈テクニカル・レポート〉にした後で、その後、ユニコードの文字等を見て、JISに格上げするのか、あるいは廃案するのかは、後でゆっくり考えたらどうか。
[*2]……1997年に改正されたJIS漢字コードJIS X 0208の第4次規格、JIS X 0208:1997をさす。改正時の原案作成委員会の委員長は、0213と同じく芝野耕司。
[*3]……いずれもデフォルトの文字コードとしてUnicodeを指定している。これ以外の文字コードを使用する場合は、なんらかの指定をしなければならない。
[*4]……この発言にあらわれる以外ではMacOSでも実装されている。すなわち一般的なパーソナルコンピューターでは支配的な文字コードがUnicodeだ。アメリカの主要コンピューター・メーカーを中心に結成されたUnicodeコンソーシアムによって制定されたデファクト標準だが、その内容は国際機関による公的標準（デジュール標準）であるISO/IEC 10646（通称"UCS"――Universal Multiple-Octet Coded Character Set）とほぼ同一。つまりISO/IEC 10646とUnicodeはまるで自転車の前輪と後輪のように、連携をとって規格化と拡張が進められている。情報部会のように公的標準を扱う場ではISO/IEC 10646かUCSと呼ばれるが、メーカーが実装する場合はUnicodeと称する場合が多い。この原稿ではISO/IEC 10646とUnicodeは同じとして、“ISO/IEC 10646(Unicode)”と表記する。
[*5]……Basic Multilingual Plane（基本多言語面）のこと。ISO/IEC 10646では、タテ256×ヨコ256の区点からなる“面”を256面あつめてひとつの“群”とし、全体を128群とする体系だ。256×256×256×128＝2,147,483,648文字を符号化するものだ。一方でUnicodeはタテ256×ヨコ256の区点からなる“面”を、第16面までの全17面分を規定することをきめている。このうち、最初の面、第0面を特にBMPと称する。現在のところ、ISO/IEC 10646もUnicodeも、第0面に収録する文字までしか規定していない。第1面以降はただ今拡張の審議中で、このうち漢字の拡張はExtension Bとして第2面に収録するべく、現在審議の最終段階をむかえつつある[訂正1]。
●テクニカル・レポート化をもとめるメーカー各社の“要望書”とは
この斎藤委員代理の発言の中でも注目されるのが、冒頭で言われた、部会のメーカー委員の他、日本電子工業振興協会（以下、電子協）の加盟3社が連署したという“要望書”だ。これについて、工技院で0213を担当する永井裕司技官はこう説明する。
「この要望書は、9月の情報部会のちょうど1カ月前、8月末に工技院に対して出されたものです。ですから工技院としては、この要望書は情報部会の提出資料ではなく、標準化政策の企画立案機関である工技院に対して、電子産業界がまとまって意思表示してきたものという解釈をしています。その内容は、日本IBMの斎藤さんが発言されたものとほぼ同じ、テクニカル・レポート化を求めるものです」
つまり、この要望書は情報部会のメーカー委員だけでなく他のコンピューター・メーカーからも、情報部会での0213JIS化最終審査を前にして、これに反対する先制パンチを仕掛けてきたと受け取れるものなのだ。
となれば、この要望書に連署した部会委員の会社名が知りたくなるのだが、これはまだ調査中だ。私の開示要求に対して工技院では、情報部会に対する提出資料ではなく、工技院への要望書であるという理由で公開を拒否した。また要望書をまとめたとされる日本電子工業振興協会へ問い合わせたところ、連署したメーカーの了解をとらないと公開できないとしたうえで、各社へ問い合わせることを約束してくれた。ちなみに、議事録からこの要望書に署名したとはっきり分かるのは、日本IBMと日本電気（以下、NEC）の2社だ。
●富士通が附属書1～3を参考にする提案をだす
斎藤委員代理の発言の後、富士通の成田委員代理、NTTの山田委員から0213原案への懐疑的な意見が出され、ついでNECの藤崎委員代理から日本IBMへの賛成意見が出される。そして再び富士通の成田委員代理が発言をもとめ、今度はのちに最終審議の結論となる提案を出す。
丸山委員（代理成田）
事務局〈工技院〉からの説明にもあったが、X0208を拡張する文字集合そのものとしては、ユーザの標準化のニーズが強いということもあるが、X0213の文字集合は、現時点でベストあるいはそれに近いと思う。X0213の規格化はふさわしい。
ただし、既存の資産との非互換のところがあるため、符号化表現に関する附属書1～3[*6]を規定から参考[*7]にするのが良いのではないか。
これをうけて、ISO/IEC 10646の審議に対する日本代表委員会の委員長をつとめる慶應義塾大学の石崎委員から、0213原案は現在国際提案中であることと、現在はUnicode(ISO/IEC 10646)へ主流がうつりつつある状況であることを理由として、実装関係の規格、つまり附属書1～3については柔軟な方針にする方がよいという意見がだされる。
これに対して電総研の藤村委員代理、富士ゼロックスの篠岡委員代理からUnicode(ISO/IEC 10646)収録に関連して質問と疑問が出される。
ここで棟上部会長が議事を整理する。文字集合に対する反対はないこと、そして問題点として従来のシステムとの互換性などがあげられること。
●文字化けが増える科学的理由がないとする芝野委員長
そして芝野委員長が反論に立つ。
・文字化けの件ですが、文字化けが問題になるのであれば、既にDOS〈MS-DOS〉からWindowsへの移行時点で、IBM、NEC、富士通等それぞれ各社がこれまで【移行以前から】ROMベースで提供したものが問題となっている。
例えば、NECの場合、ユーザ定義【外字】領域が、86、87区を使い、あるいは、9区から12区までに半角文字を提供してきたが、それがWindows【3.1から採用されたWindows標準キャラクタセット】ではなくなっている。ユーザ定義領域も変わっている。
もしも、互換性で問題があって、製造物として問題がある、〈メーカーの〉責任があると言うのであれば、そこで文字化けは既に起こっている。また、実際にはユーザ定義文字を交換できるのか、あるいは交換するとしても、きちんとした【典拠のある】文字集合があって、補助漢字〈JIS X 0212〉にもない地名の【0213の】漢字は4、5年先まで書けなくていいのか。住民基本台帳の交換において、もしも、現在、外字領域で漢字を作っているサイ〈「禾最」（面区点1-89-47）か〉東町は、その外字をユーザ定義領域で作る限り、個々に違っており、文字化けが起こっている。新JIS〈0213〉ができると【何が典拠のある正しい字か】リファレンスできるようになる。すなわち、新JISができることによって、文字化けが増えるという科学的理由はどこにもない。もしも、新JISが変換されることによって、従来と違った文字集合になることによって、問題が起きるのであれば、各社【文字集合を】1個にすれば良い。1個にできるのであれば、SC2の国際委員長[*8]として大賛成である。残念ながら、世界では、IBMはDOS/Vのコードページ935[*9]だけでなくて、漢字に関わるコードを新しく作っている。混乱を助長する形のことは、最近でも行われており、UCS〈=Unicode=ISO/IEC 10646〉、ラテン1〈英独仏語などのISO/IEC 8859-1〉があったとしても、コードページ850[*10]がまだ生きている現状にある。
UCSコードは、メジャーアプリケーションは、Java、XMLである。【しかし一方で】まだ、既存のコードでの開発が進んでいる。ShiftJISだけではなくて、例えば、電総研での多言語環境の研究とか早稲田大でも2022[*11]ベースの研究開発が続いている。
・UCSコードに将来統一してほしいというのが【SC2国際委員長である】私の願いではあるが、残念ながら、文字コードは長い間生き残る。JISでも、'97年のX0208改正において、【同時に改正された】JISX0201から4ビットコードをはずしたが、それまで4ビットコードは生きていた。50年生きるコードもある。もしも現時点で、全部UCSの方向であれば、開発を一本にして、ShiftJISやISO2022の開発関係は終わっているのであれば、5年先にはまったくなくなっている。今、【これらによる】開発をストップしなければならない。コードがShiftJISや2022によるコードページで書かれている限り、アプリケーション【や】、そこで蓄積されたデータは、最低五年ぐらい【残ると】見積もる【ことができる】。ゼロックスやIBMもワールドワイドに製品も出しているが、最近もそれぞれ各社が新しいコードページ対応も作っている。
・私は、現在、UTC〈Unicode技術委員会〉に対して、BMPに【0213の新しい文字を】入れてもらいたいと孤軍奮闘しているわけですが[*12]、その時に、各社からBMPへいれてもらいたいと言って頂ければ、非常にうれしいが、そういうことはなく、依然として、既存のコードでの開発が続いている現状にある。
[*8]……芝野委員長は情報技術関係の国際規格を審議するISO/IEC JTC 1（国際標準化機構と国際電気標準会議による第1合同委員会）傘下で、文字コードを管轄するSC 2（第2専門委員会）の委員長(Chairman)をつとめる。ISO/IEC 10646はこのSC 2の下にあるWG 2で審議される。
[*9]……コードページは、マイクロソフトとIBMが規定した、世界の文字コードを指定する際のコード番号。DOS/Vで使われるシフトJISはコードページ932であり、おそらくは芝野委員長の記憶違いと思われる( http://www.microsoft.com/GLOBALDEV/Reference/dbcs/932.htm http://msdn.microsoft.com/library/psdk/indexsrv/ixuwebqy_6e5v.htm などを参照)。ただしこの方法は現在のプログラミングでは使われなくなりつつある。
[*10]……コードページ850は、“MS-DOS Latin-1”を指示する。ラテン1とはISO/IEC 8859-1の別称であり、Windowsでのラテン1はコードページ1252であることから、おそらくは古いバージョンのラテン1が残っている現状を指摘したものだろうか。この部分については調査がしきれていない。後日を期したいと思う。
[*11]……ISO/IEC 2022のこと。現在JISにかぎらず、ISO/IEC JTC 1が管轄する文字コードの構造は、ISO/IEC 2022（翻訳JISはJIS X 0202）と、ISO/IEC 10646（翻訳JISはJIS X 0221）の2種類に大別される。このうちISO/IEC 2022は、複数の7ビット（2^7=128文字）、8ビット（2^8=256文字）の文字コードを切り替えて使用する拡張方法を定義する。インターネットのメールで使われるISO-2022-JPや、UNIXで使われる日本語EUCは、このバリエーションだ。また、規格としてのJIS X 0208も0213も、あるいは補助漢字と呼ばれるJIS X 0212、US-ASCIIの翻訳JISであるJIS X 0201も、すべてこのISO/IEC 2022(JIS X 0202)のもとで使われるように考えられている。ただし実体としては、これらの文字集合だけを抜き出してISO/IEC 10646(JIS X 0221)に収録して規格化し、これを各メーカーはUnicodeとして実装して使用するという、いわば複雑にねじれた状況にある。
[*12]……芝野委員長は'99年7月4日、UTC（Unicode技術委員会）副委員長アーノルド・ウィンクラーにあてて0213の新しい文字をUnicodeのBMPに収録するように求める電子メールを送った。これに対する回答は、UTC委員長リサ・ムーアによる'99年11月23日付けの手紙( http://www.cse.cuhk.edu.hk/~irg/irg/N690_Lisa_JIS.doc )によって出された。返答の内容は、一部を互換漢字として収録を仮受諾されたが、大半の文字はIRGへ審議差し戻しか、却下するとしたものだった。
この芝野委員長の発言と、本連載の第1部第4回（こちら）と第5回（こちら）を読み合わせると、そこで展開された意見と、この情報部会での発言はだいぶ重なる部分があることが分かるだろう。
●1回目の審査は水入り
だが、議事録では、かみあわない議論がつづく。
北城委員（斎藤代理）
・外字を勝手に使って文字化けを起こすことは使った人はわかっているわけで、相手も外字を使っていることがわかる。しかし、そこに第3、第4水準をぶつけてくると、そういこうとが【そういうことが？】わからなくなってしまう。
芝野原案作成委員長
・それは間違いである。今でも、誤入力はあるわけで間違ったデータはチェックできる。ですから、文字というものは、その文字が単独であって、文字表毎にあるわけではなく、コンテクストがある。文字入力をして、文字フォーマットをして、やる限りは、必ずチェックはある。その中で、文字というのはひとつの情報を作り出す単語とか文というの【という？】意味のある校正要素【構成要素？】であって、単独で文字があってそれで化けてわからなくなるわけではない。
実は、X0208の【97年】改正の際、Windows標準文字セットを採用しようとしたが、各社でそれぞれ別々にインプリメンテーションがあって、ROMがあったため、同じロジックで採用できなかった。
・５万字、10万字あれば、済むということではない。一個一個の字単位を考えずにとにかくコンピュータの【容】量があるからどんどん入れれば済むというのは間違っている。そういうことでなく、一文字どこで必要か、どういう役割で、これがあるとどこに使えるかということである。〈後略〉
ここで棟上部会長が芝野委員長にたずねる。
棟上部会長
・実装部分に関する附属書を参考にする点についてはどうか。
芝野原案作成委員長
・附属書1に規定するShiftJISは、もともと本体で規定する符号化方式〈ISO/IEC 2022〉とは異なる方式であることから参考とすることは基本的に問題ない。
ただし、附属書2及び3は、本体規定と同じ【バリエーションの】符号化方式である。こちらで参考とするということは、本体規定と矛盾してしまう。
以降、しばらく繰り返し文字化けを問題視する斎藤委員代理と、それに答える芝野委員長の間で、附属書2と3を規定にするべきか否かをめぐる論争がつづく。
やがて、棟上部会長が議論を引き取り、事務局である工技院に論点を整理するよう依頼し、引き続き1カ月後の部会で再審議することを宣言し、この日の部会は終了した。◎訂正1
私は第2部第7回、注5の中で、Extension Bについて以下のように書いた。
第1面以降はただ今Extension Bとして拡張の審議中（漢字は第2面に収録予定）で、現在審議の最終段階をむかえつつある。 この記述では、あたかも“Extension B”が、ISO/IEC 10646(Unicode)を拡張する原案のすべてのように読めてしまう。しかしExtension Bの正式名称が“CJK Unified Ideographs Extension B”（CJK統合漢字・拡張B”であることもからも分かるとおり、これは漢字だけの拡張集合だ。そこで以下のように訂正する。
第1面以降はただ今拡張の審議中で、このうち漢字の拡張はExtension Bとして第2面に収録するべく、現在審議の最終段階をむかえつつある。
以上は、読者の直井靖さんからの指摘だ。ありがとうございます。
(2000/7/19)
[Reported by 小形克宏]
INTERNET Watch編集部internet-watch-info@impress.co.jp Copyright (c) 2002 Impress Corporation All rights reserved.