小形克宏の「文字の海、ビットの舟」
|
|
●符号化方法からJIS X 0213:2000を考える
文字コードは、文字を定義する文字集合と、その符号位置を定義する符号化方法のふたつからなる。JIS X 0213:2000（以下0213と略）の文字集合については前回を参照していただくとして、もうひとつの符号化方法について要点とその問題点を整理すると、下記のようになるだろう。
*シフトJISで符号化されることを前提に収録文字数を決定
-構造としてはISO/IEC 2022の符号化方法によるもの
-本当は17,672文字を収録可能だが、シフトJISと日本語EUCに対応させるために全
11,223文字にした
*現行のJIS漢字コード（JIS X 0208:1997、以下0208と略）を土台に拡張
-現行のJIS漢字コードとセットで使い、これを拡張する
-現行のJIS漢字コードの空き領域に新しい文字をいれてゆく拡張法
-現行のJIS漢字コードがもつ符号化方法(ISO/IEC 2022、Shift-JIS、ISO-2022JP)から0213に移行できるよう配慮
-ただし現行のJIS漢字コードと0213は包摂規準が非互換なため、このふたつは明確に区別して考えるべき
*文字化けをめぐる議論
-シフトJISの空き領域に文字を入れたため、そこに外字を入れていた各メーカー のシフトJISとの間で文字化けが発生する
-しかしこの文字化けは0213により新たに発生する問題ではない。違う外字システムの間では、現在も文字化けは発生している
*0213に規定された符号化方法は、国内では普及しないだろう
-実際には、0213はUnicodeの文字集合の一部として国内に普及する見通し
-よって0213の符号化方法の部分は、市場からは無視されるかたちになる
-皮肉だが、これは現実の世界だ
*カッコ付きUCS符号位置をめぐって
-0213とISO/IEC 10646(Unicode)の符号位置対応表の部分で、ISO/IEC 10646に未収録の文字は、カッコでくくり独自に空き領域の符号位置を割り当てた
-そして、このカッコ内の符号位置そのものはBMPを使用している
-カッコ付きUCS符号位置は、日本の公的な標準化団体が独自のISO/IEC 10646 (Unicode)のバージョンを作ることを意味しかねない
-ISO/IEC 10646への対応を担当する日本代表JSC2の委員はこれを非難
-インターネットで文字コードを議論する場でも反対意見を読むことができる
→『国際規格への提案の動き』で説明する「IANAへのcharset name登録」を参照
-主要OSメーカーのアップルコンピュータとマイクロソフトは、このカッコ付きUCS符号位置を“規定”ではなく“参考”であるとして無視する構え
-一方で原案作成の芝野JCS委員長は、これを情報交換用ではなく内部処理用の限定された用途のものと説明
-ただし規格票には、このカッコ付きUCS符号位置の意図は何も書かれていない
●シフトJISを前提に収録文字数をきめた0213
規格としての0213は、縦94×横94の文字表2面分で構成されている。第1面は0208と同一で、0208の空き領域を埋めるかたちで0213の文字があらたに1,908文字収録されている。第2面は0213だけの文字集合で2,436文字。
この94×94が2面という構造は、7ビット（128文字）・8ビット（256文字）系の文字コードを拡張するためのISO/IEC 2022（JIS規格ではJIS X 0202）という規格に由来するもので、0213の規格本体の符号化方法は、このISO/IEC 2022によるものだし、先行するJIS漢字コード、0208の規格本体の符号化方法もこれだ。
実装しやすいように、0208をふくめた第1面だけをサポートするものを実装水準3（全8,787文字）、両面ともサポートするものを実装水準4（全11,223文字）とする。0208は第1・第2水準漢字から成り立っているが、0213のことをJIS第3・第4水準漢字とも呼ぶのは、ここからだ。
ところで94×94が2面ならば、0213の収録文字数は17,672文字のはずだ。だが0213は1,908＋2,436＝4,344文字で、0208の収録文字数6,879文字と足しても全11,223文字。あと6,000文字あまりも入るのにどうして？
それがつまり、0213をシフトJISと日本語EUCに対応させたからなのだ。ISO/IEC 2022ベースで符号化可能な17,672文字のうち、まずシフトJISで符号化可能な領域（11,280文字）を取り出し、その上で日本語EUCで不都合がでる領域をのぞいて、現在の全11,223文字という収録文字数に落ち着いた。このことを分かりやすくするために、すこし角度をかえて、もう一度説明すると、以下のようになる。
シフトJISで符号化可能な11,280文字のうち、すでに0208で6,879文字は符号化している。残りの4,401文字の領域のうち、日本語EUCで符号化したときに不都合がでる領域を避け、最終的に0213の収録文字数は4,344文字になった。
逆にいえば、0213は当初からシフトJISや日本語EUCといった市場で有力な符号化方法を十分に考慮に入れて開発されたのだと言える。
●0213のシフトJISは文字化けを生むのか？
このようにして、シフトJISの視点から見えれば、0213はその空き領域に文字を埋める形で0208を拡張したと言えるのだが、これは同時に、今まで空き領域に外字を入れていたメーカーにとっては、自分たちのシフトJISと新しい0213版シフトJIS、規格票でいう『Shift_JISX0213』との間で文字化けが発生するということを意味する。
これを理由として、0213は最終審議の場でシフトJISや日本語EUC、インターネットで使うISO-2022JPによる符号化方法を定義する部分を“規定”から“参考”に変更することになった。これは後の『制定過程』で詳しく述べる。また、一部に誤解があるようだが、“参考”の部分を実装しても、0213には適合す る。“参考”は規格の一部ではないので、参考部分が実装されている・いないとい う事実は、規格への適合性とは直接関係はない。[訂正1]
ここで説明しなければならないのは、Shift_JISX0213があらたに文字化けを起こすわけではないということだろう。なぜならば、シフトJISの空き領域は、各メーカーで勝手に外字を入れており、0213が登場する前から、これら各メーカー版のシフトJIS同士で情報交換すれば文字化けは発生していたからだ。たしかにShift_JISX0213によってあらたな文字化けの要因が増えただけかもしれない。しかし、文字化けをなくそうとするなら、これは仕方ないことだと言わざるをえない。シフトJISのバージョンが乱立して困っているならば、これをShift_JISX0213に統一すればよいのだ。なぜならば、0213は“現代日本語を符号化するために十分な文字集合”であり、必要な文字はここに収録されているはずだからだ。そのうえ典拠も文字の同定も、包摂規準も比類のないくらいしっかりしている。統一するには十分なものではないだろうか。
しかし……現実はシフトJISはShift_JISX0213に統一されないだろう。私の知るかぎりで、主要なOSのうちShift_JISX0213をサポートするものはないからだ。現在のバラバラなシフトJISは自然に息絶え、じょじょにUnicode[*1]に取って代わられることになろう。このことは明日掲載の次回に詳しく述べる。
[*1]……この原稿ではISO/IEC 10646もふくむ。以下Unicodeとのみ表記。UnicodeとISO/IEC 10646の関係については第2回を参照。別々の規格ではあるが、文字コードとしてはほぼ同一であり、両者は自転車の両輪のように連携をとって開発をしている。大ざっぱには文字集合の拡張はISO/IEC 10646がリードし、実装するためのさまざまな情報をUnicodeが付加すると考えておけばよい。実装される場合は『Unicode』と称するメーカーが多いようだ。
●0208そのものを拡張する0213。運用時は0208とセットで使用される
規格としての0213は、あくまでもJIS漢字コード(0208)を拡張するもので、0208と同時に使うことを想定されている。だからこそ規定される符号化方法も、0208のそれからスムーズに移行できるよう考えられている。
0208と同時に使われる規格だという意味ではJIS X 0212:1990（以下、補助漢字）と性格が似ているといえる。しかし補助漢字は市場で支配的な符号化方法、シフトJISで0208とともに使う方法を規格として明示しなかった[*2]ために、規格としてはほとんど使われなかった。もっとも文字集合の部分が、ISO/IEC 10646(Unicode)に収録されたり、UNIXワークステーションで使われる日本語EUCという符号化方法で使うことはできた。しかし規格票の『適用範囲』に謳う0208の補助[*3]という目的を果たすほどに広く使われているとは思えない。だからこそ0213は作られなければならなかったのだろう。
ただし規格として0213をみる場合に注意しなければならないのは、0208から包摂規準が変更されていることだ。つまり“0208と同時に使われる”と言っても、0208単体で使われるときと、0213において同時に使われるときの0208では包摂規準が変わってくる。一部で0208では包摂されていた、つまり例示字体としては収録されていなかった字体が、0213では新たに収録されているからだ。
たとえば、子の名前に使える漢字をさだめた『人名用漢字別表』（以下、人名用漢字）のうち、いわゆる康煕字典体（つまり旧字体）で使用可能な文字を『人名用漢字許容字体表』（以下、許容字体表）というもので規定している。
すでに0208では人名用漢字はすべて収録している。一方で許容字体表の205文字については115文字を収録し、残りの90文字は人名用漢字の字体に包摂するとしていた。つまり90文字だけは、人名用漢字と許容字体表の字体を書き分けられなかったわけだ。0213ではこの90文字を新たに収録した。包摂規準を変更し、0208では包摂していた字体を、0213では包摂しないことにしたのだ（図1）。
同様に常用漢字表のなかの文字で、カッコ書きでいわゆる康煕字典体（旧字体）がそえられていた『常用漢字表康煕字典体別掲字』（康煕別掲字）も、0213によってすべて常用漢字表の字体と書き分けられるようになったのだが、これらの非互換な変更は、すべて法令などに明確な根拠がある場合に限っておこなわれた。図１:包摂規準を変更して新たに収録された『人名用漢字許容字体表』の文字の一例
(人名用漢字別表)
(人名用漢字許容字体表)それにしてもこの表の右の方の字体など、一目で違いを見分けられる人が何人いるのだろう……。
このことを符号化方法に引きつけて考えてみると、もう少し分かりやすい。たとえば、規格としての0213では、以下にあげる符号化方法はすべて明示的に区別されなければならない。
(1)0208のシフトJIS
(2)0213の第1面だけを符号化するシフトJIS（規格では『Shift_JISX0213-plane1』）
(3)0213のすべてを符号化するシフトJIS（規格では『Shift_JISX0213』）
つまり従来は、“公的なシフトJIS”[*4]といえば、唯一0208(97JIS)の附属書1で規定されたバージョンだけだったのが、これで３つのバージョンに増えたわけである。
ただし、包摂規準が非互換といっても、この３つそのものは (1)＜(2)＜(3) の順の上位互換関係にある。そして仮に一番上位（一番多くの文字を符号化できる）の(3)でしか符号化できない文字を(1)で受け取ったとしても、“？”や空白になるだけで、別の文字に置き換わるといったことにはならない。
[*4]……もっとも、この“公的なシフトJIS”を実装したシステムというのを、寡聞にして私は知らない。そして、あとのふたつも現実には普及はしないだろう。理由は次回本文で述べる。もちろん現在市場で圧倒的なシフトJISはWindows 3.1、Windows 95/98に実装されている、『Windows標準キャラクタセット』だ。
（以下、5月25日号掲載の第3回につづく）
訂正
[*訂正1]……川俣晶さんから規格の“参考”について正確ではないというご指摘をい ただいた。以下のように訂正したい。
●訂正前：また、一部に誤解があるようだが、“参考”の部分を実装しても、0213には適合す る。“参考”とはいっても、あくまでも正式な規格の一部なのだ。
●訂正後 ：また、一部に誤解があるようだが、“参考”の部分を実装しても、0213には適合す る。“参考”は規格の一部ではないので、参考部分が実装されている・いないとい う事実は、規格への適合性とは直接関係はない。
文中にでた規格の規格票の他に、下記の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/24)
[Reported by 小形克宏]
INTERNET Watch編集部internet-watch-info@impress.co.jp Copyright (c) 2002 Impress Corporation All rights reserved.
