小形克宏の「文字の海、ビットの舟」
|
|
●現在のWindowsで、2000JISに対応するのは簡単だ。
国内のメーカーは当事者能力をうしなっている。芝野のするどい告発に気押されしながら、私は聞いてみた。
「当事者じゃないということは、自分で汗をかかないということですか？」
迎合気味の、すこし機嫌をうかがうような私の質問に、すぐに芝野は答える。
「そう。だから、ユーザー・サイドであっても、デペロッパー・サイドであっても、両方とも自分では関係ないと。NECにしても日本IBMにしても、なんか話が終わるたびにマイクロソフトさんはどうですかという話になる。そんなのおかしいでしょう？」
芝野はマイクロソフト日本法人の開発統括責任者の名前をあげて言った。
「――さんなんかは、最初は2000JISの実装なんか絶対嫌だと言ってたんだけど、2000JISの開発がすすむにつれて、市場の要求があるのはハッキリしたねと、たしかにマーケットがある。それだったら、コンバージョン（変換）のひとつとして……今だってWindowsの中ではシフトJISもコンバージョンのひとつですからね。ISO-2022JPなんかと同じように、そのひとつとして開発しますよと、もう１年半くらい前から言っているわけ。あとは、だからWindows 2000のタイミングにあうのか、今のタイミングだったらWindows 2000は来年（2000年）の2月くらいに出荷しなけりゃいかんから、じゃあその次ねってだけの話で。
今度の2000JISが誰も使わなかったら、それはそれでいいんじゃないですか。マーケットのリクワイアメント（要求）がないわけでしょう？ それだけです。リクワイアメントがあるかないかというのは、中身をみて判断してもらう必要がある。マイクロソフトがやらなければ、ラッキーっていって自分たちでLinuxなりなんなりで実装させればいいんだから。そもそも、すでにいろんな人がフリー・フォントを作ろうという話だってあるわけですよ[*1]」
[*1]……とりあえず現時点で入手可能な2000JISのフリーフォントには、以下のURLで入手可能なものがある( http://www.vector.co.jp/authors/VA018031/font/ )。説明によれば〈Microsoft Windows用TrueType書体〉とのこと。Windows 2000やofficeなど、Unicodeで動作するプログラム上で使用できるかどうかは不明。
このページ、トップページ（ http://www.vector.co.jp/authors/VA018031/ ）にタイトルがないので呼ぶのに困るのだが、とりあえずここではコンテンツの一部をとって『文字コードのばなな』としておくが、事実にもとづいた2000JISの論考、資料が充実しており、関心のある向きにはおすすめである。
Windowsに2000JISを実装するのは難しいことではない。これは私にとっては、大変気になるコメントだった。取材後、あらためてマイクロソフト広報部に問い合わせたところ、第2回冒頭でひいたコメントを繰り返されただけだった。また芝野のいう開発統括責任者が本当にこういうことを言ったかどうかについては、コメントがえられなかった（記事末尾の『追記1』参照）。しかしマイクロソフトの姿勢には微塵もぶれはない。つまりUnicodeにない2000JISの文字については、これを収録するUnicodeのバージョンが制定されるのをまって、これに対応する形でサポートする、ということだ。
しかし、それは取材後の話だ。私はびっくりして聞いた。
「それは具体的には、Windowsのどの部分を修整すればいいという話ですか？ フォントを追加すればいいということですか？」
分かってないな、とでも言いたげに、顔をしかめて芝野は答えた。
「簡単じゃないですか、フォントとコンバージョン・テープル（変換表）のふたつがあればいいだけですよ。中はUnicodeで動いていて、外部で動いているコードと違うんだから、その間にコンバージョン・テーブルがあればいいし、それを表示するには対応するフォントがあればいい。Windowsにかぎらず今はどんなOSだってそういう仕組みで動いている。そのふたつを入れたら、それで動くようになるんですよ」
そうか、そうなのだ。まるで精緻なジグソーパズルのようにさまざまな、それじたいで完結した“部品”で構成されている先端OSならば、心臓部はいざしらず、外部であつかう文字コードくらい、まるでパズルのピースを入れ替えるようにして交換可能なのだ。
芝野の話を聞きながら、私は懸命に頭を回転させていた。ということは……。
「あとの問題は、マイクロソフトがそれをいつ入れるかということだけですね」
なにを当たり前なことを、というかんじで応じる。
「いろんな符号化方法がOSの上で動いているわけでしょう？ ローカライズによってデフォルト（初期値）の文字コードがどれになっているかというだけなんだから」
●Unicodeをより良くするためにも、2000JISを日本で使えるようにしないと。
あの本はお見せしませんでしたっけ。あれを見れば一発で分かるんだ。どこにしまったっけ……といいながら、芝野は研究室の書棚から厚さ1センチくらいの本を探してきて、私に見せてくれた。それはEUのためにスウェーデンで発行された、EU加盟各国の文字コードの間で、そしてアメリカ英語の文字コードとの間で、どの文字が化けるかという一覧表を集めた本だった。その本を、みずからページを繰って説明する。
「これがヨーロッパ、EUの混乱です。ヨーロッパで文字コードがどれだけ出ているか。ISO/IEC 646IRVから、Latin-1、Latin-greekだとかいっぱいありますねと。このへんはcode pageで、Macintosh……。どの文字コードからどの文字コードに変換されると、どの符号位置に問題がおきるか。だからたとえばISO/IEC 646IRVというのがありますと。それがスウェーデンの7ビットコードにいくと、こんなところに問題がおきますと。Latin-1とLatin-2でどうなるかだとか……[*2]。ヨーロッパはこういう問題を抱えているわけですよ。濃いシャドーのところはどうしようもなく文字化けがおこってしまう変換不可能な位置、薄いシャドーは変換可能な位置。日本以外にも、こんなにたくさん文字コードがあるわけ。たとえUnicodeになろうと、これらが全部、文字化けなしに動かないと困るでしょう？ 簡単な話だと思いますか？」
それに、と芝野はつづける。
「今のUnicodeのフルの実装はとっても大変なんです。なにもUTF-16の16面まで問題にしなくて、BMPだけでも大変なのは、まずは8ビットでなく16ビットの符号がフルにくること。システムに負担をかけますね。
それともうひとつは、それぞれのランゲージ（言語）に対応したコンポジション・メソッドをちゃんと入れられるかどうか。Unicode、ISO/IEC 10646は実装水準が3つありまして[*3]、実装水準1というのは、コンポジションをしない。水準2はどうしても必要なコンポジションをする。水準3はオプショナル（選択的）なコンポジションをすると。例えば、ラテンは両方で、プリコンポーズ（あらかじめ合成した文字）もあればコンポジションもある、だからこれは水準3なわけですよ。例えばヒンディーだとか、タイだとか、これはコンポジションなければ動かないわけですから」
たとえば、ヨーロッパのラテン文字には、さまざまな種類の発音記号（ダイアクリティカル・マーク）をつける場合がある。Unicode（ISO/IEC 10646）には、あらかじめ発音記号を合成した（これをプリコンポーズという）ラテン文字も収録してあるが、発音記号だけも収録してあり、これを組み合わせて使うことも可能だ。この組み合わせる仕組みが“コンポジション・メソッド”とよばれるものだ。
たとえば、フランス語の発音記号“グラーヴ”[*訂正4]（文字の上に小さな右下向きのチョンをつける）をつけたアルファベット小文字“ａ”を、Unicodeであらわそうとした場合、符号位置U+00E0にあらわされる“グラーヴ”つきラテン小文字“ａ”を使ってもいいし、U+0061の“ａ”につづけてU+0340の合成用グラーヴ単体を使ってもよい（"U+"はUnicodeの符号位置であることをあらわす。符号位置そのものは当然ISO/IEC 10646とまったく同じ）。
コンポジション・メソッドが必要なのはヨーロッパのラテン文字だけではなく、タイ、キリル、アラビア、ベンガル、タミル、ラオなどなど多くの文字にわたる。
つまり、1つの文字が1つの符号位置をあらわすという我々日本語ネイティブの（そしてアメリカ英語の）常識は、たんなる幻想にすぎないのだ。
また、ヘブライ、エチオピアなどのセム語族に属する文字の多くは、英語などと反対に右から左に向かって流れる。ところが、これらのなかに外来語である英語の文字列が入ると、そこだけは通常の英語と同じく左から右へ流れる。つまり、これらの文字では、流れる向きが右と左の双方向ということになる。ということは、流れる方向を指示するなんらかの仕組みが文字コードの中に必要となる。これもコンポジション・メソッドの一例だ。
「そこらへんのアルゴリズムというのが、ちゃんと動くのかどうかっていうのは、ある意味ではまだプルーブ（証明）されていないんですよ。机上ではやってますね。Unicodeコンソーシアムでグレン・アダムスとかあのへんが真面目に考えている。でもマーケット・プルーブではないわけですよね。まだまだ、まずいろんな言語のコンポジション・メソッドをいっぱい入れないと、Unicodeのフルセットとして、ちゃんとしたものは動かない」
つまり、と私は聞いた。
「まだUnicodeは未完成ということですか？」
芝野は即座に断定した。
「私は完全に未完成だと思っています」
「そこで最初におっしゃっていた、Unicodeに移行するには5年や10年でも不十分じゃないかとおっしゃっていたのが、現実的な話になってくるわけですね」
ようやく分かったか、という顔で芝野は応じる。
「ええ。だから、うちの研究室でその辺をちゃんと検証してみようとしてますけどね。過去の活字印刷が、どのような形で各国でやってきたのかという調査。例えばヒンディーとか、タイとか、インドの各地、アラビアとかペルシャとかそういうところで、活版印刷はここまでやっていて、その前の手書きはこういう形でやっていて、で、今のコンピューター化のときに、どういう問題があるのか、そういうことを、きれいに整理していかないと、まだまだ分からないと思いますね」
知らなかった。うーん、なるほど、その通りですねと私は言った。芝野はコーヒーをグビリと飲み干しながら、覚えのわるい生徒に、言いきかせるようにつづけた。
「分かりますか？ そんなに簡単にUnicodeに移行して、万事解決するなら楽でいいんですが、皆さん物事を単純化しすぎていて」
そうなのもしれない。文字化けだらけのヨーロッパの文字コードの本を手にとって開きながら、私は言った。
「これを見ていると、Unicodeにしたくなる気持ちって、すごくよく分かりますね」
芝野は応じる。
「したい気持ちはとってもよく分かるんだけど、だから、そう簡単にはヨーロッパでだっていかんから困っているわけで、2000年問題よりも大きいですよね。これだけの種類のコードのデータが、日々溜まりつづけているんだから。そういうところで、Unicodeに移行だとは、なかなか。でもじょじょにUnicodeにしたいとは思っていますよ。でも、それはやっぱり……ね」
ふふふ、と笑った。午後のやわらかな光が研究室に射し込んでいた。建物の下のグランドからは、遠くなにかのゴールを決めたらしい学生の歓声がきこえてきた。芝野は笑顔をみせながら、こういった。
「賛成なんですよ。だから、どこにも私はUnicodeに反対していない。ただしUnicodeを使えば文字化けがないという状態にするためには、まずベースとしてそれぞれが必要な文字を、ちゃんと同定したうえで、それぞれの国の文字コードの中に入れて、その国の中では外字なんか必要ない世界っていうのを作り上げていかなきゃならないわけですよね。プライベートコード、外字を必要としない世界」
つまり、まずその国の実情にあった、2000JISなりを国内で規格化し、国内で普及させたうえで、それを国際の場にあげて、Unicode（ISO/IEC 10646）に反映させる。そういうプロセスが“筋”であり、いちばん大切なのだ。2000JISはそのためにこそ必要なのである。そして、今のパソコンで使うためにはシフトJISによる符号化が必要なのだ。芝野があれほどシフトJISにこだわった真意は、ここにあるのだろう。できの悪い生徒は、ようやく理解した。
「一方で、国際の場は各国のまっとうな要求は、ちゃんと取り上げていかねばならない。そこで問題なのは国際会議にいっても配られた資料を持って帰るだけの、昼間の会議では寝ていて、夜になると接待ばかりしている植民地の官僚みたいな代表がいっぱいいるということなんですよ」
●芝野がUnicodeコンソーシアムに出した、一通の電子メール。
ひとしきり芝野が語り終えた研究室に静寂がひろがった。時折芝野の机の上におかれた、常時接続されているらしいVAIOのノートPCからは、新着メールをしらせる昔のエンリコ・モリオーネのようなユーモラスなメロディーだけが聞こえてくる。
そろそろ頃合いかもしれなかった。ようやく態度を軟化させてくれた芝野を、ひょっとしてふたたび怒らせるかもしれないが、これはやはり聞いておかねばならない。
「今年の5月の時点で、芝野さんがUnicodeコンソーシアムに手紙という形で……」
芝野の反応は早かった。私が質問を最後まで言い終わらないうちに早口で訂正する。
「6月、7月くらい。7月くらいだと思います」
私は、なるべく気を取られないように、緊張しながら質問をつづけた。
「……提案をされてますよね。それはどういう意図で、どういう返事が返ってまいりましたか？」
芝野が出した一通の電子メールは、Unicodeコンソーシアムの正会員、Unisys代表アーノルド・ウィンクラーにあてられていた。それは他のメンバーに即座に転送され、Unicodeコンソーシアムのメンバーのなかに大きな波紋を呼んだという。その内容は、Unicodeに収録されていない2000JISの文字を、BMPに収録するよう提案したものだった。
「なんでUnicodeコンソーシアムに無関係な、国内規格の原案委員会が提案をしてくるのだ？」「だいたいBMPはもうフィックスずみだ」「いったいシバノは何を考えている？」「日本はどうなっているのか？」
Unicodeコンソーシアムの反応は、困惑と怒りがまじったものだったという。いったい、なぜ芝野はそのようなメールを送ったのだろう？
（以下次号）
なお、次週は取材のため、休載させていただきます。
※追記1 Windowsの2000JIS対応問題について
この原稿前半部分に“Windowsに2000JISを対応させるのは簡単である”と芝野がコメントをする箇所がある。そして、筆者はマイクロソフト広報部に対しこのコメントの確認をもとめたが、確たる回答を得られなかったとも書いた。しかし、さらにその後で、マイクロソフト広報部にチェックをもとめるため上記の原稿そのものを送ったところ、以下のようなコメントが返ってきた。原文のまま掲載する。これは2月10日付だ。
「マイクロソフトとしては、この部分の記載事項には、その実装方法など技術的見地から見て正しくない記述がなされており、この内容を肯定することはできません」
つまり、マイクロソフトは“Windowsに2000JISを実装するのは、簡単なことではない”と主張している。同時に同社はこの問題について私に直接会った上で説明することを望んでいるので、ちかいうちに結果を報告できると思う。
また、このマイクロソフトのコメントを読んだ芝野本人からは以下のようなメールがとどいた。これも原文のまま掲載する。これは2月15日付だ。
「マイクロソフトは、Unicodeに入らなければ実装できないといっていますが、MS Officeに標準で添付されるフォントの中には、Unicodeを完全に無視したものもあります。例えば、発音記号のフォントであるIPAKielSevenは、全くUnicodeを無視して、8ビットの領域を勝手に使っています。
ですから、Unicodeに入らなければ実装できないということは全くありません」
ところで、私自身は今でも芝野の言うとおり、“技術的には”Windowsシリーズに2000JISを対応させるのは容易だと思っている。ただしそれは純粋に技術レベルの問題であり、結果的には、彼らのコメント通り2000JISの新しい文字を収録するUnicode（もしくはISO/IEC 10646）のバージョンが出るまで対応しないだろうと考えている。それは、“技術”というよりは“政治”の問題といえるのではないか。
この問題はマイクロソフトのみならず、2000JISを考えるうえで多くの興味深いものをふくんでいるので、ギリギリのタイミングながらここに追記というかたちで書こうと思う。
その前にすこしお断りをしたい。私は10月にはじめて芝野に会ったとき、彼の多大な厚意により情報部会に提出された2000JIS最終案そのものを複写することができた。1、2回の原稿はこの最終案のコピーをもとに執筆したものだ。また、今年1月27日に日本規格協会にあるJCS委員会事務局にお話を聞きにうかがったとき、事務局の厚意によりその時点で一番新しい規格票案の一部（漢字と非漢字の分類配列を書いた附属書4と6）の複写をわけていただいた。このような無名ライターに寄せられた厚意に、私は深く感謝したい。以上の理由により、私が以下のべることは上記の規格票案にもとづくものであることをお断りする。ちなみにこれらの複写のうち、事務局からわけていただいた漢字部分の詳細を書いた附属書6のタイムスタンプは、1月9日午後3時3分とある。
私が“技術的”に容易と考える根拠は、2000JISの規格票にある。私の手元にある規格票案には、それぞれの文字の符号位置をしるした欄に、2000JISそのものの面区点番号、JIS X 0202[*訂正1]で拡張した場合のGL・GR領域での位置（これについては詳述しない。申し訳ないが専門書を参照してほしい）、シフトJISで符号化した場合の位置、そしてUCSでの位置が書かれている。
このうち問題なのはUCSの欄だ。UCSとは、Universal Multiple-Octet Coded Character Setの略であり、つまりISO/IEC 10646の別名だ。この和訳規格名はJIS X 0221。そしてISO/IEC 10646はUnicodeと現在のところほぼ一緒。これは原稿で書いた。2000JISのほとんどはすでにISO/IEC 10646に収録されている。私が2回数えた限りでは、収録されていないのは、漢字が第3水準が78文字、第4水準が278文字の計356文字、非漢字が126文字、総計482文字であった。そして、このUnicode（ISO/IEC 10646）に収録されていない文字は、規格票案では括弧で位置を表示している。そしてこれらの符号位置をよく見ると、いずれもUnicode（ISO/IEC 10646）のBMPに未定義領域として残っている“すき間”なのだ（私用領域として定義された場所でもない）。ちなみにBMPの開発じたいはすでにほとんど終了しており、これらの未定義領域は今後も空き領域として残る可能性が高いと思われる。
さて、この括弧内の符号位置をふくめれば、結果として2000JISのすべての文字はUnicode（ISO/IEC 10646） と一対一対応する。よってこの規格票のUCSの欄の符号位置にマッピングしたフォントをインストールすれば、“技術的には”Unicodeで動作するOS（Windows NT/2000[*補注]もそうだ）上で動作するすべてのアプリケーションで対応可能なはずである。私はそのように考えている。
[*補注]……Windows 95/98は内部的にシフトJISで動作しているので、シフトJISの欄の符号位置にマッピングしたフォントをインストールすればよいだけだ。[*注1]で述べたフリーの2000JISフォントはこうして動作しているはずだ。
次になぜ政治的な理由でマイクロソフトが現時点で2000JISを実装しないかを考えよう。一言でいえば、この括弧でくくられたマッピング（符号位置を与えること）が、イリーガル、非合法だからだろう。Unicodeコンソーシアムの正会員たるマイクロソフトが、非合法なマッピングを許容して実装するわけがない、はずだ。それを念頭においたのが、前述のOffice添付の発音記号用フォントでマイクロソフトがおこなっている非合法なマッピングを例にとる芝野の反論なのだと私は理解する。
ただし芝野、というより芝野が委員長をつとめる2000JIS原案作成のJCS委員会にも疑問がないわけではない。それはJIS X 0208:1997、つまり97JISで外字領域の原則使用禁止を打ち出したのは、ほかならぬ2000JISの前の仕事として97JISの原案作成を担当したJCS委員会自身だったからだ。第2回の原稿に詳しく書いたが、97JIS以前は、JIS漢字コードでは未定義領域がユーザー外字領域として解放されていた。それゆえに今日にいたる文字化け問題が発生してしまったのだが、97JISの大きな功績は、これを原則禁止にしたことにある。
97JIS規格票『解説 3.4.2 空き領域の取扱い』では、〈過去の規格票の“解説”が、空き領域を利用することを誤って推奨していた〉とし、未定義領域は〈ISO登録簿〉では〈使用禁止（This position shall not be used）として登録している〉と明確に位置づけている。この過去のJCS委員会がした指摘は、実はそのまま2000JISを作成した現在のJCS委員会への指摘として適用できるのではないか。
今回の2000JISのBMP未定義領域へのマッピングは、過去の“誤り”を指摘したはずのJCS委員会みずからが、同じ過ちを繰り返すことだと思う。では、なぜJCS委員会はこのような非合法なことを“あえて”したのだろう。これも私の推測だが、答えは芝野のコメントにある。芝野はインタビューのなかで繰り返し2000JISが“今すぐに最低限のコストで実装できる必要性”を説いていた。上記の括弧内の符号位置を使えば、文字通り“今すぐに”、そして“容易に”、すべてのアプリケーション上で2000JISを使うことが可能になる。
しかし、この“今すぐに2000JISを使う”方法が、結果的に日本独自のUnicodeのバージョンを作ることにつながり、将来的に文字化けを引き起こす（かつての97JIS以前のJIS漢字コードのように）ことにはならないだろうか？ 私としては、そのような懸念を持たずにはいられない。
最後にマイクロソフトに対しても疑問をのべたい。マイクロソフトの視点はあくまでもUnicodeにあり、ここまで述べた括弧内のUCS符号位置も、もしかしたら同社にとってはたんに“Unicodeに提案中であることをしめす”意味しかないのかもしれない。つまりそのようなマイクロソフトなら、“提案中”の符号位置を実装するはずもない。
しかし、マイクロソフトはJCS委員会に委員を派遣していることを忘れてはいけない。同社のようなUnicodeに重心をおく企業が、なぜ非合法なUnicodeの拡張につながる2000JISを、委員会の論議のなかで阻止しなかったのだろう？ Unicodeコンソーシアム正会員企業の責任はどこにあるのか。現実に規格票案を見る限りでは、参考ではなく規格としてこのUCSの符号位置は盛り込まれている。もし2000JISの規格票文末に、委員名がマイクロソフトの社名をあげて掲載されているならば、同社はこのUCSの括弧でくくられた符号位置に関して賛成したと見られても、おかしくはないのではないだろうか。
※追記2 第4回の原稿の補足
第4回の原稿の発表後、前寺正彦さん、松川一也さんから、Unicode―ISO/IEC 10646―JIS X 0221に発音記号はすでに収録されており、発音記号を出せるのは2000JISだけという芝野の発言は間違っているのではないかという趣旨のご指摘をいただいた。しかし2000JISにしかない発音記号はあり、そのことを彼はこの原稿に収録しなかった別の部分で明確にコメントしている。
2000JISにだけにある発音記号とはアクセントつきの発音記号だ。2000JISの面区点番号では1-11-41以降、43、45、47の計4面区点の文字をさす[*訂正3]。これらの元になる親字はいずれもISO/IEC 10646（和訳がJIS X 0221）では『IPA(International Phonetic Alphabet)拡張』とよばれる領域（0250～02A8）に収録されているが、アクセント記号つき（具体的にはアキュートつき）の字形は収録されていない。ISO/IEC 10646（Unicode）ではアクセント記号単体はすでに収録ずみなので、これと合成すればよいという判断からだ。ラテン文字圏ではこうした文字を合成する技術が確立されている。
しかし日本では、アクセント記号の合成をする機能は普及していないので、現実によく使われているものについては合成ずみの字形を2000JISで収録することにした。
――以上のように芝野は説明した。(2000.2.12)
※追記3 IPAKielSevenフォントについて
編集部の調査によると、芝野が『追記1』のなかでふれた『IPAKielSeven』は Linguist's Software社のフォントであり、マイクロソフト社のOffice2000シリーズ に添付された事実はない。以下のURLを参照してほしい。
http://www.imj.tky.plala.or.jp/roboword/rw3_about.html
また、2月29日におこなわれたマイクロソフトへのインタビューでも同社から同様の 指摘をうけた。
(2000.2.19 2000.3.1追加)
◎参考文献
・漢字文化は危なくない 見えてきたUnicode3.0（月刊ASCII 98.6）
・Unicodeを巡る放談会 Unicodeはどうやって決まっているのか（月刊ASCII 98.12）
・パソコンにおける日本語処理／文字コードハンドブック（川俣晶著 技術評論社 99.6.10）
・文字コードの世界（安岡孝一・安岡素子著 東京電機大学出版局 99.9.30）
・JIS X 0212:1993（日本規格協会）
・The Unicode Standard Version 2.0（The Unicode Consortium著 Addison Wesley 96年）
・文字コード標準体系検討専門委員会報告書(99-08) (99-09-22版) ( http://www.itscj.ipsj.or.jp/domestic/mojicode/houkoku922.pdf )
・JIS X 0221（ISO/IEC 10646）の目指すもの（98-11)芝野耕司 http://www.itscj.ipsj.or.jp/jp/ns39012.html.)
※コンポジション・メソッドに関する記述では、JIS X 0221:1995[*訂正2]（これは広義のUnicodeについての最良の日本語解説書だ。ちなみにこの原案作成委員会の委員長は芝野耕司氏）の規格票はもちろんだが、月刊ASCIIの『漢字文化は危なくない』をおおいに参考にさせていただいた。記して感謝いたします。
また、ISO/IEC 10646の最新の情報をえるなら、『文字コード標準体系検討専門委員会報告書』がいいだろう。
(2000.2.16)
◆お詫びと訂正
[訂正1]…… 小池和夫さんより本文中の規格名が間違っているとのご指摘をいただき、以下のように訂正した。
◎誤：JIS X 0211で拡張した場合のGL・GR領域での位置
◎正：JIS X 0202で拡張した場合のGL・GR領域での位置(20002.17)
[訂正2]…… 小池和夫さん、狩野宏樹さんより本文中の規格名が間違っているとのご指摘をいただき、以下のように訂正した。
◎誤：コンポジション・メソッドに関する記述では、JIS X 0212:1993
◎正：コンポジション・メソッドに関する記述では、JIS X 0221:1995 (20002.17)
[訂正3]…… 豊島正之さんよりご指摘いただき、追記1でふれている“Unicodeになく
2000JISにある発音記号”は、あと2面区点あることがわかり、以下のように訂正した。
なお、豊島氏よりは「JIS X0213:2000の規格票は現在印刷中で、あと3週間程で 市販に回る」との貴重な情報をいただいた。このメールは2月18日のものだから、発売は3月10日過ぎだろうか。ちなみに氏は2000JIS（JIS
X0213:2000）の規格票編集 責任者である。ありがたいことです。
◎誤：2000JISの面区点番号では1-11-41以降、43、45、47の計4面区点の文字をさす 。
◎正：2000JISの面区点番号では1-11-41以降、43、45、47、1-11-69、1-11-70の計 6面区点の文字をさす。前半の4面区点の元になる親字は（中略）技術が確立されて いる。また1-11-69は声調記号上昇調、1-11-70は声調記号下降調をあらわす記号だ 。(2000.2.19)
[訂正4]…… 伊藤弘樹さんより原稿中のフランス語発音記号「グレイブ」は、それぞれ「グラーヴ」の間違いであるというご指摘をいただき、修整した。ああ恥ずかしい。(2000.2.22)
[Reported by 小形克宏]