バックナンバーへ
このほかの連載へ
 【連載】

小形克宏の「文字の海、ビットの舟」
――文字コードが私たちに問いかけるもの　　

第2部　これが0213の特徴とその問題点
第3回　符号化方法編（下）

 　 　 　 　
Illustation:青木光恵

●実際の市場ではJIS X 0213の符号化方法は無視される

　さて、前回くどいくらい“規格としては”とわざわざ断ったのには理由がある。これは次回以降『実装をめぐる問題』でも述べることだが、実際には規格としてのJIS X 0213（以下、0213）を実装するOSはない。現在のOSは内部コード（OS内部のデータ処理に使う文字コード）としては、ほとんどUnicode[*1]の符号化方法を実装している。またJavaやXMLといった最新技術もデフォルトの文字コードとしてUnicodeを指定している。唯一の例外はシフトJISを内部コードとして実装するWindows 95/98[*2]だが、これとて来年のクリスマス登場が噂されているメジャー・アップデート版『Whistler（ウィスラ）』によってWindows 2000と統合され、全面的にUnicodeを実装することになる。またマイクロソフトは、基本的な方針として文字集合の拡張はシフトJISベースではおこなわず、Unicodeによってのみおこなうと明言している。これはすでに特別編第4回のなかで詳しく述べた。

　

[*1]……この原稿ではISO/IEC 10646もふくむ。以下Unicodeとのみ表記。UnicodeとISO/IEC 10646の関係については第2回を参照。別々の規格ではあるが、文字コードとしてはほぼ同一であり、両者は自転車の両輪のように連携をとって開発をしている。大ざっぱには文字集合の拡張はISO/IEC 10646がリードし、実装するためのさまざまな情報をUnicodeが付加すると考えておけばよい。実装される場合は『Unicode』と称するメーカーが多いようだ。

[*2]……現在もWindows 95/98は一部のAPIレベルではUnicodeに対応しており、Unicodeの符号化方法を使うことも可能だ。その意味ではWindows 95/98もUnicodeをサポートしている。 APIとはApplication Programming Interfaceの略で、OSがアプリケーション・ソフトに対して公開しているプログラム用のインターフェイス。アプリケーション・ソフトはAPIを通じてOSの機能を利用する。


　Unicodeの文字集合は、最初からJIS X 0208（以下、0208）とJIS X 0212（以下、補助漢字）を収録している。そして0213の文字も大半が他の漢字使用国の規格の出身文字として収録ずみで、純粋に0213にしかない文字は400弱しかない。しかし、その大半は現在審議の最終段階をむかえつつある漢字拡張案、Extension Bに入っており、おって正式に収録されることになるだろう。いくつかUnicodeに収録されるのが難しそうな文字があるが、これがなげかける問題は『国際規格への提案の動き』としてあらためて述べる。いずれにしても大半の0213の文字はUnicodeに収録される流れにあると理解してよい。

　ということは……規格としての0213は、符号化方法の部分は実質的に無視され、文字集合の部分のみがUnicodeに“吸収”されるということになる。そこでは、前述したような補助漢字と0213の適用範囲の違いといったことはもちろん、0213は0208と同時に使う規格ということも、包摂規準が変更されたということも、一切合切がチャラになり、0208、補助漢字、0213は、Unicodeのなかの日本語文字集合として大ざっぱにひと括りにされる[*3]。そこで問題になるのはUnicodeの適用範囲、Unicodeの符号化方法、Unicodeの包摂規準だけだ。そうして0213が正式にISO/IEC 10646に収録された後、その和訳JIS規格、JIS X 0221（そう、UnicodeもJIS規格のひとつなのだ）が改訂され、こうして晴れて0213の文字は二度目のJIS規格入りをするわけである。

　

[*3]……正確には、Unicodeの日本語文字集合のソースとしては、ここに挙げられているJIS規格の他、658文字の “Unified Japanese IT Vendors Contemporary Ideographs,1993”というものがある。ISO/IEC 10646の審議に参加する日本代表団(JSC2)が、国内の有力メーカー5社から集めて、漢字を拡張するExtension Aに収録されることになったものだが、日本の他の文字集合がすべてJIS規格であるのに対し、この文字集合の典拠について詳細な説明は今にいたるまでなされていず、正体不明と言わざるをえない。これについてメールによる私の問い合わせに、現在のJSC2委員長・石崎俊は以下のように回答をよせてくれた。


