“情報化時代”に追いつけるか？　審議が進む「新常用漢字表（仮）」：第2部新常用漢字表と文字コード規格第5回なぜUnicode正規化は生まれたか

記事検索

バックナンバー

【 2009/04/09 】

■	「新常用漢字表（仮称）」のパブコメ募集が始まった［12:59］

【 2008/11/28 】

■	第3部印刷文字から符号化文字へ第11回「情報化時代」へ常用漢字表を進化させよ［11:19］

【 2008/11/27 】

■	第3部印刷文字から符号化文字へ第10回ふたたび常用漢字表の改定を考える［14:31］

【 2008/11/14 】

■	第3部印刷文字から符号化文字へ第9回議員の氏名表記とRFC標準の共通点［11:12］

【 2008/11/13 】

■	第3部印刷文字から符号化文字へ第8回字体意識と社会的コスト［11:27］

【 2008/11/12 】

■	第3部印刷文字から符号化文字へ第7回『議員氏名の正確な表記』と人名表記の位相文字［14:06］

【 2008/11/11 】

■	第3部印刷文字から符号化文字へ第6回漢字の字体史から見た『議員氏名の正確な表記』［17:08］

【 2008/10/31 】

■	第3部印刷文字から符号化文字へ第5回『議員氏名の正確な表記』はどうやって作られたか［11:21］

【 2008/10/30 】

■	第3部印刷文字から符号化文字へ第4回議員本人のWebページとの比較結果［15:03］

【 2008/10/29 】

■	第3部印刷文字から符号化文字へ第3回実装の上から『議員氏名の正確な表記』を考える［15:15］

【 2008/10/28 】

■	第3部印刷文字から符号化文字へ第2回規格の上から『議員氏名の正確な表記』を考える［11:08］

【 2008/10/27 】

■	第3部印刷文字から符号化文字へ第1回現代日本の「ゴルディアスの結び目」をほどくのは？［16:44］

“情報化時代”に追いつけるか？　
審議が進む「新常用漢字表（仮）」

第2部新常用漢字表と文字コード規格
第5回なぜUnicode正規化は生まれたか

● 互換用文字は、存在するはずのなかった文字

　前回までは互換漢字が追加提案しにくくなっている現状について述べた。規格の上から互換用文字／互換漢字といった文字がどのように考えられているかは、次のUnicode規格書の一文に明らかだ。

Conceptually, compatibility characters are those that would not have been encoded except for compatibility and round-trip convertibility with other standards.（概念上からは、互換用文字とは他の規格との互換性及び往復の保全性の目的以外には、符号化されるはずのなかった文字である。）
『Unicode Standard 5.0』2.3 Compatibility Characters（http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf#G11062）

　「本来は存在するはずがなかった文字」、それが互換用文字だ。そうした危うい文字に対し、日本は人名用漢字という政令に根拠を持つ文字の一部を対応させているのが現状だ。この先、常用漢字表に追加される字体が新字体だった場合、文字によっては第2部第1回／第2回で説明したような漢字政策の玉突き現象が発生、JIS X 0213を包摂分離し、これを互換漢字としてUCSに追加提案しなければならなくなる可能性がある。では政令文字の符号化を互換漢字に依存し続けた場合にどのような不都合が生じるのか、今回はそれを考えていきたい。

　互換漢字を使用する上で、最も障害になるのは、Unicode正規化（Unicode Normalization。または単にNormalizationとも）を適用すると必ず対応するCJK統合漢字に置き換わってしまうことだ。後述するさまざまな制限も、すべてこのUnicode正規化に起因して発生する。

　Unicode正規化については、2004年に本誌連載『文字の海、ビットの舟』で2回にわたって述べたことがある[*1]。発表当時いくつか好意的な反応をいただいたが、読み返すと内容の古さと多くの間違いに気付かされることになった[*2]。そこでなるべく多くの人にわかるよう、あらためて説明し直したいと思うが、限られた紙数ではすべてを書くことは難しい。より正確には原典である『Unicode Standard Annex #15 Unicode Normalization Forms』（UAX#15）や注釈に示したWebページ等を参照していただきたい[*3]。

● 2種類の「発音記号付きラテン文字」を符号化する方法

　1987年の秋、カルフォルニアのシリコンバレーで3人のソフトウェア技術者がミーティングを行った。Xeroxのジョー・ベッカー、リー・コリンズ、そしてApple Computer（当時）のマーク・デイビス。ベッカーとコリンズは1981年に発売されたワークステーション『スター』に搭載され、最も早い多言語文字コードとされている「XCCS」（Xerox Character Code Set）を開発していたし、デイビスは札幌に滞在してMacintoshの日本語版OS『漢字Talk V1.0』を開発した経験があった[*4]。彼等はこのミーティングで世界中の言語を取り扱う単一の文字コードが必要であることに合意、協力してその開発を進めることになった。その年の12月、ベッカーによってこの文字コードは、unique（唯一の）、universal（普遍的な）、uniform（不変の）から「Unicode」と命名される。翌1988年9月まで、最初期のUnicodeは次のような特徴を持つようになっていた[*5]。

