“情報化時代”に追いつけるか？　審議が進む「新常用漢字表（仮）」：第2部新常用漢字表と文字コード規格第7回 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部新常用漢字表と文字コード規格
第7回 Unicode正規化と互換漢字

● “情報化時代”の新しい文字

　前回は符号位置の並びが違っても「全く同じ」字である「正規等価」、それから符号位置の並びが違い、正規等価ほど「同じ」とはできないが、「基本的な意味は同じ」で見た目もあまり変わらない「互換等価」、そしてこれらに基づいて重複を排除するUnicode正規化について述べた。

　例えば、文字コードのことを活字棚に喩え、棚に並べられている活字に1つずつ番号を振ったようなもの……とするような説明を耳にしたことがないだろうか。しかし現在私たちが使っているコンピュータに実装されたUnicodeは、すでにそうした牧歌的な喩えでは正確に理解することはできない。見た目だけを比べると「全く同じ字」でも、背後に振られた番号からは「違う字」という場合があるのだし、そもそも1個の「番号」が必ず1文字に振られているとは限らない。つまり画面に映し出されたり紙に印刷された文字の「形」だけに囚われていると理解を誤ってしまう。Unicodeを見ていると、これは従来と全く枠組みが違う“情報化時代”の新しい文字であるように思える。

　ここで思い出してほしいのが互換漢字だ。これらはUnicodeの統合規則から言うと本来は収録されるはずがなかったが、さまざまな事情により既収録の統合漢字と区別する必要があって収録された文字だ。一方で、互換等価とされている文字たちも、やはり見た目は少ししか違わないが何かしら区別する必要があって収録された文字であるはずだ。ということは互換漢字は当然「互換等価」でなければならないことになる。では実際にUnicode規格書で互換漢字の属性を確かめてみよう（図1）。

図1　Unicode規格書の文字表のリストでのJIS X 0213互換漢字（FA30～FA33）の表示。正規等価として統合漢字が対応付けられている（http://www.unicode.org/charts/PDF/UF900.pdf、P.510）

● パンドラの箱を開けてしまったJIS

　「完全な一致」を示す論理記号で対応付けられていることからわかるとおり、互換漢字は正規等価に指定されている。そしてUnicodeでは単一文字が正規等価として単一文字に対応付けられている場合は、どのタイプのUnicode正規化を行っても対応する文字に置き換わると規定されている（これをSingleton Decomposition／単一文字への分解と呼ぶ）[*1]。こうして互換漢字はUnicode正規化を行った途端、強制的に対応する統合漢字に置き換わってしまうことになるのである。

　残念ながらこの互換漢字の正規等価の属性は、将来も修正されないと思われる。すでにUnicode正規化の実装は普及し始めており、それらの実装との互換性を保証するためにも変更はできないからだ。これはUnicodeでは『Unicode Character Encoding Stability Policy』（Unicode符号化における安定化の指針）の中で、「Normalization Stability」として明確に規定されている[*2]。

　まるで狐につままれたような話だ。図1のJIS X 0213の文字はいずれも人名用漢字、つまり日本の政令に根拠を持つ漢字だ。それがUnicode正規化を行うことで、字種は同じとはいえ別の字体に置き換わってしまう。日本人としては非常に困るし、何とか修正できないかと思ってしまう。実際にJIS X 0213の互換漢字がUCSで審議中の段階から、この問題を予見して互換漢字の属性を互換等価に変更するようUnicodeに働きかける動きが日本人を中心にあったのだが、残念ながら結果として修正されないままに終わってしまった。

　こう書くとUnicodeばかりが悪いようだが、彼らの側にも同情すべき点はある。Unicode正規化を定めたUAX#15が制定された1999年は、互換漢字の性格が明確化される議論がちょうど始まったころだった。というより、UCSが初めて互換漢字の厄介さに気付いた時期と言えるかもしれない。このころの議論の中で既存の互換漢字と対応する統合漢字について洗い直しが行われ、その結果、対応するものがない互換漢字については、統合漢字と見なすことが決定された[*3]。

　第3回で述べたような「互換漢字は特定の規格との互換性確保だけに使われるもの」という位置付けも、この時の議論によって明確化されたものだ。実際にこの条項はUCS（ISO/IEC 10646）の2000年版にはなく、2003年版で初めて付け加えられている[*4]。こうした議論が定まらないうちにUAX#15は制定された。そのころのUnicodeにとっては、互換漢字が正規等価だろうが互換等価だろうが大差はないと思われていたのではないか[*5]。