《私自身はExtension Aの最初から参加した訳ではないので、人づてに聞いている部分がありますが、その範囲でお答えしたいと思います。
　1992年にISO/IEC 10646-1が決議されると直ちに漢字の追加作業に入ったそうです。そして、IRGの各国は国家標準にあるにもかかわらずISO/IEC 10646-1に入らなかった漢字を直ちにしかも大量に出して来ました。
　我が国はJIS漢字はすべてISO/IEC 10646-1に入れたのですぐに提案できる国家標準の漢字はない状況でした。そこで、その当時の最新のJISであったJIS X 0212への追加という意味と、IRGの参加国と歩調を合わせるために直ちに用意できる漢字という意味で、当時の漢字に関する有力メーカー5社から追加漢字を集めたそうです。始めは3,000以上あったレパートリーは、2社以上が提案した漢字という確かなニーズの確保や、辞書にあるという典拠の確保によって現在の658字程度に収まりました。
そのようなレパートリーの漢字は、有力メーカーがフォントを開発して実装していたということ、また複数の会社が使用していたことから、確かなニーズがあったと思われます。典拠については、我が国が提案したすべての漢字は辞書に載っているものに限定したので、権威ある辞書の典拠をもっていると言えると思います。
　また、ISO/IEC 10646-1の漢字の標準化では、参加国の漢字をユニフィケーション（引用者注：統合・包摂）する必要があるため、一度提出した漢字の変更は他の参加国に大きな影響を与えてしまいます。したがって、提案した漢字のレパートリーは早期にフリーズして、それ以降は追加や変更を原則として禁止しています。
このようなExtension Aのレパートリーと典拠については、秋に制定予定のJIS X 0221:2000（JIS X 0221第2版）の解説で説明する予定です。》


●来年末をめどにアプリケーション・ソフトはUnicodeへの転換を早める


　そういうわけだから、前回で述べたように0213で定めたシフトJIS、Shift_JISX0213で日本の市場が統一されることもない。もちろん連載の第4回で、0213の原案作成をした芝野耕司委員長が主張したように、シフトJIS対応のアプリケーションは残るだろうし、今まで蓄積された膨大なシフトJISのデータも使い続けなければならない。しかしUnicode対応のOS上でシフトJISのアプリケーションが使えなくなるわけではないし、データも同様だ。変換表でシフトJISからUnicodeに変換すればよいだけの話だからだ。文字コードをAからBに変換することは、ごくありふれたことに過ぎない。

　つまり、芝野委員長の言うようには、これらはUnicodeへの流れを押しとどめるほどの障害にはなりえない。このことは、これから数年のコンピューターの発展が証明していくことになるだろう。
　おそらくは最大のシェアをもつコンシューマー用のOS、Windows 98が、今年秋に予定されるマイナー・アップデート版Windows Me（ミレミアム・エディション）[*4]を経由し、Windows 2000と統合される来年末のウィスラにいたるまでに、アプリケーション・ソフトはUnicodeへの転換を早めていかざるをえなくなるだろう。もちろん、これはマイクロソフトが予定通りにアップデートできることが前提ではあるが。
　私はUnicodeを一方的に礼賛しているつもりはない。しかし現実問題として、文字コードの未来はUnicode以外にはないだろうと考えている。だからこそ、Unicodeを理解し、それが間違った方向に進むのならば、声を上げていくべきなのだろう。

　

[*4]……5月23日、マイクロソフトはWindows Meについてのプレス向けセミナーを開催した。ここでの説明によれば、Windows MeはあくまでもWindows 98のマイナー・アップデートであり、内部コード、API、フォント、IMEに対するUnicodeサポートは、Windows 98とまったく同じレベルだという。これらの改訂はすべてウィスラでおこなわれる予定だ。


　0213の符号化方法について、一番踏まえなければならないのは上記の事実、つまりUnicodeへの転換がすすんでいく市場のなかでは、Unicodeの文字集合の一部としてしか受け入れられない、つまり規格としての0213でさだめられた符号化方法は無視されるということだろう。皮肉だが、これこそが現実の世界なのだ。


●カッコ付きUCS符号位置が投げかけるもの


　カッコ付きUCS符号位置については、特別編第4回で詳しく述べた。ここでは前回冒頭にあげた要約以外に繰り返すことはしない。しかし0213の符号化方法を考えるうえでは、やはり抜きにはできない問題だ。インターネット上でもこのカッコ付きUCS符号位置をめぐる反対意見を読むことができること（ http://lists.w3.org/Archives/Public/ietf-charsets/2000AprJun/0038.html ）を付け加えておこう。この日本以外からの反対意見がどのような意味をもつのかは、次回以降『国際規格への提案の動き』であきらかになるはずだ。
　
　今回は『符号化方法』と『制定過程』をまとめて1回で紹介する予定だったが、前者だけで2回をつぶしてしまった。先を急ぐことにしよう。

文中にでた規格の規格票の他に、下記のURLのドキュメントや雑誌記事により多くの知識を得ました。記して感謝いたします。

◎参考URL
・『文字コード』豊田英司( http://dennou-t.ms.u-tokyo.ac.jp/arch/zz1998/mozi/zengaku.html )
・『漢字コードとコーディング方法』今田 庸介( http://tron.is.s.u-tokyo.ac.jp/~imada/kcode/kcode.html )
・『JIS X 0213の特徴と、Emacs上での実装』KAWABATA Taichi(http://www.m17n.org/mule/m17n2000/proceedings/kawabata/jisx0213.html )

◎参考文献
・文字コード論から文字論へ[訂正]（家辺勝文　人文学と情報処理 第26号　00.4.15）
・JIS X 0213の符号化表現（安岡孝一　人文学と情報処理 第26号　00.4.15）

[訂正]

「文字コード論から文字論へ」のタイトルが誤っておりました。心よりお詫び申し上げます（5月31日）。

誤：文字コードから文字論へ
正：文字コード論から文字論へ

(2000/5/25)

[Reported by 小形克宏]