小形克宏の「文字の海、ビットの舟」
|
|
●積み残していた問題の解決。まずは『追記』のまとめから
前回“リサの返信”は次に書きますといいましたが、今回も無理です。すいません。ふと振り返れば、僕はもう特別編だけを4回も続けているんですね。つまり本編を最後に書いたのは、はるか1カ月も前。「最近くだけた文体になってきましたね」ってメールをよくいただきますが、特別編と本編で文体を意識的に変えているんですよ。でもいっこうに本編を再開しないから、現状では変わったと思われてもしょうがないですよね。2回も休載しているしなぁ。
とまあ、よしない話はさておき、その本編の続きを書く前に、どうしてもすませておかないと前に進めない話がある。ひとつは“Windows OSでJIS X 0213（以下0213）を実装するのは簡単か”という問題、もうひとつは0213規格票での、いわゆる“カッコつきUCS符号位置”問題。これをはっきりさせないと、僕はたんなるマッチポンプになってしまう。前回の原稿末尾で追記を掲載しましたが、その続きでもあります。
さて、僕は第5回の『JCS委員長、芝野耕司の反論（後編）』の末尾、追記1（以下、追記と略）の中で、概略以下のようなことを書きました。
◆[1]Windows OSと0213の実装に関して
◎JCS芝野耕司委員長はインタビューに答えて“Windowsで0213をサポートするのは簡単である”とコメントした。[1-1]
◎芝野はみずからが聞いたこととして、マイクロソフトは「0213を実装する」と言っていたという話を紹介した。[1-2]
◎一方でマイクロソフトは私の問い合わせに答えて、“それは技術的な見地から間違っており、肯定できない”とコメントした。[1-3]
◎私自身は“技術的”には実装は容易だが、“政治的”な理由でマイクロソフトが0213を実装することはないだろうと考えている[1-4]。その理由は以下の通り。
・内部的にUnicode(ISO/IEC 10646)で動作しているOS、たとえばWindows NT/2000では、0213の文字とISO/IEC 10646の文字が一対一対応できるような変換表があれば実装できるはず。
・すでに0213の文字のうち、ほとんどはISO/IEC 10646に収録ずみ。問題は収録されていない文字の符号位置だが、これも手元の0213規格票案の附属書4（非漢字）と附属書6（漢字）の“UCS符号位置”欄をみると、未収録の文字はカッコでくくって、ISO/IEC 10646の未定義領域の符号位置をしめしてある。
・これによって、0213の文字とISO/IEC 10646の文字が一対一対応するので、“技術的”にはWindows NT/2000で実装が容易なはず。
・またWindows 95/98では内部的にシフトJISで動作しているので、0213の規格票“シフトJIS欄”の符号位置にマッピングしたフォントをインストールすればよいだけだ。だからこれも容易。
・しかし、これは非合法な符号位置であり、これをUnicodeコンソーシアムの正会員であるマイクロソフトが実装することはありえないだろう。ゆえにWindows NT/2000に、0213を実装されることはない。しかしこれは“技術”ではなく“政治”的な理由だ。
◆[2]“カッコつきUCS符号位置”について
◎前項でふれた“カッコつきUCS符号位置”にはおおいに疑問がある。そもそもJIS X 0208:1997（以下97JIS）で外字領域の原則使用禁止を打ち出したのは、ほかならぬJCS委員会自身ではないか。97JIS規格票では、〈過去の規格票の“解説”が、空き領域を利用することを誤って推奨していた〉とし、未定義領域は〈ISO登録簿〉では〈使用禁止（This position shall not be used）として登録している〉（以上、同解説より）と明確に位置づけている。この過去のJCS委員会の指摘は、実はそのまま0213を作成した現在のJCS委員会への指摘にもなりうる。[2-1]
◎しかし、この“今すぐに0213を使う”方法が、結果的に日本独自のUnicodeのバージョンを作ることにつながり、将来的に文字化けを引き起こす（かつての97JIS以前のJIS漢字コードのように）ことにはならないだろうか？[2-2]
◎だいたいが、マイクロソフトもけしからん。なぜならマイクロソフトはJCS委員会に委員を派遣している。同社のようなUnicodeに重心をおく企業が、なぜ非合法なUnicodeの拡張につながるカッコつきUCS符号位置を、委員会の論議のなかで阻止しなかったのだ。Unicodeコンソーシアム正会員企業の責任はどこにある。規格票案を見る限りでは、参考ではなく規定としてこのUCSの符号位置は盛り込まれているが、もし0213の規格票文末に、委員名がマイクロソフトの社名をあげて掲載されているならば、同社はこのUCSのカッコでくくられた符号位置に関して賛成したと見られても、おかしくはないのではないだろうか。[2-3]
●読者からの疑問
他に細かな問題もありますが、明らかにしなければならない問題点としては上記の通りであると思います。今こうして読むと、Windows 95/98に関する0213実装の判断が書かれていなくて、なんとも冷や汗ものです。
ここで話をすすめる前に、ちょっとUCS符号位置とは何かについて説明した方がいいかもしれません。UCSとはUniversal Multiple-Octet Coded Character Setの略。つまりISO/IEC 10646のことですが、0213規格票でいうUCSとは、ISO/IEC 10646の和訳JIS規格であるJIS X 0221（以下0221）を指します。ではこのふたつは、どう違うのか、という話はちょっと脇におきます。
さて、一般的に文字コードというのは、実際のコンピューターに実装された世界では、何回もさまざまなコードに変換されてデータとして流通していきます。たとえばOSの内部コードとしてUnicodeを採用しているWindows NT/2000やMacOSでも、国内のアプリケーションはシフトJISでデータの入出力をしている場合がほとんどです。インターネットにメールを出せばISO-2022JPという文字コードに変換される。また同じ文字コードでも符号化方法によって符号が変わる場合もある。たとえば先のUnicodeを内部コードとして使っているOSでは、16ビット単位の符号化方法を使っています。しかし一方で、インターネット・エクスプローラーなどのインターネット系アプリケーションでは、同じUnicodeでも8ビット単位の符号化方法を外部コード（OSや他のアプリケーションとの情報交換用の文字コード）採用しているんです。つまり、どこかのパソコンで入力された文字があなたのマシンに届くまで、あるいはそこまで話を大きくしないで、あなたのキーボードから入力した文字が、モニターやプリンターに出力されるまでには、知らないうちに何回も文字コードが変換されてデータは流れていくわけであります。
そこで重要になるのは、文字コード同士の関係。つまりある文字コードで定義された符号位置が、別の文字コードではどこに対応するのか、その対応表です。これをコンバージョン・テーブル、変換表という。たとえば0221では関連するJISの文字コード、JIS X 0201、0208、JIS X 0212（以下補助漢字）との対応表を附属書3（参考）として掲載しています。そして、この附属書3こそが、単にISO/IEC 10646を日本語に移し替えただけではない、JIS規格としての0221の価値を高めるものなのです。つまり、0221を日本語環境で実装したい技術者は、この0221附属書3の変換表を参照することで、安心して規格から逸脱しない実装をすることができる。
これと同様の理屈で、0213規格票でも、補助漢字、シフトJISなどとの対応表が掲載されている。UCS符号位置は、そのひとつでUCS=0221(ISO/IEC 10646=Unicode)と0213の対応表です。とはいっても、0213のすべての文字がUCS=0221(ISO/IEC 10646=Unicode)にふくまれているわけではないので、0213規格票では、そういった文字をカッコでくくって、0221の空き領域の符号位置を入れている。これがカッコつきUCS符号位置なのです。以上、説明でございました。
さて、話を戻して、この私の追記に対して、非常に的確な指摘をしてくださったのが、読者の松川一也さん。これは2月17日のメールです。以下引用しましょう。
|
その括弧つき符号位置が「未定義領域」なのは当然です。それらは、JCSがISO等に対し、UCSの「この符号位置にこれらの文字を追加して欲しい」と目下提案中の個所であり、もちろん、現段階ではUCS上のそれらの符号位置を*情報交換用として*用いることは、いかなる場合も禁止です。 そもそも未定義領域とは、「将来の規格改正の際の文字追加のために保留された領域」です。だからこそユーザやメーカが勝手にそれらの位置に文字を追加してはならないのであり、規格作成者が規格の改正としてそれらの位置に文字を追加するのは全く自由です。Unicode Consortiumが「BMPは既にフィックスされている」[*1]というのは、現時点におけるConsortiumの“意見”に過ぎません。むしろ、将来の規格改正でこれらの位置が埋まっていく可能性は充分にあると考えます。 芝野先生の要求は、あくまでも「Unicodeに依存することなくJIS X 0213を利用可能にすること」であると考えます。規格書上の「提案位置」は、現在こういう風にISO側に追加提案を行っているということをユーザに明らかにしたものに過ぎず、現実の実装とは何の関係もありません。まして、芝野先生自身「今すぐ“提案位置”通りにUnicodeシステムに実装せよ」と仰いましたか？ |
松川さんの指摘は、まことに理路整然としたものだと思います。しかし実はこの時原稿にまとめた'99年12月13日時点の芝野委員長への取材テープの中には、「“提案位置”通りにUnicodeシステムに実装せよ」と、私には明確に聞こえる談話が記録されていたんです。そこで、そのような内容の『追記の追記』を書き、芝野さんの談話を引用しているので、本人の確認をえるために、メールすることにしたわけであります。これが2月19日。
一方、マイクロソフトはこの件について、追記にも書いたとおり、原稿の公開前から、直接会って説明したいと言われていました。若干たがいのスケジュールのすりあわせがあった後、実際に僕が調布のマイクロソフトに行ったのが2月29日でした。
お会いいただいたのは加治佐俊一（ビジネス＆エンタープライズ開発統括部次席代表兼ビジネス＆エンタープライズ開発統括部長）、増井伸昭（ビジネス＆エンタープライズ開発統括部リリースマネージメントグループ マネジャー）、阿南康宏（ビジネス＆エンタープライズ開発統括部リリースマネージメントグループ）の諸氏。加治佐さんは開発のトップにたつ取締役ですし、増井さんは'98年の11月まで0213の原案作成を実際におこなったJCS委員会の下部機関WG2の委員、阿南さんは増井さんと交代でWG2の委員になった方です。つまり、マイクロソフトで0213について聞くなら、この3人以上はないだろうという顔ぶれになる。うれしいことです。
さて、ここで僕がマイクロソフト開発陣から聞いた話は、僕を打ちのめさせるのに十分な内容でした。スペースがないので失礼ながら箇条書きにまとめます。また、すでに特別編2の原稿『ISO/IEC 10646で却下された(?)JIS X 0213の新漢字一覧表』の冒頭において、簡単に0213にたいするマイクロソフトの姿勢をご紹介しているけれど、以下はこれを補足するものでもあります。
●マイクロソフトが考えること
◎芝野氏が追記のなかでふれた『IPAKielSeven』はLinguist's Software社のフォントであり、マイクロソフト社のOffice2000シリーズに添付された事実はない。
◎“カッコつきUCS符号位置”はそもそも0213規格票に“参考”であると明記されており非合法（イリーガル）とは言えない。空白にしておくというオプションもあったかもしれないが、規格原案作成当時UCSにない文字についてのJCSの対応についての関心も高く、ユーザーにとっては、単なる空白よりもカッコでくくった位置に提案中だと明示したほうが、より親切だといえるのではないか。
◎ただしこれは“規定”ではなく、“参考”だ。そしてこれは実装を意図したものではない。というよりも、このカッコの位置を使って、誰かが実装するとは、おそらくJCS委員会にかかわっている人間は誰も思わないだろう。0213は国際規格との整合性をもできうる限り考慮した規格だが、規格単体としては〈新JIS漢字は、 7ビット又は8ビットの2バイト符号化文字集合であり、 10646/X0221/Unicodeのような 16ビット又は32ビットの符号化文字集合とは、別の体系〉（JCSサイトのFAQのページ項番2： http://jcs.aa.tufs.ac.jp/jcs/progress/njis-faq.htm ）だからだ。だからこの部分(2-1、2-4)はマイクロソフトにとっても、JCS委員会にとっても間違った指摘になる。
◎仮に芝野委員長がこの“カッコつきUCS符号位置”で実装してもよいと言ったか、ないしはほのめかしたのだとしたら、それは驚きだ。なぜなら、まさにこの追記で書かれたとおり、JCS委員会は97JISを作った委員会であり、97JISはでそれまで自由領域だった部分を原則利用禁止にしたからだ。おそらくは別の文脈でそういう話が出てきたのだろう、読んでいてそう思った。
◎Windows NT/2000への0213の実装問題だが、0213がUnicodeと完全に対応しない限り、実装は不可能だ。0213が完全にUnicodeに収録されていない以上、現在では実装はできない。
◎1年半ほど前、芝野氏と話をしたとき(1-2)も、Windows 2000の話をしていたのではない、この時はマーケット・リクワイメント（市場の要求）の話をしたので、Windows 2000とは関連がない。マイクロソフトも0213の文字集合を、将来実装していかなければならないね、という話をした。このことじたいは、今も方針に変更はない。
◎マイクロソフトがサポートしている符号化文字集合は、『Windows標準キャラクタセット』だが、制定した時点からこれは拡張しないという前提でつくられた。後継の符号化文字集合はUnicodeだけと、はっきりその時点から決まっていた。
◎だから0213も、文字集合としてはむしろ積極的にサポートするが、符号化方法としてはUnicode以外はありえない。
◎もしもWindows 95/98への実装という意味ならば、たしかにそれは技術的には可能だ。フォントをシフトJISベースで作り、インストールすればよい。
◎しかし変換表をつかってもUnicodeへの変換は、0213とUnicodeが対応していない以上、いろいろと矛盾は出る。また既存のアプリケーションや外字が使えなくなる場合もあるだろう。もちろん、これは弊社として保証の限りではない。
◎シフトJIS環境で0213を動作させた場合に考えられる問題点として、これはOS内部の処理の話だが、たとえば第1バイトと第2バイトに分かれるシフトJISのデータを、両方とも見ないかわりに特定の組み合わせを監視することで結果的に高速にデータをスキャンできるアルゴリズムが存在する。もしこういうアルゴリズムでデータを処理するときに、シフトJIS(Shift_JISX0213)で符号化された0213のデータがくれば誤動作するだろう。具体的に例示すれば、これはGDIとよばれる描画ルーチンにも使われている。もちろんアプリケーションでも、このアルゴリズムを使っているかもしれない。
◎また、シフトJISの空き領域を、何かうまく使い込んでいるアプリケーションがあるかもしれない。これらはもうテストするしかないことで、我々としても分からない。
◎仮に0213に対応したフォントをWindows 95/98にインストールしたとすれば……どうなるか、我々はテストする立場にないので分からないというのが正直なところだ。
◎0213は現代日本語表記に必要とされる符号化文字集合として開発された。日本で必要とされている文字集合をマイクロソフトができるだけ早く実装しようとするのは当たり前の話だ。
◎マイクロソフトはUnicodeコンソーシアムの中でも、0213の文字集合をできるだけ早く規格化するよう呼びかけている。もちろんわれわれが提案したからといって、自動的に収録されるわけではないが。
◎0208を拡張する文字集合としては、'90年に作られた補助漢字があげられる。これをマイクロソフトがサポートしたのは、'98年のWindows 98だった。そしてWindows NTではServicePack4で同年12月にサポートした。つまり、補助漢字にかんしては大きなタイムラグがあった。これは補助漢字そのものが本当に必要なものなのだろうかという疑問があったからだ。そうこうしているうちに、UNIXのメーカーで補助漢字の実装がすすみ、それに追従したという事情もある。
◎そういうメーカー間の事情はさておき、われわれの基本的な立場は、文字が足りないという要望に対して今ある標準(JIS)で実装するとしたら、まずは0221（つまりUnicode=ISO/IEC 10646）でサポートするべきだというものだ。そこで0221にふくまれるものとして補助漢字を実装した。
◎たしかに今度規格化されたISO/IEC 10646(Unicode)のExtension Aにも、百六十数文字の0213はふくまれている。しかし、たとえば第3水準漢字だけという部分実装ならともかく、Extension Aだけの0213部分実装では、日本文字レパートリーとしてのまとまりがクリアではない。Extension Aの意味のある日本文字集合を定義する日本の規格はないわけで、これだけを取り出して実装する裏付けはない。だからきちんと全部揃って0213の文字がUnicodeに入ったときに、0213の文字集合をひとまとまりとして実装するのが一番クリアだと考えている。だから、どうしても数年先になってしまうだろう。
◎ただし、マイクロソフトがExtension Aを部分的にアプリケーションとしてサポートすることはありうるかもしれないし、サードパーティーがサポートしたいと言うかもしれない。それは技術的には十分に可能だ。しかし、これをOSとしてサポートするかどうかは、また違う話だ。
◎ある文字集合をOSで段階的にサポートしてゆけば、結果的にいろいろなバージョンが市場に混在することになり混乱をまねいてしまう。われわれはそれはすべきではないと考えている。これで、僕の指摘に対するマイクロソフトの考えも、そして同社の0213にたいする姿勢もクリアになったのではないでしょうか。つまり、先にあげた指摘のうち、同社に関するものについて、はっきりさせると、
・[1-1]に関しては、どうやらマイクロソフトは無関係。
・[1-2]に関してはその通り。
・[1-3]はこのコメントで彼らの言う“技術的見地”の内容がはっきりしたでしょう。
・[1-4]についてですが、これは後述させてください。
・[2-1]についてですが、カッコつきUCS符号位置が規定でなく参考である以上、JCS委員会を批判するべき筋合いのものではありません。ここに取り下げて、JCS委員会にお詫びいたします。
・[2-2]、[2-3]についても、後述させてください。
つまり0213のWindows OS実装問題については、まずWindows 95/98では確かに可能。しかしそれは不安定な、どういう問題がおこるか分からないもので、実用品としてはお勧めできない。これを“容易に”と表現してはいけないでしょう。あくまでも“可能”というレベルにとどまる。
つぎに、Windows NT/2000について。これは例の“カッコつきUCS符号位置”の評価ともかかわりますので、[1-4]と[2-2]、[2-3]と一緒に後述します。ただし、この部分でカッコつきUCS符号位置を“非合法”と表現しましたが、誤解のないように説明すると、これはあくまでUnicode(ISO/IEC 10646)からみれば“非合法”という意味です。カッコつきUCS符号位置が0213の規格票に掲載されている以上は、0213から見た場合、けっして“非合法”ではありません。
そんなわけで、一部をひとまずのぞいて、僕の原稿は誤りをふくんでいました。ここに訂正し、お詫びするものです。申し訳ありませんでした。
●芝野耕司委員長の考え
さて、なぜ僕は[1-4]と[2-2]、[2-3]をひとまず脇によけたか。それは前項であげた部分以外の指摘と関係します。これらについては、芝野委員長にも話を聞いて判断しないと、どうにも分からないことがあるからです。人間、簡単に頭を下げては言うことに重みがなくなる。いや、結果的に僕はよく謝っちゃっているんですけどね、それはあくまで結果です。
一方で芝野さんからの返事はなかなかきません。あとで聞くと悪い風邪をこじらせてしまい、この頃から数カ月も僕への返事をふくめ何もできない状態がつづいていたそうです。それをおして芝野さんが電話で話してくれたのが3月6日。本当に申し訳ないことです。以下はその電話での取材の内容です。これまたスペースの関係上、要点を箇条書きにします。
◎『IPAKielSeven』はどうやら私の勘違い。ただ、Dingbatsとか、マイクロソフトから入っているフォントでも、全然関係ないやり方をするものがある。
◎[2-1]について。これにはふたつの点で問題がある。まず、ISO/IEC 10646の符号と国際登録簿とは全く異なる符号体系に属し、全くの別物だ。
また、JISでは'78年、'83年、'90年と文字の追加を行なっているが、97JISの解説は規格が拡張することに対する否定ではなく，規格外での空き領域の利用の禁止だ。また0213は、国際登録簿上では0208とは異なるものとして登録している。
このような理由で97JISの解説と国際登録簿での記述をたてに、0213の間違いを指摘するのは無理がある。
◎対応が容易かどうか、Unicodeに入るか否かは、技術的な問題とは別次元のもの。単純な技術の話と、技術政策、国際規格との整合性とは別の問題だ。国際規格を優先させるのか、国内規格で実装するかはメーカーのポリシーの問題だろう。規格に合わない実装は今でも大量におこなわれている。たとえば外字が使えるというのは、つまり規格（0208）には合っていないということだ。つまり、これは何をどう優先させるかという議論だろう。
◎現時点で0213でISO/IEC 10646に収録されていない文字があるのは当然だ。こういう時、規格を作るときのオプションとしては三つ選択肢がある。
(1)空白にしておく
(2)暫定位置に入れておく
(3)外字領域に割り振っておく
◎(1)の場合、空白にしておいて、ユーザーがバラバラなところに割り当ててしまうと、正式にISO/IEC 10646に収録された後、将来の移行措置がとても大変になる。もっとも決められた外字エリアを使うならば、それはそれでISO/IEC 10646に適合する。しかし各自バラバラに外字を使った場合、この部分に限れば情報交換はできなくなる。
◎また(3)の場合、規格が外字領域を使うのはおかしい。
◎そこで(2)の場合だが、文字コード規格への適合を内部処理と外部との情報交換とにきちんと分けて議論する必要がある。たとえばWindows NTのTrueTypeフォントによって0213の文字を使いたいという時などは内部処理だ。これは暫定的にでも、なんらかの符号位置がないと不可能だ。
◎ちなみに、内部処理に独自コードを用いても、情報交換用としては規格に合ったものを出して、適合性を主張することは完全に認められている。
◎ただし、0213規格本文、ISO-2022-JP3などの符号化方法を用いる情報交換は推奨している。しかしISO/IEC 10646としての情報交換は、ISO/IEC 10646に適合する形では、このカッコつきUCS符号位置は使えない。
◎この(2)の場合は、この符号位置は規格の一部ではなく参考だと書かざるをえない。実際0213規格票には、そのように明記してあるし、明確に分かるようにカッコつきにもしてある。
◎自分の意図としては、この松川さんの言っているものの方が近いと思う。あくまでも暫定位置として使っていて、明らかに現時点では、ISO/IEC 10646には適合しない。適合してないものを、適合していると言って情報交換に出すのは、私の意図ではない。
◎これはあくまでも暫定的、というより提案中のコードポジション。提案位置であって、規格の最終的な位置ではない。
●W3C――海外からの視点
じょじょにはっきりしてきたと思います。ちょっと交通整理をしましょう。あ、その前に[1-1]についてだけ書きます。これは芝野委員長が、「これがそうだ」という具体的なフォント名を出してくれるまで、現時点では僕としては何とも言えません。というわけですので、それを待つことにいたしましょう。
さて、まず[1-4]、つまりWindows OSに0213を実装するのは容易かどうかについて。マイクロソフトと芝野委員長のコメントを読み合わせると、この問題が明確になってきます。Windows OSのうちWindows 95/98への実装は、可能ではあっても問題含みであり、僕の原稿の間違いであったことは前述したとおり。
ではもうひとつのWindows NT/2000ではどうか。もしもカッコつきUCS符号位置を盛り込んだうえで変換表とフォントをインストールすれば可能です。その意味では技術的に容易と言ってもよいと僕は考えます。しかし、このカッコつきは、あくまでも暫定的なものでしかない。したがって原案作成委員会の芝野委員長も、これを推奨する意図はないということです。前述したとおり、僕の取材テープにはこの暫定的な位置での実装をすすめるようにうけとれるコメントがありましたが、これは当の発言者が否定しているのだから、なにか言葉が足りなかったのだと思われます。たぶん内部処理に限定して、という意図で言われたのでしょう。
同時に、このカッコつきUCS符号位置が暫定である以上、マイクロソフトがこれをつかって実装するはずはありません。0213の原案作成に社員を派遣した同社なら当然ですし、またこういう暫定的なUnicode(ISO/IEC 10646)の実装を、Unicodeコンソーシアムの有力メンバーたる同社がするはずがありません。ただし、このことと“技術的に容易”かどうかは、僕が追記で書き、また芝野委員長も指摘するとおり、まったくの別問題で切り分けて考える必要があります。
さて、上記のことをはっきりさせたうえで、考えなければならないのは、再三ここまで問題にしてきたカッコつきUCS符号位置を、僕たちはどのように評価したらよいか、ということです。これを考えることが、ここまで積み残してきた[2-2]日本独自のUnicodeをつくる危険性、[2-3]マイクロソフトへの疑問、この2項目が間違いだったかどうかを検証することにもつながります。
ここで登場していただくのはマーティン・Ｊ・テュールストさんという、在日のドイツ語系スイス人。スイスのチューリッヒ大学で修士をとったあと、東京大学で理学博士の学位を取得。現在はXMLやHTMLなどのインターネット上のさまざまな標準を研究開発するWorld Wide Web Consortium（以下W3C）の国際化活動担当者として、慶應義塾大学湘南藤沢キャンパス内に駐在しています。W3Cは世界中のいくつかの拠点をもつ国際組織。つまり日本に住むマーティンさんには、まず国際的な視点を期待できるし、また日本で活動をしているので、国内事情を踏まえた話も聞けるわけであります。彼はもっと他にいろんな話をしてくれたのですが、それは後のお楽しみにとっておき、ここでは特にこのカッコつきUCS符号位置問題にしぼって談話を採録しましょう。なお、マーティンさんは日本語が堪能な人で、インタビューも日本語だけでおこなわれました。
マーティン：XMLがUnicodeをベースにしている関係上、W3Cもたいへん心配しているんです。実際の規格票をまだみていないので確かには言えませんが[*2]、UnicodeでもISOでもまだ審議がはじまったばかりなのに、提案中としてなにかの番号 （符号位置）が入っているんですね。一応カッコでくくってはありますが、それでもまだ正式なものになっていない審議中の文字です。どこかのユーザ ーがこれをみて使っちゃうと、大変なことになります。だから、そういうものを規格票に入れるのは大変危ないです。 国の規格がこういうことをすると、例えばどういうことが起こるかというと、他の国でも日本とまったく同じ場所にUnicodeの番号を決めてしまうようなことが起こるかもしれませんね。そうなると大混乱がおきます。それは絶対にダメですよね。
審議中の文字を早く使えるようになるのはいいとは思いますけど、やはりちゃんとUnicodeやISOの審議をへて、決まった時点で使うべきだと思います。ですからこのカッコ内の番号は空白のほうがよかったんじゃないかと思います。Unicodeなどへの提案書の中だったら、番号をふってもまったく問題はないです。でも、0213は何百部、何千部と出回る標準になると思いますので、そこに提案中の番号をそのまま入れるのは、やはり誤解の可能性があるんじゃないかと思います。
小形 ：規格本文ではこれは参考であって、規定ではないと明確に言っています。
マーティン：それは分かりますけど、それでも規格をきちんと全部読まないという人は当然いますので、その辺が心配ですね。
[*2]……取材は0213規格票が発売になった当日の3月8日、湘南藤沢キャンパスでおこなわれ、まだこの時点でマーティンさんは規格票を入手していませんでした。
つまり、マーティンさんはこのカッコつきUCS符号位置が誤って使われる危険性だけでなく、他の国も同様に暫定的な符号位置を規格票に載せ、結果的にそれらが衝突してしまう危険性をも指摘しているんですね。
このようにカッコつきUCS符号位置の危険性を憂慮しているのは、マーティンさんだけではないようです。3月18、19日に大阪でおこなわれた『XML開発者の日』というイベントに僕も参加して聴講してきました。この中の『企業のグローバライゼーションとディアスポラ的情報技術者 ユニコードの現場報告』というセッションで、Unicodeの制定にはUTC（Unicode Technical Committee―Unicode技術委員会）メンバーとして、一方、ISO/IEC 10646の制定にはIRG(Ideographic Rapporteur Group)[*3]メンバーとしてかかわっている小林龍生（日本代表）さんと、サンマイクロシステムズの樋浦秀樹（アメリカ代表）さんも、講演のなかでこの問題に関して同様の懸念を表明していました。それにこたえて前述のマーティンさんが会場から特に発言をもとめて、「括弧内の番号は空白と考えて、塗りつぶしてもよい、無視した方がよいです。今の時点でこれを使うと、絶対混乱の元になります」と言っていました。
これらの3人とも国内規格より、国際規格により軸足をおく立場の人々ですから、その意味で、この3人の意見はさまざまな立場の一面を代弁しているにすぎないかもしれません。それでも、Unicode(ISO/IEC 10646)側の視点から見ると、この0213のカッコつきUCS符号位置は、きわめて“迷惑”なものに映るのは確かなようです。
●やはりカッコつきで暫定符号位置を載せるのはまずい
結論にいきましょう。まず僕はカッコつきUCS符号位置が、結果的に日本独自のUnicodeのバージョンを作ることを心配します。これはマイクロソフト、芝野委員長の取材をへた後、さんざん考えましたが、やはり追記の中で[2-2]として書いたものから考えは変わりませんでした。
たしかにマイクロソフトが指摘したとおり、このカッコつきUCS符号位置は参考であって規定ではありません。しかしだからといって“カッコでくくって提案中であることを明示した”という説明はわかりません。提案中であることを明示するなら他の方法があるはずだからです。暫定的なものだからこそ、誤用をさけるために符号位置を出すのは避けるべきではなかったのではなかったか。むしろ、そっちのほうが“親切”ではなかろうかと、僕は思います。
芝野委員長の論点は明解です。こういう場合、規格票がとるべき3つの選択肢をしめしたうえで、その得失を論じ、結果としてカッコでくくった暫定符号位置を規格票に盛り込んだ。しかし僕には、こと得失という意味では、暫定ポジションを入れておこる混乱の可能性を回避することのほうが、他のメリットよりも優先するように思うのです。“規格票が混乱をおこす原因になってはいけない”。僕の考えはここに帰着します。
さて、同時に芝野委員長は規格への適合を論じる場合、用途を情報交換と内部処理に分けて考える必要があることを指摘しています。内部処理については独自の文字コードを使ったってかまわない。しかし、例えばそうして使ったカッコつきUCS符号位置をふくむUCSのデータを、そのまま情報交換のために外に出すと、0221と適合しなくなる（ただしISO-2022-JP3等に変換すればOK）。なるほど、たぶんこれは規格として考えれば正論なのでしょう。しかし、僕はこうも思うのです。実際のシステムで考えた場合、はたしてひとつのシステムの中で、文字コードを情報交換用と内部処理用に、きちんと分けることは可能なのでしょうか？
たとえばWindows 2000で0213を使うのは、芝野委員長の言うように、Unicodeと0213の変換表、つまりカッコつきUCS符号位置をつかった変換表と、0213に対応したフォントをインストールすればいい。しかしこの場合、内部処理と情報交換の差は本当に紙一重です。なぜならこの方法で0213に対応させるということは、たとえ内部コードだけに限定して使うつもりであっても、アプリケーションが書き出す文字コードをも制限することは事実上無理なわけですから、それが情報交換に用いられてしまう危険があるからです。OSにカッコつきUCS符号位置をふくむ変換表をインストールするということは、意図がどうであれ内部処理以外の局面でカッコつきUCS符号位置が使われうることを意味するわけです。
そういう実装上のことはさておき、規格のうえからは情報交換と内部処理を分けて考える、そういうことなのでしょうか。しかし……。
なるほど、このカッコつきUCS符号位置の用途が、暫定的で内部処理用の限られた意図だということは分かりました。今すぐに0213を使いたいユーザーの要求に、規格としてこたえようというのも、きわめて真っ当な姿勢でしょう。
しかしそれならば、解説などで意図を詳しく説明して、誤用を防ぐべきだったのではないでしょうか。前出のカッコつきUCS符号位置に疑問をもっている人々は、みんなこの誤用を心配しているということなのでしょう。もっと規格は誤用されないように配慮してもよかったのではなかったか。僕はそんなふうに思います。
ところが規格票そのものは、これについてきわめて寡黙です。規定でなく参考であること、カッコつきは0221にふくまれない文字を意味するということの他は、提案中の暫定的な符号位置であることも、内部処理に限定したものであることも、ましてや誤用せぬよう警鐘をならすようなことも書いていないのです。
話をもどします。僕は[2-3]としてマイクロソフトに対して批判を投げかけました。これはカッコつきUCS符号位置が“規定”であるという前提のもとでの批判でしたので、これについては取り下げ、ここに同社に対してお詫びしたいと思います。しかし、やはりこのカッコつきUCS符号位置が混乱の元になること、そして同社がUnicodeコンソーシアムとして、Unicodeに対する誤解・誤用をなるべく回避させるべき立場であることを思うとき、責任がまったくなかったかというと、疑問をもたざるをえないのです。先の追記の中ではかなり厳しい調子で書きました。しかしカッコつきUCS符号位置があくまでも“参考”であることを考えると、同じ調子で批判するつもりはありません。しかし、責任がないかというと疑問がある、もっとうまいやり方があったのでないか、こういう言い方になるでしょうか。
[Reported by 小形克宏]