　ということは、そうした互換漢字に政令文字を割り当てたJIS X 0213が犯人なのだろうか？　もちろん違う。そもそも法務省がこれらの字を人名用漢字（当時は人名用漢字許容字体）に指定しなければ、JIS X 0213は互換漢字に割り当てなかったはずだからだ。では法務省が犯人？　違う、法務省が悪いわけではない……とまだまだ先は続く。このことが何を意味するか第3部で考えることにして、今は先を急ごう。

● 互換漢字を置き換えてしまうDTPソフト

　では、こうした互換漢字の置き換えが、私たちにとってどのような影響があるのだろう。それを考える上で注意すべきは、Unicode正規化の本来の目的は文字や文字列同士が同じかどうかという「照合」であり、したがって必ずしもユーザーが目にする画面表示や印刷にまで及ぶ必要はないということだ。例えばMac OS X付属のテキストエディットでは、検索にUnicode正規化を取り入れていることで知られている（図2）。

図2　テキストエディットにおいて「祝」とこれに対応する示偏の異体字を入力したファイルを作成、これに対して「祝」で検索をかけた。異体字の方にもヒットしていることがわかる。ここでは「祝」と示偏の異体字が同一視されていることになる。一方でウィンドウのタイトルバーを見るとわかるとおり、ファイル名としては両方の字が区別されており、ファイルシステムHFS Plusにおいては互換漢字は同一視されていないことがわかる[*6]

　ここでは、検索の処理過程においてメモリ上にファイルを書き出してUnicode正規化を施し、これに対して検索を行うことで、画面上では置き換えた結果そのものは目に入らないようにしていると思われる。このようにUnicode正規化は、Unicodeによる文字列の照合が必要となる操作全般で必要とされている。検索、置換、整列、そしてファイルをHDDなどに収納するファイル管理システムなどでも実装されている。しかしUnicode正規化が図2のように「裏方」に徹している限り、いくらこれを規定したUAX#15の規定上では互換漢字が必ず置き換わると言っても、ユーザーが編集しているファイルの中身にまで影響を及ぼすことはない。

　しかし、そのようなアプリケーションばかりとは限らないのが現実だ。例えばDTPソフトで大きなシェアを持つアドビシステムズのInDesign CS3を見てみよう。直井靖氏が自らのブログで報告したところによれば、Mac OS X版のInDesign CS3に一定の条件下で互換漢字をペーストすると、対応する統合漢字に置き換わってしまう。

図3　『Mac OS Xの文字コード問題に関するメモ』2008年5月28日付エントリ「InDesign CS3にCJK互換漢字をペーストしたときの文字化け」（http://d.hatena.ne.jp/NAOI/20080528/）

　直井氏がこの日のエントリで書くように、文字の形が業務に直結するプロフェッショナル向けDTPソフトで、何のアラートも出さずに人名用漢字を含む文字を置き換えてしまうような振る舞いは、ユーザーにとってきわめて危険なものと言える[*7]。それでも、アドビシステムズは互換漢字を置き換えるためにこうした実装を行ったのではないのだろう[*8]。おそらくは、前述した発音記号付きのラテン文字を、アプリケーション上で扱いやすい合成ずみ文字に置き換えることが本来の目的だったはずであり、その限りではUnicode正規化の目的にかなった真っ当な実装とすら言える。同社にとって互換漢字が置き換わることの方が想定外だったのかもしれない。

● Unicode正規化が必要とされるインターネットの現実

　こうしたInDesign CS3の実装がユーザーにとっては迷惑であっても、じつはUnicodeの規定上は問題がない。もともとUAX#15にはどの部分に対してUnicode正規化を行うとする規定はなく、置き換えた結果をユーザーに見せてはいけないというような規定もない。だから実装者は目的に合わせてどのように実装してもよい。では、このことが何を意味するのだろうか。

　ここまではアプリケーション上の検索やカット＆ペーストなど、ユーザーのローカルな環境に限定した例ばかりを挙げてきた。しかし現代では符号の処理が1台だけにとどまることの方がむしろ珍しい。私たちのコンピュータはたいていの場合ネットワークに接続されており、そこで入力した文字は深く意識することもなくネットワークを駆けめぐっている。じつをいうとUnicode正規化はこうしたインターネット時代（漢字小委員会ならこれを“情報化時代”と呼ぶはずだ）にこそ必要とされる技術だ。

　このことは時間を少し戻してみるとよく理解できる。インターネットが登場するずっと以前、例えば大型計算機やテレタイプといった旧来型のネットワークでは、符号を送る側と受ける側には完全な合意が存在した。一つ一つのネットワークは独立していて、その内部では特定のメーカーのハードウェアが使用される。だから符号の受信にあたっては特定の相手から特定の種類の符号が送られてくると割り切ることが可能だった。

