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

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

特別編2
ISO/IEC 10646で却下された(?)JIS X 0213の新漢字一覧表

       
Illustation:青木光恵

●国際規格にどの文字が含まれる!? 注目されるJIS X 0213新漢字のゆくえ

 今年1月20日に制定された従来のJIS漢字コード(JIS X 0208、以下0208)を拡張するJIS X 0213:2000(以下0213と略。なお前回までは"2000JIS"としてきたが、今回から本来の規格名での表記に改める)。3月8日に待望の規格票が発売[*1]されるという今日、一番注目されるのが、0213にだけ存在し、国際規格であるUnicode(ISO/IEC 10646)にふくまれない文字が、どのようなかたちで収録されるかということだ。

 

[*1]……3月6日に0213の原案作成を担当したJCS委員会、芝野委員長に電話取材した際の情報。価格は1万円を越える程度のようだ。

 

 前回、2月23日の原稿「MacOS Xの新フォントと2000JISの関係」において、アップルコンピュータはこれからの方針として“情報交換用の文字コードとしては、符号化方法はUnicode、文字集合は0213”と明言した。そして、今年夏に発表される次期OS、MacOS Xに添付されるヒラギノ・フォントに、はやくもいくつかの0213の文字が収録される。そして0213への対応は、いくつかの段階をおって完全なものにしていきたいという。
 一方、2月29日に私はマイクロソフト開発首脳にインタビューすることができたが、その場でも加治佐俊一(ビジネス&エンタープライズ開発統括部次席代表兼エンタープライズ開発統括部長)は、現代日本語の表記に必要なレパートリー(文字集合)として0213を高く評価していることを言い、「そのような評価をしている我々が0213に対応しないわけがない」と明言した。方針としては“符号化方法はUnicode、文字集合は0213をふくむ日本文字レパートリー”ということになる。ただし、アップルコンピュータと違うのは対応のタイミングだ。アップルが対応可能な文字からどんどんフォントに字体を収録していこうという方針なのに対し、マイクロソフトは「0213の文字が、文字集合としてUnicodeに収録された段階で」(加治佐談)の対応となる。その意味では、第2回の原稿ではじめて同社の0213に対するコメントを伝えてから、同社の姿勢にはゆらぎはない。
 これ以外にも興味深い話が聞けたのだが、それは近日中に改めて取り上げることをお約束し、この0213に対するマイクロソフトの姿勢を取り急ぎ読者に皆さんに伝えする。

 では、どうしてUnicode(ISO/IEC 10646)にふくまれない0213の文字のゆくえが注目されるのだろう? それを明らかにするのが、今回の“一覧表”なのだ。
 実は今回こそは、2月16日の「第5回 JCS委員長、芝野耕司の反論(後編)」の続編をお届けするつもりでいた。この第5回の原稿最後で、芝野が'99年7月(芝野談)にUnicodeコンソーシアム正会員、Unisysのアーノルド・ウィンクラーにあてた電子メールのことにふれている。その内容は、Unicodeに収録されていない0213の文字を、BMP[*2]に収録するよう提案したものだった。

 

[*2]……ISO/IEC 10646は、現在2つの種類がある。UCS-2とUCS-4だ。UCS-4は、タテ256×ヨコ256の区点からなる“面”を256面あつめて“群”とし、全体を128群とする体系だ。256×256×256×128=21億7264万9472文字となる。2^31=2,172,649,472と同じで、つまり31ビットコード。
 このUCS-4の22億もの符号位置は当然まだまだ埋められていない。ではどこまでいっているかというと、最初の群の最初の面、つまり第00群の第00面だけは“ほぼ”収録が終了していて、この面をとくにBMP、Basic Multilingual Plane、基本多言語面とよぶ。第01面以降は今はからっぽであり、つまりUCS-4を実装するOSも、あつかっている文字はBMPにかぎられているのが現状だ。このBMPだけを実装すると、256×256=65,536文字=2^16=16ビットコードとなる。そしてこれこそがUCS-2、つまり現在のUnicodeなのだ。UCS-2を実装しているのは、MicrosoftのWindowsOSシリーズだ。