16ビット固定長（2進数で16桁、最大文字数6万5536文字）で世界中の文字が符号化可能[*6]
ASCII（ISO 646）と上位互換で、容易に変換可能[*7]
日中韓の漢字を統合したCJK統合漢字[*8]
合成ずみ文字を排除し、合成列により符号化する[*9]

　このうち最後の「合成ずみ文字」と「合成列」が今回のテーマとなる技術だ。これは主にヨーロッパ諸語に見られる発音記号付きラテン文字を符号化するための方式のことなのだが、詳しいことはすぐ後で説明するとして、今はもう少し文字コードの歴史をたどってみよう。

● 誕生間もないUnicodeが選んだ「妥協」

　この頃、文字コード標準化の世界は昏迷していた。1984年に国際的な文字コード審議機関であるISO/TC97/SC2[*10]において、漢字を含む各国語を統一して符号化できる16ビット文字コードの枠組みを開発することが合意され、作業部会として今に続くWG2が発足する。その後1987年3月に最初の原案を可決したのはよいが、3つの国内規格により漢字2万1000字以上をすでに符号化していた中国が、16ビットの範囲ではそれらすべてが収容できないことによりこの原案に強く反対していた。そこでSC2は枠組みを32ビットに拡張することに方針変更、その原案を作成し直していた[*11]。これが後にUCSと呼ばれるものにつながる。

　このような状況の中でUnicodeは産声を上げることになった。多国籍IT企業とは言え、それまで国際標準化活動とは無縁なソフトウェア技術者の私案だったUnicodeは、この後IBMやMicrosoftなど急速にメンバーを拡大、Unicodeコンソーシアムとして団体の形を整えていく。1991年1月にはUnicode社としてカルフォルニア州に法人登記される（社長はマーク・デイビス）。

　やがてアメリカの代表機関L2の支持を獲得するまでになり[*12]、彼等が主張するCJK統合漢字と同じようなアイデア「Han Character Collection」を打ち出した中国と連繋しながら[*13]、1991年8月にジュネーブで開催されたWG2において、ついにUCSの一部をUnicodeが乗っ取るような形での一本化が承認される（詳細は第2部第3回の注釈1を参照）。そして1993年にISO/IEC 10646-1として制定されたのである。しかし、こうして激しい競争に勝ち残るまでには（そして勝ち残った後も）、Unicodeは当初の構想と矛盾する無数の妥協を続けなければならなかった。

　そうした妥協の中でも最初の、そして後々まで大きな影響を残したものが、1990年3月に合成ずみ文字も収録するよう方針を変更したことだ[*14]。最初期のUnicodeが合成列方式を採用していたことはすでに述べた。これが彼等なりの信念から採用されたことは明らかだ。ところがヨーロッパ各国の言語を符号化する有力な規格、ラテン1として知られるISO 8859-1（1987年制定）は合成ずみ文字方式を採用していた（図1）。この規格はイギリス英語、ドイツ語、フランス語など25の言語を符号化可能にしており、すでに実装実績があった。この状況の中で、UicodeはISO 8859-1と互換性を確保しなければ生き残ることは難しいと思われたのである。

図1　ISO/IEC 8859-1の文字表。右半分を見ると発音記号付きの文字は合成ずみの形で収録されていることがわかる。この部分がUnicodeとの互換性でネックになった（『ISO/IEC 8859-1:1998』ANSI、1999年、P.5）

　ここで合成ずみ文字（precomposed character）と合成列（composite sequence）について説明しよう。前者はあらかじめ発音記号と合成した形を規格に収録して使う方法だ。一方、後者は専用の結合文字（combining character）を組み合わせて表現する（図2）。

図2　発音記号付きのラテン文字を表現する2つの方法／合成ずみ文字と合成列

　合成ずみ文字は何といっても実装が容易というメリットがある。1つの符号位置を1文字として扱えばよいから、見た目から簡単に文字列のバイト数（記憶容量）を割り出すことができる。いささか退屈だが手堅く現実的な方式だ。反面で必要な文字の形だけ符号位置を用意しなければならないという無視できないデメリットがある。

　一方、合成列は2つ以上の符号を1つの文字として扱うことになり実装が難しい。文字の形に合わせて微妙に発音記号の位置を調整しないといけないし、複数の符号位置が並んでいるもかかわらず、単一の文字と同様にカーソルの移動、削除、行末処理などをしなければならない。もちろん見た目からバイト数は割り出せない。反面で合成ずみ文字より収録文字数が抑えられ、いったん実装してしまえば既収録の符号と組み合わせて使える文字を増やせたりと、融通がききやすいメリットがある。いかにも気鋭のエンジニアが好みそうなチャレンジングな方式なのである。