　しかし1990年代前半以降、インターネットが急速に普及したことにより事情は大きく変わった。ここではネットワークを構成するハードウェアは種々雑多であり、不特定多数との合意のない情報交換を想定しなければならなくなった。具体的にいえば　前回調べたMac OS XとWindows Vistaの符号表現からもわかるように、送信相手が「ダ」という文字を表すのに合成ずみ文字のU+30C0を使うのか、それとも合成列のU+30BF／U+3099を使うのか、前もって予想はできないというのがインターネットにおける情報交換だ。Unicode正規化はまさにこうした状況の中で必要性が高まってきている。逆にいえばかつてのような大型計算機やテレックスなどのように秩序立った環境では、Unicode正規化は必要とされなかっただろう。

　次回は具体的にどのような用途でUnicode正規化が必要とされているのかを見てみることにしよう。

[*1]……なぜ、単一の文字が単一の文字に対して正規等価に指定されている場合は、どのタイプのUnicode正規化を行っても対応する文字に置き換わるのか。それは、そうした文字がUnicode正規化を適用することにより「より一般的な文字」に置き換わるべきと考えられたからだ。例えば光の波長の長さを表すオングストローム記号「Å」（U+212B）は、物理学者オングストロームの名を彼の母語であるスウェーデン語で表記した最初の1字（上リング付きA：U+00C5）にちなんだものだ。だからそもそもオングストローム記号と上リング付きAと外見の違いはない。こうした重複は互いが正規等価＝全く同じ字である以上、「より一般的な文字」の方に置き換えた方がよいことになる。そこでUnicodeでは「合成除外」（Composition Exclusion）というものを規定して、分解した後の合成をしないことにしている。この結果、オングストローム記号はUnicode正規化により、必ず上リング付きA（U+00C5）に置換されることになる。互換漢字が必ず置き換わる理由は、オングストローム記号と同じ指定をされたことによるものだ。

[*2]……『Unicode Character Encoding Stability Policy』（http://unicode.org/policies/stability_policy.html）

[*3]……より詳しくは『JIS X 0221:2001』（日本規格協会、2001年、P.1100～P.1101）を参照。また、この時のJIS X 0213の互換漢字割り当てについては、当時原案作成委員会メンバーだった安岡孝一氏のブログ『yasuokaの日記』2008年9月4日付エントリ「人名用漢字と互換漢字」（http://slashdot.jp/~yasuoka/journal/451203）も参照。このエントリは、本稿の初出時にコメントとして書かれたものだ。

[*4]……ISO/IEC 10646の2000年版の翻訳である、前掲『JIS X 0221:2001』の該当箇所は、次のように書かれている。「この規格群には互換用文字が含まれているが、これは、既存の符号化文字集合との互換性を保ち、情報を失うことなく双方向の符号変換を可能にすることを目的にしている」（P.16）。2003年版の翻訳である『JIS X 0221:2007』の該当箇所については第3回を参照されたい。

[*5]……JIS X 0213以前は、Microsoftと日本IBMがU+FA0E～U+FA2Dに収録されているWindows収録のJIS外字に由来する互換漢字に利害関係を持っていた程度だろうか。日本IBMは当初CJK-JRG（IRGの前身）にこれらの字を提案したが否決されたので、今度はWG2で漢字を使わないはずのカナダIBMに代理提案をさせることで、最終的に収録に成功している。「カナダに漢字を使う少数民族が!?　Unicodeをめぐる不思議なものがたり」樋浦秀樹（『月刊ASCII』2000年7月号、P.169～170）を参照。

[*6]……HFS Plusについては『Technical Note TN1150 HFS Plus Volume Format』（http://developer.apple.com/technotes/tn/tn1150.html#UnicodeSubtleties）を参照。和訳（http://developer.apple.com/jp/technotes/tn1150.html#UnicodeSubtleties）もあるが内容的に多少古い。またMac OS XにおけるUnicode正規化の資料として『Technical Q&A QA1235 Converting to Precomposed Unicode』（http://developer.apple.com/jp/qa/qa2001/qa1235.html）、『Technical Q&A QA1173 Text Encodings in VFS』（http://developer.apple.com/jp/qa/qa2001/qa1173.html）がある。一方でWindows XPやWindows VistaにおけるファイルシステムであるNTFSについては資料がほとんど公開されておらず、詳しいことは不明と言わざるを得ない。なお、Windows Vista付属のメモ帳で同様のファイルを作成し検索をかけたところ「祝」だけにヒットした（図4）。一方でラテン文字の合成ずみ文字と合成列は同一視する。つまりWindows Vistaでは互換漢字は検索ルーチンで同一視する中から除外されていることになる。このあたり、Unicodeに忠実であろうとするMac OS Xと、日本の字体規範に忠実であろうとするWindows Vistaという考え方の違いが垣間見えて興味深い。この項、第2部第6回の注釈14も参照。