(以上、説明のため第4回原稿の一部を変更して再掲。なお、この時UCS-4を32ビットコードとする間違いをおかしたが、上記の文書のように31ビットコードとするのが正しい。近日中に本体の第4回の方に訂正文を出したいと思っている。ご指摘いただいた多くの皆さんにお礼をいいます)

 

 BMPを拡張する最後の領域であるはずのExtension A最終締め切りが、すでに何年もまえに終わっているのに、また新たにBMPに文字を提案しちゃうという、これはもう横紙破りといわれても弁解しようのないこの手紙への返信は、実はウェブ上で公開されている( http://www.cse.cuhk.edu.hk/~irg/irg/N690_Lisa_JIS.doc )。この返信を中心に、芝野との会話、そしてUnicodeやISO/IEC 10646の日本側代表のコメントで構成するつもりでいたのだが、それを書く前にぜひともやっておかねばならない作業があった。
 それが今回の原稿の核になる、“ISO/IEC 10646で却下された(?)JIS X 0213の新漢字一覧表”の作成だ。つまり、今国際の場では、0213はどのように審議されているのか、ということだ。これを押さえておかないと、ちゃんとした原稿が書けない。ところがですね、これが面白いんだなぁ。すげー面白い。どこかの三文ライター(俺だ)が書く、どこかで読んだような“人間ドラマ”より、よっぽどドラマチックですよ。あんまり面白いから、原稿よりも前に、この一覧表の公開に踏み切るというわけであります。
 
 これからお見せする資料は、何も入手するのに特別な労力(強力なコネを使ったり、こっそり不正にコピーしたり)を使ったりしていない。ウェブ上で公開されている資料や、公開セミナーで配布された資料が元になっている。もちろんまだ規格票が発売されてない時点で、私が規格票案を持っているということじたいは特別かもしれないが、それだって何の実績もコネもない無名ライターが、真っ当な(つまり誰でもできる)取材をした結果だ。そうした特別でない資料をもとに、これだけの事実が浮き彫りになるんだから、すごい世の中になったものでございます。今まで新聞記事の中の絵空事でしかなかった“情報公開”ってことを実感しましたよ。
 
 この一覧表を細かく読み込むことで、さまざまな分析ができると思う。これから私がするものは、そのごく一部でしかない。私などよりももっと確かな目を持っている人がみれば、もっともっと多くの“物語”を、そこに見いだすことが可能なはずだ。だから、なるべく読者の皆さんが追試可能なように、表の元になった資料を公開することにする。特別でない資料をもとに特別でない分析をする者としては、当然のことだろう。
 たぶんこの表からは、多くの国々の多くの立場の人々が参加して出来てゆく“国際規格”というものが、どのような外交をへて作られてゆくのかという、ある種“現場の空気”のようなものが感じとれるとおもう。そしてその雰囲気は、従来は直接交渉に携わっている人々とその周辺、どう多く見積もっても100人は越えないだろう人々しか知ることがなかったはずだ。しかし、もう違う。この状況は、ひとえにISO IEC/JTC 1/SC 2のサイトに、さまざまな資料がアップロードされているゆえなのだが、いったい誰が資料公開を決断してくれたのだろう? ある人が、同サイトが充実してきたのは、SC 2委員長が芝野耕司その人になってからだと言っていたが、さて……。  

 

●一覧表ができるまで  

 今回は、とりあえず漢字にしぼって検討する。非漢字にも重要な問題はあるが、それはまた別の機会としたい。それからこれは重要なことだが、ここで検討した資料や、分析の結果はいずれも最終的なものではなく、現在では変わっている可能性がある。だいたいが、現在ISO/IEC 10646を拡張するExtension B[*3]の開発は最終段階にあるものの、まだ決定ではない現在進行形、流動的な状態であり綱引きの真っ最中だ。

 出発点は先にふれた芝野の電子メールだ。これがどんなものなのか、公開されていないので分からない(まあ当然かもしれません)。しかし返信は、前述したようにウェブ上で公開されている。それもISO/IEC 10646を審議するSC 2/WG 2と、その下部機関IRG[*4]のサイトの双方にある。どうしてUnicodeコンソーシアムではないサイトで公開されているのかを考えると興味深いが、それはさておき、'99年11月23日付けUnicodeコンソーシアム技術委員会リサ・ムーア委員長(米IBM)が署名するこの返信のなかで、彼女が「この受諾は仮のものであり、UnicodeコンソーシアムおよびISO/IEC SC2/WG2は、Unicode標準とISO/IEC 10646のすりあわせを継続する」(原文は英文)と繰り返すように、この結果そのものは仮受諾の域を出ないものだ。それでも結論からいうと、ここでしめされた方針は、現在でも大筋で変わらない。

 

[*3]……第02面に割り当てられ、現在各社で実装が進められようとしている符号化方法UTF-16で利用可能となる漢字用の拡張領域名称。新漢字がExtension Bに入るということは、別の言い方をすれば芝野が望んだBMPには入らないということになる。
[*4]……ISO(国際標準化機構)とIEC(国際電気標準会議)によるJoint Tchnical Committee-1(第1合同委員会)という親委員会のもとで、文字コードを管轄するのがSC2(第2専門委員会)。この関係を表記すると“ISO/IEC JTC 1/SC 2”となる。このSC2の中でISO/IEC 10646を審議しているのはWG 2(WorkGroup2―第2作業部会)という部会だ。その下部機関IRGはIdeographic Rapporteur Groupの略で、ISO/IEC 10646に収録する漢字の選定作業をする。メンバーはUnicodeコンソーシアムの委員と一部かさなる。

 

 さて、リサ(友達ではないけれど語呂がいいのでファーストネームで呼ばせてもらいます。許してね>リサ)からの手紙で漢字に関しては以下のように述べられている。


(1)56文字の互換漢字[*5]について


 UTCは、漢字領域開発当初から、56文字の互換漢字の追加を提案されていた。だから今、UTCは56文字の互換漢字の追加をサポートし、これをIRGへ取り次ごうと思う。我々は、キャラクターだけでなくあなた方が提案書において提案された符号位置(FA30..FA67)もサポートする。

[*5]……BMPのR領域(互換漢字領域)に追加される漢字をさす。R領域は本来漢字を収録するI領域(CJK統合漢字領域)には入れられない例外の漢字を収録する場所のことだ。ところで、別の言い方をすれば、これらの仮受諾された互換漢字は、芝野が提案したようにBMPに収録されるということになる。

(筆者注:非漢字部分は中略)

(8)313の新漢字[*6]について

 UTCは、以下に挙げたいくつかの深刻な懸念により、これらの漢字については、現時点では検討しない。

提案された部首の多くは、すでに符号化されている。たとえばAB99(2ECCに符号化されている)、AB6C(2EC0に符号化されている)、そしてABBE(2EDEに符号化されている)である。
統合されたキャラクターのグリフ・バリエーションが存在する。
これらの313の新しい漢字が、Plane 2に符号化されされているExtension Bにすでに含まれているかどうかが明らかでない。
これらのキャラクターがExtension Bに含まれていないのであれば、それらはIRGに提案されるべきである。

 

[*6]……BMPのI領域(CJK統合漢字領域)に収録される漢字をさす。本来漢字はこの領域に入れられることになっている。結局、後述するように互換漢字をのぞいて、新漢字はすべてBMPではなく、第2面のExtension Bにまわされることになったようだ。

 



 しかし、これを読んだだけでは、なにがなにやらさっぱり分からない。そう、どんな文字を、どこに提案したのか分からなければ、話は始まらない。このリサの返信に直接対応する、つまり芝野の電子メールに比較的近いと思われる提案は、0213の原案作成をしたJCS委員会のサイトで入手可能だ。 http://jcs.aa.tufs.ac.jp/fdis-an.htm にある、〈●ISO 10646及びUnicode提案用資料〉の項目にある文書がそれだ。ただし、8月6日付と古くて、この後討議のなかで修整が繰り返されているので、われわれが知りたい“現在審議されている文字”をさぐるためには参考程度にしかならない。
 
 そこで、SC 2/WG 2のサイトをさがすと、以下のような文書が見つかる。

http://wwwold.dkuug.dk/JTC1/SC2/WG2/docs/n2092.pdf
(Addition of 48 Hiragana & Katakana characters)

http://wwwold.dkuug.dk/JTC1/SC2/WG2/docs/n2093.pdf
(Addition of 27 medical symbols and 50 enclosed numbers)

http://wwwold.dkuug.dk/JTC1/SC2/WG2/docs/n2094.pdf
(Addition of 13 linguistic educational characters)

http://wwwold.dkuug.dk/JTC1/SC2/WG2/docs/n2095.pdf
(Addition of 56 CJK ideographs which are already unified)

 最初の3つは非漢字の提案書(先のリサの返信中では半分以上が却下されている)で、最後の4番目が仮受諾された56文字の“互換漢字”だ。これらの日付は上位ページの http://wwwold.dkuug.dk/JTC1/SC2/WG2/docs/documents によれば、'99年9月13日となっている。これらはいずれも正式にISO IEC/JTC 1/SC 2/WG 2で受理された書類であり、それぞれJCS委員会の提案書に、日本側代表のJSC2[*7]による上書きが添えられている形になっている。つまり、JCS委員会とJSC2とのやりとりをへて、正式に国際の場に提案されたものだ。JSC2はISO/IEC 10646を審議する日本代表だから、当然提案もUnicodeコンソーシアムではなく、ISO IEC/JTC 1/SC 2/WG 2にされることになる。つまり、芝野ひきいるJCS委員会は、UnicodeコンソーシアムだけではなくISO IEC/JTC 1/SC 2/WG 2にも提案する両面作戦をとっていたようだ。そしてリサのUnicodeコンソーシアムとISO IEC/JTC 1/SC 2/WG 2は連携を先のリサの手紙に見られるように連携をとって動いている。ややこしいことに、WG 2の上部機関ISO IEC/JTC 1/SC 2の委員長は、前述したように芝野でもある。やれやれ……。


[*7]……注4で説明した“ISO/IEC JTC 1/SC 2”に日本代表として出席するのがJSC2だ。日本(J)のSC 2であることからこうよばれる。情報処理学会の情報規格調査会におかれる。国際機関に対応することから、“国内対応委員会”とか“ナショナル・ボディ(NBと略される)”とよばれる。

 

 リサの返信が11月23日付であることを考えると、JCSのサイトにある時点の提案書よりは、このサイトの提案書を踏まえて彼女は返事を書いているのではないかという推測がなりたつ。したがって、これらの提案書を対象に検討したいのだが、困ったことに、n2095.pdfにある“互換漢字”以外の“新漢字”の提案書がないので、いったいどの字体が“新漢字”なのか分からない。

 そこで登場するのが、'99年11月12日に都内で開催された『第2回 築地電子活版創立紀念連続セミナー』で、JCSオブザーバー(役割は委員と同じ)小池和夫が配布した資料だ( http://internet.watch.impress.co.jp/www/column/ogata/special2/list.pdf )。この資料(以下小池資料)にも日付がない。しかし〈表の見方〉の部分に〈9月のSC2/WG2に提出された〉云々という記述がある。これは http://wwwold.dkuug.dk/JTC1/SC2/WG2/docs/meetings の会議日程のページにある'99年9月16~19日デンマーク・コペンハーゲンで開かれた会議のことと思われるので、すくなくともこの日以降に作成されたものなのだろう。つまり、上で引用した4つの提案書が出された9月13日以降に作られ、そしてたぶんこの提案が討議されたコペンハーゲン会議の内容を踏まえていると考えられる。この小池資料により、この時点で国際の場に提案されていた、前述したn2095.pdfにある互換漢字以外の、“新漢字”の字体がわかるというわけだ。

 それでは、SC 2/WG 2/IRGは提案された新漢字のうち、どれを認め、どれを却下しているのか? これがわかるのがSC 2のサイトにある02n33937_extensionb_map.txtだ。これはマッピング・テーブルと呼ばれる形式のもので、各国から提案された文字のIDと、割り当てられている符号位置(むろん最終ではない)を対応させたもの。日本以外の提案も入っており、総容量が3.3MBという膨大なテキストファイルだ。欧数字がずらずらとならんでおり、意味不明もいいところ。それでも、これをじぃーーーーーと見ていると、やがて何を表しているのかおぼろげながらわかる。この、48~54桁目の“jcode”というのが、先の小池資料の“ID2”の欄の“JPN”から始まる番号と、そのまま対応しているのである! つまり、この“JPN”がふくまれる列だけを抽出して並べていけば、“IRGでExtension Bとして審議中の0213の新漢字”が判明するわけだ。ただし、このマッピング・テーブルそのものがいつの時点のものか判断がつかないのが残念なのだが、それでもここで取り上げられているJPN番号に漏れているものが、“IRGで却下された新漢字”ということになる。どうです、面白くなってきたでしょ?
 こうして、JPN番号をふくむ列だけを、こちらで切り出し、JPN番号を先頭に持ってきたのが0213xB_process_2.txtだ。これでだいぶ見やすくなったでしょうか。JPN番号以降が空欄になっているものは、先の02n33937_extensionb_map.txtになかったもの。全部で28文字ある。つまりはこれこそが問題の“IRGで却下された新漢字”なのでございます。

 この28文字がなぜ却下されたのかを、JPN番号と0213規格票案[*8]の字体を対応させ、これに既存のISO/IEC 10646とUnicode3.0の規格票と付け合わせることで推理し、考えられる理由別に分類して一覧表にしたのが、この先に説明する表1-a~1-eだ。しかし新漢字の受諾されたものの中にも検討すべき文字が2つほどあり、これを表にしたのが表2-a、2-bだ。

 字体や符号位置の表記は、規格票案や規格票そのものをスキャンして使用した。0213の符号位置欄の見方は“表あ”を参照してほしい。ISO/IEC 10646はそのJIS和訳規格であるJIS X 0221:1995の規格票をつかった。日本語の方が読みやすいでしょ? この欄で“C”、“J”、“K”は、それぞれ中国(C)、日本(J)、韓国(K)の各国の漢字の意味。字体の下の番号は各国の元になった規格の符号位置をあらわし、例えば日本のJ欄の場合、0で始まる4桁の数字は0208、1で始まる数字はJIS X 0212(補助漢字、以下0212)の区点位置だ。もちろん0221とISO/IEC 10646の字体や符号位置は同じ。
 それから、この規格が出た後で“補遺”として公開されているExtension A[*9]とCJK RADICALS SUPPLEMENT(CJK部首集合)[*10]については、SC 2/WG 2のサイトで公開されている最終案を参照することにする。ここではC、J、Kにくわえてベトナムの漢字“字喃(チュノム)”が“V欄”としてソースにくわえられている。
 また、Unicode3.0については、つい先頃出版された、出来たてのホヤホヤであるAddison Wesley刊『The Unicode Standard Version 3.0』を使用した。先週金曜日3月3日に航空便でとどいたばかりなので、読み込んでいないゆえの間違いがあるかもしれない。この“3.0本”には、ISO/IEC 10646ではまだ出版されていない補遺の部分[*11]が、正式に反映されているのだ。もちろんこれも一覧表に盛り込んである。

 この一覧表の最大の見所は、おそらく字体の細かい違いだろう。これが意外に違うのであります[*12]。それぞれの規格の“個性”とでもいうべきものを味わってほしい。

 

[*8]……私が入手した2000年1月9日付附属書6の規格票案は、平成フォントの最終検収後のものなので、ここで使われている字体は限りなく実際の規格票に近いと思われる。

[*9]……Extension Aの最終案のあるURLは以下のとおり。三分割されている。
http://www.cse.cuhk.edu.hk/~irg/irg/CJK_A305-355.pdf
http://www.cse.cuhk.edu.hk/~irg/irg/CJK_A356-400.pdf
http://www.cse.cuhk.edu.hk/~irg/irg/CJK_A401-442.pdf

[*10]……CJK RADICALS SUPPLEMENT(CJK部首集合)の最終案のあるURLは以下のとおり。
http://wwwold.dkuug.dk/JTC1/SC2/WG2/docs/n2122.pdf

[*11]……ISO/IEC 10646-1:1993の発行後に出された補遺(AMENDMENT)は、現在のところ私がタイトルで確認しただけでも31まである。どこまでを収録するのか分からないが、これらをまとめたのが今年中盤に出版される予定のISO/IEC 10646-1:2000、つまりISO/IEC 10646のパート1第2版である。これに対応するJISの和訳規格も現在原案を作成中。パート1はBMPの開発を目的としており、第01面以降はパート2、つまりISO/IEC 10646-2に収録される。もちろん0213の新漢字がはいるExtension Bもここだ。制定は来年2001年12月を予定している。

[*12]……じつは『The Unicode Standard Version 2.0』と比べるともっと違う。もっともVersion 2.1になってから2.0の訂正表( http://www.unicode.org/unicode/reports/tr8/ )を出しており、3.0はこれを反映させたという経緯のようだ。

 

●おそらく日本側の提案ミスと思われる文字(表1-a)

◎表1-a すでにExtension Aに入っていた文字(5文字)《日本側のミス》
http://internet.watch.impress.co.jp/www/column/ogata/special2/1a.htm

 これらについては、あまり問題はない。0213規格票案の〈UCS符号位置〉にはカッコつきのものはなく、0213とISO/IEC 10646、Unicode3.0の間で字体の差もほとんどない。つまり、これらは日本側がExtension A領域に同じ字体があるのに、チェックから漏れて提案してしまった文字と考えられる。小池資料の〈備考〉欄にも〈Extension Aにあり〉とか〈JCS提案からは削除済み〉の記述がみえる。なお、小池資料にはJPN169の〈備考〉に手書きで〈Extension Aにあり〉とあるが、これはおそらくよく似た字体のJPN171の間違いだろう。

 

●日本側の提案ミスか、もしや“戦い”をしかけて引っ込めた文字(表1-b)

◎表1-b すでにR領域(CJK互換漢字領域)に入っていた文字《日本側のミス?容認?》(9文字)
http://internet.watch.impress.co.jp/www/column/ogata/special2/1b.htm

 この表も、前の表1-aと同様に、一見問題がないように思える。0213規格票案の〈UCS符号位置〉にはカッコつきのものはなく、0213とISO/IEC 10646、Unicode3.0の間で字体の差もほとんどない。強いていえばJPN136、231、265に差が見られるが、あまり大きな問題とはいえない。ただし、これらの文字がR領域(互換漢字領域)におかれていることを考えると、ちょっとした妄想がふくらむ。つまり、日本側はこれらの文字がR領域にあることを知ってのうえで、I領域(CJK統合漢字領域)の方に収録するべく提案した。しかし無理なことをさとり、引っ込めた。つまりR領域に統合することで妥協した。そんな想像もありうる。すこし先走ってしまったが、これらの領域の詳しい説明は後述することにする。

 

●おそらく日本側が妥協したと思われる文字

◎表1-c すでにI領域(CJK統合漢字領域)に入っていた文字《日本側が統合容認》(6文字)
http://internet.watch.impress.co.jp/www/column/ogata/special2/1c.htm

 これらの文字のうち、JPN139、246、278、298は3つの規格のあいだで字体の差がなく問題はない。つまり、おそらく表1-aと同じく日本側の提案ミスではないか。ただし、このうち0213規格票案では“字体記述要素”としているJPN139、246が、I領域(CJK統合漢字領域)に入っていることを覚えておいてほしい。この表で問題にしたいのは残りの2つ。
 まずJPN075は0213の包摂規準では包摂されないはずだ。一方で0221を見る限りではISO/IEC 10646の包摂規準で包摂される(0221規格票、解説4.3.1.2 統合規則、(5)p.885を参照―表ア )。つまり、ここでは日本側はISO/IEC 10646の包摂規準を尊重している。このことは、つぎの表1-dをみると、意味をもってくるはずだ。
 次にJPN200。これは0213規格票案をみても明確に包摂される例を見つけられなかった。包摂されるような包摂されないようなという感じだ(なんか素人臭いことを書いているなぁ)。一方でISO/IEC 10646で包摂の例は見いだせない。

 

●日本側が“戦い”を挑んだと思われる文字

◎表1-D 却下されたのに0213規格票でUCS符号位置が括弧になっている文字《日本側が統合拒否》(7文字)
http://internet.watch.impress.co.jp/www/column/ogata/special2/1d.htm

 この表にしめされた文字が本稿のヤマであり、じつのところ、この原稿はこれらの文字の意味を読者の皆さんと考えるために書かれたといってもいい。まず表中0213符号位置の右下、UCS符号位置をご覧いただきたい。いずれもカッコで括られている。これは、これらの文字がUnicode(ISO/IEC 10646)に収録されていないことをしめしている。一方で前述したExtension Bのマッピング・テーブルから、これらのJPN番号を検索していってもヒットしない。つまりこれらの文字は、0213では“Unicode(ISO/IEC 10646)に収録されていない”としているのに、Unicode(ISO/IEC 10646)では“審議の対象にしていない”文字なのだ。

 審議しない理由はふたつ考えられる。ひとつは“将来審議する”というもの。ところが現在審議中のExtension Bの次の漢字拡張予定であるExtension Cは、まだスケジュールもたってない段階であり、もしここにはいるとなれば0213の文字がすべてUnicode(ISO/IEC 10646)に収録されるのは、はてしなく遠い未来になってしまう。
 もうひとつ考えられる審議しない理由は“従来ある文字に統合されている=収録ずみ”というもの。実際はこれが一番可能性があり、また厄介なものなのだ。もしそうなれば当然収録そのものが望めないことになってしまう。
 これがどんな問題を引き起こすかは後述するとして、まずはUnicode(ISO/IEC 10646)の“統合”とは何かを説明しよう。本来のUnicodeの理想こそは“統合”にこそあるといっていいのだ。これは同じスクリプト[*13]に属する文字は、一定のルールの元に統合(unify)して整理しようということ。東アジア諸国で使われている漢字というスクリプトは、“CJK Unified Ideographs”(CJK統合漢字)という領域で、中国(C)、日本(J)、韓国(K)の3つの言葉の間で統合し、しかし各国の字体は併記した形で収録する(これはISO/IEC 10646だけで、Unicode3.0では併記されていない)。スクリプトという考え方の元で文字を統合・整理することで、各国の間で文字が共有され、そしてこれはあくまでも結果論だが、収録される文字数は減少する。

 

[*13]……スクリプト(用字)とは、JIS X 0221:1995規格票の『4.1定義』によれば「一つ以上の言語の表記の方法で、使用する図形文字の集合」となる。図形文字とは制御文字以外の目で読める文字だから、つまりある言語の書き言葉のことなのかと思われるかもしれないが、これが間違い。たとえば英語、ドイツ語、フランス語など、ヨーロッパやアメリカ英語のアルファベット(ラテン文字という)をつかう言語は、すべて“ラテン・スクリプト”に属する。これらは表記する文字の集合が共通のラテン文字をつかうからだ。もちろん各言語でちがった発音区別符号(ダイヤクリティカル・マーク)をつかうが、基本になる文字は同じだ。
 反対に日本語では漢字、ひらがな、カタカナ、ローマ字という4つの異なるスクリプトをつかって表記する。そして、日本、中国、韓国などで使われる漢字は共通のスクリプトだ。
 つまり、言語とスクリプトは違う概念に属する。“言語”は話し言葉を中心にしたひとつの体系、まとまりだ。しかし“スクリプト”は記述する文字だけに注目した体系だ。ひとつの言語が複数のスクリプトをもつ場合もあるし、多数の言語がひとつのスクリプトを共有する場合もある(こちらの方が多い)。(第2回原稿補注2を再掲)

 

 一方で、この理想主義とは別に、現実主義的な原則も存在する。それは各国の現実を尊重し、そこでの実装をすすめるために、Unicode(ISO/IEC 10646)は各国規格のスーパーセットでなければならない、という原則だ。具体的に漢字スクリプトを例にとれば“異体字”の問題がこれに直面することになる。たとえば0208、日本のJIS漢字コードでは多くの異体字をふくんでいる。鷆と鷏、爭と争、將と将、惠と恵、曾と曽……。戦後の当用漢字による字体整理(新字体と旧字体)だけでなく、異体字には中国から入ってきた時期による違い、昔から使われてきた簡略体、ほぼ地名や人名にしか使われないちょっとだけ違うものなどさまざまな種類があるが、そういう多くの異体字が0208にはひしめいている。
 これらの異体字をすべて統合してしまっては、各国規格のスーパーセットにはならない。そこで基本的にUnicode(ISO/IEC 10646)では、元になった各国規格を尊重して、そのまま収録している。これが原規格分離の原則、ソース・レパレーション・ルールだ(JIS X 0221規格票の解説4.3.1.1にある“原規格分離漢字の取扱い規程”を参照)。こうしてすべての0208や0212の異体字はI領域(CJK統合漢字領域)に収録されている。
 この原規格分離の原則がきわめて重要なのは、これがあるおかげで、Unicode(ISO/IEC 10646)と各国の規格の間で変換が可能になることだ。つまり0208の文字をいったんUnicode(ISO/IEC 10646)に変換して、さらにまた0208に変換し直しても、符号位置は変わらない。これを“ラウンド・トリップ・コンバージョンの確保”という。現状のようにUnicodeに対応したOSであるWindowsOSやMacOSで、シフトJISアプリケーションを使用する場合、これが確保されないと、実質的に文字は情報交換できなくなってしまう。わかるだろうか? ラウンド・トリップ・コンバージョンが確保されないシステムでは、文字化け――よく似た別の字に変わったり、〓とか??などの意味不明の文字になってしまうのだ。
 このようにして理想主義と現実主義の折衷、もしくは同居がUnicode(ISO/IEC 10646)をつらぬくものではあるだが、ちなみに、この“例外規定”ともいえるのが、先の表1-bにあるR領域(互換漢字領域)だ。これは従来の各国規格や有力メーカーが実装していた外字を収録する、繰り返すが“例外領域”だ。したがって統合(包摂)は存在せず、欄の表記のしかたも各国規格を併記はしていない。

 一方、現在のUnicode(ISO/IEC 10646)の風向きはどうなっているのだろうか?  なんと http://wwwold.dkuug.dk/JTC1/SC2/WG2/docs/n2005/n2005.pdf ('99年5月29日付)の“Annex R”を読むと、これからは原規格分離の原則を撤廃し、規格としての整合性を高めるために統合をより進めていこうという方向がしめされているのだ。この表中の文字がすべて統合の対象になsっているとすると……当然Unicode(ISO/IEC 10646)と0213との間でラウンド・トリップ・コンバージョンは確保されなくなり、0213とUnicodeの情報交換はできなくなる。それに対して敢然と(?)カッコでくくって、この文字はまだ提案中であると高らかに宣言することで、いわば日本側が“戦い”を挑んでいるともとれるのが、この表の文字なのである。

 特に“RADICALS SUPPLEMENT”の領域によく似た字体があるJPN215、216、263をみると、妄想はさらにふくらむ。0208でも0213でもRADICALS、つまり部首は“字体記述要素”として収録されている。しかし0208と0213においてこれらの部首は、他の文字と重複して収録されてはいない。例えば“鬼”という字は“オニ”という字であると同時に、字体記述要素としての“鬼”でもある。それが0208、0213での考え方だ。また、0208、0213では、字体記述要素は他の読みをともなう文字と混在して収録されている。しかし、Unicode(ISO/IEC 10646)の“RADICALS SUPPLEMENT”は違う。ここでは読みをともなう文字とはまったく別の領域に、しかもI領域との重複符号化はあえて避けずに、どんどん部首を収録して、“RADICALS SUPPLEMENT”の中で完全な部首集合を作ることを目指しているように思える。
 つまり、ここでは日本側はUnicode(ISO/IEC 10646)の規準とは違う日本側――というよりはむしろJCS委員会の“俺の規準”を貫徹するために、あえて“RADICALS SUPPLEMENT”を無視してI領域に提案したのではないか。その傍証として、前述した表1-cのJPN139、246が、I領域(CJK統合漢字領域)に入っていることを思い出してほしい。これらの字体記述要素として0213に収録されている文字は、もしかしたら“RADICALS SUPPLEMENT”に収録されてもいい、という考え方も充分成り立つ。しかしこれらはI領域にはいっている。日本側としては、これは“OK”なのだ……とは考えられないだろうか?

 それはともかく、もし統合されるになると“ラウンド・トリップ・コンバージョンの確保”という意味で問題になるのは、JPN095、138、196、283の3文字ということになる。頑張れニッポン!

 もっともこれら0213の文字と、以前からの0208や0212との間で区別する必要がない、別にこれからはUnicode(ISO/IEC 10646)だけ使えればいいじゃない、国内規格なんて別にカンケイないよ~ん、と言われればそれまでなのだ。すくなくとも上から下まで完全にUnicode(ISO/IEC 10646)で一貫したシステムならば、ラウンド・トリップ・コンバージョン問題など起こり得ない(通信は無理だろうが)。ただし、そうなると日本ってモノはどうなるの? 私たちが使う字はいったい誰が決めるの? そういうことなのだ。0213が制定の際に公開レビューという形で広く意見を募集し、それを反映させて作られたことを、もう一度思い出してほしい。

 

●IRG側のミスではないかと考えられる文字

◎表1-e 理由不明の文字《IRGのミス?》(1文字)
http://internet.watch.impress.co.jp/www/column/ogata/special2/1e.htm

 このJPN092については、たしかにマッピング・テーブルには見つからないのだが、小池資料にはExtension Bとの対応(符号位置は2-34F5)がしめされており、IRGのサイトで公開されているExtension Bの最新版コード・テーブルN686(字体と符号位置が記載されている)で確認しても、2-34F5の符号位置に収録されている。おそらくこれはマッピング・テーブルの方の単純なミス、マップし忘れであると思われる。

 

●IRGも日本側も両方間違えたと思われる文字

◎表-a Extension Bに入っているのに0213にはない文字《双方のミス?》(1文字)
http://internet.watch.impress.co.jp/www/column/ogata/special2/2a.htm

 この文字は0213規格票案に見あたらない。にもかかわらずマッピング・テーブルでは JPN073(つまり0213を出典とする新漢字)として記載されている。可能性として考えられるのは、この文字は0213の最終案以前のギリギリの段階で落とされた文字なのだが、落とす前に国際に提案してしまっていた。そうしてこの文字が、マッピング・テーブルに“審議中”として残ってしまった。あるいは、最終段階で落としたはずの文字をうっかり提案してしまった。そして日本側が間違いに気づいて取り下げたのに、IRGの側が削除し忘れていた。こんなところではないだろうか? 実際小池資料にも〈JCS提案からは削除済みだが、日本単独ソースとして残っている〉とある。しかし〈日本単独ソースとして〉の部分に鉛筆らしい棒線で消してあるが……。ちなみに前述の最新版Extension Bコード・テーブルN686では残っている。いやはや、皆さん意外に間違うものなのですね。毎回訂正を山のように出している私としては、人のことは言えません。

◎表2-b Extension Bに入っているが、R領域にも入っている文字《双方のミス》(1文字)
http://internet.watch.impress.co.jp/www/column/ogata/special2/2b.htm

 このJPN053と同じ文字は、じつは同時にR領域(互換漢字領域)に提案されている(先にあげたn2095.pdfの提案書を参照)。つまり、うっかりI領域(CJK統合漢字領域)とR領域の両方に重複して提案してしまったということではないか。
 まず表にあるようにI領域(CJK統合漢字領域)のC-G欄に、すでによく似た字体が収録されている。一方でC-T欄とJ欄ではJPN053と違う字体がある。
 J欄は0208の文字であり、もちろん日本側としてはこの0208に収録されている文字と0213のJPN053は別の字だという立場だ。そこで本来の漢字領域であるI領域に提案したいのだが、困ったことにC-G欄に0208で入れた字体がすでに併記されている。そこでやむなくR領域に提案することにした。ところがうっかりI領域の方の提案書から消し忘れてしまった。というような経緯が思い浮かぶが、どうだろう?

 

●マッチ・ポンプのお詫び:現在これらの文字はどうなっているのか?

 皆さん、すみません。実はざんざんラウンド・トリップ・コンバージョンの確保だとかなんとか危機感を煽ってまいりましたが、わたくしはこれらの文字がどうなっているのか、現時点で知っているんです。たぶん大丈夫。ラウンド・トリップ・コンバージョンは確保されるでしょう。もちろん最初に前述したように、現在審議中の規格の話だから、これから先どうなるか分からないのも確か。でも確実に0213の文字がUnicode(ISO/IEC 10646)でも使えるように物事は動いているようです。
 というのも、JSC2のメンバーとしてIRGの審議に参加している日本側代表のひとり、小林龍生さんに、これらの文字がどうなっているのか質問のメールを送り、この原稿の執筆中に返事がかえってきたのであります。それを見ると心配はいらないということは分かったのですが、週刊連載の悲しさで、今さら原稿を書き直すわけにもいかず、ここまで引っ張ってまいりました。表題の『ISO/IEC 10646で却下された(?)JIS X 0213の新漢字一覧表』に気弱な“(?)”が入っているのは、そういうわけです。

 以下、小林さんの返事をまとめます。表を見ながら読んでください。

◎表1-cの文字
http://internet.watch.impress.co.jp/www/column/ogata/special2/1c.htm

・JPN075→ISO/IEC 10646では、明確にUnificationの対象となります。
・JPN200→IRGでの議論で、Unifyされました。
・JPN246→現状ではUnifyです。

◎表1-dの文字
http://internet.watch.impress.co.jp/www/column/ogata/special2/1d.htm

・JPN095→Extension Bに押し込みました。現在のドラフトには含まれています。
・JPN138→互換漢字領域へ
・JPN196→互換漢字領域へ
・JPN215→互換漢字領域へ
・JPN216→互換漢字領域へ
・JPN263→互換漢字領域へ
・JPN283→いまだにもめています。

◎表1-eの文字
http://internet.watch.impress.co.jp/www/column/ogata/special2/1e.htm

JPN092→質問の意味が分かりません。現状では、Plane2の34F5にマッピングされています。

◎表2-aの文字
http://internet.watch.impress.co.jp/www/column/ogata/special2/2a.htm

JPN073→ご指摘の通りです。Extension Bの最終ドラフトからは、落としました。

◎表2-bの文字
http://internet.watch.impress.co.jp/www/column/ogata/special2/1b.htm

JPN053→現在、Extension Bに康煕字典典拠で片割れが残っています。日本の提案からは、削除してあります。

 

●最後に感謝

 実は、ここまで読んで「小形はすごいなあ、こんなに英語の資料やページを駆使して、いやぁ見直した」と思われてはいけないので、ここで内情を暴露します。今回の原稿は、文字コードの博覧強記をもって知られる直井靖氏の強力な支援のもとに初めて成立したものです。私は彼のしめてくれた資料を必死になって咀嚼して、自分の言葉にしていっただけ。もちろん筆者は私だから、この原稿は私の理解した範囲で書いているし、原稿に間違いがあれば私がその責任をおう。でも、今回の原稿は彼なくしてはできなかった。このことを明記してお礼をいうとともに、これからもどうぞよろしくと頭をさげたい。ペコリ。

 

●蛇足情報

 これが本当に最後です、すいません。3月18、19日に大阪でとても面白そうなイベントが開かれます。『第3回XML開発者の日』。XMLを知らずとも、文字コードが気になる向きには、18日夜の「夜間セッション(1)」と19日朝10時からのセッションは必見でしょう。詳しくはウェブを参照してください。僕も行きたいけど……どうなるかなあ。でも行きたいなあ( http://www.xml.gr.jp/xmldevday3.html )。

[Reported by 小形克宏]

INTERNET Watchホームページ

INTERNET Watch編集部internet-watch-info@impress.co.jp
Copyright (c) 2002 Impress Corporation All rights reserved.