　大事なのはどちらの方式にもメリットとデメリットがあることだ。最近のBlu-ray Disc規格とHD DVD規格の対立を思い出させるような話だが、それと違うのはUCSとの一本化に成功する前のUnicodeにとって、すでに実装実績のあるISO 8859-1に対し往復の保全性を保証すれば、ヨーロッパ各国にも支持を広げることが期待できたということだ[*15]。こうしてUnicodeには当初からの合成列用の結合文字に加え、合成ずみ文字を収録することにしたのである。

　ではこの変更が、後にどのような影響を与えることになったのか、それは次回考えることにしよう。

[*1]……『文字の海、ビットの舟』「特別編24　番外編：改正JIS X 0213とUnicodeの等価属性／正規化について（上）」および『文字の海、ビットの舟』「特別編25　番外編：改正JIS X 0213とUnicodeの等価属性／正規化について（下）」

[*2]……http://internet.watch.impress.co.jp/www/column/ogata/sp24.htm#t1。他にも訂正したい箇所は多くあるが、それをすると一からの書き直しになってしまうので、申し訳ないが大きな事実誤認以外はそのままにさせていただく。

[*3]……『Unicode Standard Annex #15 Unicode Normalization Forms』（http://www.unicode.org/reports/tr15/）。他に日本語の情報としては、貞廣知行氏の『使いこなそうユニコード』にある『Unicode正規化とは』（http://homepage1.nifty.com/nomenclator/unicode/normalization.htm）が有用だ。貞廣氏はUAX#15の末尾に書かれた協力者の1人としてお名前が見えるところからも、このページは信頼が置けるものと思える。この原稿でも参照させていただいた。またUnicodeのWebサイトにある『Normalization Charts』（http://www.unicode.org/charts/normalization/）では、Unicode正規化の結果を見て確かめることができる。

[*4]……漢字Talk V1.0については『The Vintage Mac Museum』（http://www.d4.dion.ne.jp/~motohiko/kanjitalk1.htm）を参照。なお、現在もマーク・デイビスは非営利法人としてのUnicode社のプレジデントであり、社員としてはGoogleに在籍している。

[*5]……最初期のUnicodeに関しては彼等自身の編集による以下のWebページを参照。『Ten Years of Unicode 1988 - 1998』（http://www.unicode.org/history/tenyears.html）、『Chronology of Unicode Version 1.0』（http://www.unicode.org/history/versionone.html）、『Summary Narrative』（http://www.unicode.org/history/summary.html）、『Previous Unicode Officers and Staff』（http://www.unicode.org/history/previousofficers.html）

[*6]……『Unicode 88』P.2（http://unicode.org/history/unicode88.pdf）

[*7]……前出『Unicode 88』P.5

[*8]……前出『Unicode 88』P.3

[*9]……前出『Ten Years of Unicode 1988 - 1998』「September 1988」。なお、結合文字を使って合成する方式は1969年の連邦議会図書館（アメリカ）による8ビット文字コード規格、USMARCに始まる。これを情報処理分野に取り入れて国際規格化したものがISO 6937だ。ただしこれらにおける合成方式は発音記号を先行させ、次に合成対象の文字（これを基底文字という）を並べる方式だ。これには複数の発音記号を合成できず、ギリシア語やベトナム語の一部が符号化できないという欠点があった。Unicodeでは逆に基底文字の方を先行させるが、これはUSMARC/ISO 6957を踏まえたものと思われる（『文字符号の歴史　アジア編』三上喜貴、2002年、P.116～119、共立出版）。

[*10]……1987年11月に、情報処理を管轄するISOと通信を管轄するIECが合同し、JTC 1（Joint Technical Committee 1）となる改組があり、文字コードを管轄するSC2はこの下に置かれるようになった。つまりISO/IEC JTC1/SC2である。

[*11]……『文字符号の歴史　欧米と日本編』安岡孝一・安岡素子、2006年、P.184～198、共立出版

[*12]……それどころか、やがてL2はUnicodeが乗っ取ってしまうことになる。現在L2の委員は全員がUnicode技術委員会（UTC）の委員を兼任し、事実上一体化している。さらに言うとWG2の委員長と事務局もL2、つまりUTCが担当している。

[*13]……前出『文字符号の歴史　欧米と日本編』P.199

[*14]……前出『Chronology of Unicode Version 1.0』「March 1990」

[*15]……Unicode以前に合成列をサポートした文字コードといえば、1983年にテレテックス向けに作られたISO 6937だが、UnicodeはISO 8859-1と同時に、これに対しても往復の保全性を保証しているとしている（Chronology of Unicode Version 1.0）。もっとも、ISO 6937による合成列は発音記号を先行させる方式であり、Unicodeとは符号の順序が逆になる。この項、注釈9も参照（前掲『文字符号の歴史　アジア編』P.128）。

2008/09/03 13:02

小形克宏（おがたかつひろ）
文字とコンピュータのフリーライター。本紙連載「文字の海、ビットの舟」で文字の世界に漕ぎ出してから早くも8年あまり。知るほどに「海」の広さ深さに打ちのめされています。文字ブログ「もじのなまえ」ときどき更新中。

- ページの先頭へ-

INTERNET Watch ホームページ