図4　Windows Vistaで互換漢字とそれに対応する統合漢字を含むファイルを作成し統合漢字で検索したところ、統合漢字にだけヒットした

[*7]……なお、同年6月4日付エントリ「Adobe-Japan1のCJK互換漢字とInDesign CS3」では文字化けする文字をすべてリストアップしている（http://d.hatena.ne.jp/NAOI/20080604）。また、こうしたInDesign CS3の振る舞いを修正するユーティリティとして、丸山氏による『FILL InDesign』（http://tama-san.com/download.html）がある。

[*8]……ただし、あさうす氏の『実験る～む』の2008年7月21日エントリ「Windowsでもやってみた。」によると、Windows版のInDesign CS3では同じ条件でも互換漢字を置き換えないことが報告されている（http://dslabo.blog4.fc2.com/blog-entry-1277.html）。

● 修正履歴

[訂正]……安岡孝一氏より、ご自身のブログ『yasuokaの日記』を通して、この原稿に対してコメントをいただいた（2008年9月4日付エントリ「人名用漢字と互換漢字」http://slashdot.jp/~yasuoka/journal/451203）。これについて調べ直したところ、安岡氏のおっしゃる通り、〈1999年当時、話がそんなに簡単だったわけではない〉ことがわかった。このエントリは直接的には第2部第5回について書かれているのだが、むしろ第2部第7回の下記部分を訂正するべきと判断した。詳細は訂正部分をお読みいただきたいが、互換漢字は1999年当時、その性質についてちょうど再定義が始まったころであったと考えられる。JIS X 0213互換漢字は、そうした状況の中で提案、審議、承認された。またUnicode正規化を規定するUAX#15（1999年制定）も、同様にこの時期に制定されたものだ。これを私は見落としていた。安岡氏をはじめ関係者の皆様にお詫びするとともに、以下のように原稿を訂正したい。

誤：
　こう書くとUnicodeばかりが悪いようだが、彼らの側にも同情すべき点はある。2000年にJIS X 0213が制定される以前、互換漢字は政令文字を割り当てるような存在ではなかった。特定の国内規格との互換性を保証する以外には使い道が限定された、本当に例外的で脇役的な存在にすぎなかった[*3]。互換漢字が正規等価とされたころは、まだそんな時代だったのだ。正直なところ、互換漢字が正規等価だろうが互換等価だろうが大差はないと思われていたのではないか。

　そうした互換漢字の性質を一変させたのが、じつはJIS X 0213による政令文字の互換漢字への割り当てだった。それまでそのような重要な文字を互換漢字に割り当てることなど思いもよらなかった。ということは犯人はJIS X 0213なのだろうか？　違う、JIS X 0213が悪いわけではないだろう。そもそも法務省がこれらの字を人名用漢字（当時は人名用漢字許容字体）に指定しなければ、JIS X 0213は互換漢字に割り当てなかったはずだからだ。では法務省が犯人？　違う、法務省が悪いわけではない……とまだまだ先は続く。このことが何を意味するかは第3部で考えることにして、今は先を急ごう。

正：
　こう書くとUnicodeばかりが悪いようだが、彼らの側にも同情すべき点はある。Unicode正規化を定めたUAX#15が制定された1999年は、互換漢字の性格が明確化される議論がちょうど始まったころだった。というより、UCSが初めて互換漢字の厄介さに気付いた時期と言えるかもしれない。このころの議論の中で既存の互換漢字と対応する統合漢字について洗い直しが行われ、その結果、対応するものがない互換漢字については、統合漢字と見なすことが決定された[*3]。

　第3回で述べたような「互換漢字は特定の規格との互換性確保だけに使われるもの」という位置付けも、この時の議論によって明確化されたものだ。実際にこの条項はUCS（ISO/IEC 10646）の2000年版にはなく、2003年版で初めて付け加えられている[*4]。こうした議論が定まらないうちにUAX#15は制定された。そのころのUnicodeにとっては、互換漢字が正規等価だろうが互換等価だろうが大差はないと思われていたのではないか[*5]。

　ということは、そうした互換漢字に政令文字を割り当てたJIS X 0213が犯人なのだろうか？　もちろん違う。そもそも法務省がこれらの字を人名用漢字（当時は人名用漢字許容字体）に指定しなければ、JIS X 0213は互換漢字に割り当てなかったはずだからだ。では法務省が犯人？　違う、法務省が悪いわけではない……とまだまだ先は続く。このことが何を意味するか第3部で考えることにして、今は先を急ごう。

（2008/10/11）

2008/09/05 11:07

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

- ページの先頭へ-

INTERNET Watch ホームページ