Internet Watch logo
記事検索
バックナンバー
【 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部 新常用漢字表と文字コード規格
第10回 異体字シーケンスは互換漢字の代替になりうるか


任意の字体を表示させる手段としての異体字シーケンス

 第2部第8回で異体字シーケンスの一番の肝は「従来は包摂されていた字体を区別可能にするところ」と書いた。つまり従来の異体字シーケンスに対応しない環境では、フォントを切り替えれば包摂の範囲内で字体が変わっても仕方なかったのを、これを使うことによって強制的に任意の字体を表示させることができる。しかもこれに対応した環境同士ならば、そうした区別を保持したままプレーンテキストによる情報交換をし、そのままの字体で表示が可能だ。UTS#37では以下のような例を挙げ、異体字シーケンスを使えば「芦」という漢字の異なる2つの字体を使い分けられると説明している(図1)。


図1 UTS#37で例示されている、今まで包摂されていた2つの字体の使い分け(赤字部分)

 ここまで何回も例に挙げた「箸」の場合でいえば、
前回述べたようにフォントを切り替えると点つきになったり点なしになったりしてしまうのが現状だった。これが異体字シーケンスを使うことで、表外漢字字体表に基づいた点のある方の字体を強制的に表示させることができるようになった。異体字シーケンスに対応し、Adobe-Japan1に準拠した異体字シーケンス対応フォントを使用する限り、フォントを切り替えても必ず印刷標準字体が表示されるようになる。これが普及すれば現状の「混乱」も解消に向かうということだろう。


アプリケーションやOSにおける異体字シーケンスの実装

 Adobe Systemsは最近発表されたAcrobat 9、Adobe Reader 9、およびAdobe Flash Player 10で、異体字シーケンスに対応している
[*1]。よく知られているようにAdobe Reader 9は無料で入手可能だ。手近に異体字シーケンスを試すには、これとUCSの漢字レパートリを審議するIRGの第30回釜山会議で公開されたケン・ランディ氏(Adobe Systems)によるPDF文書、『Ideographic Variation Sequences - Implementation Details & Demo -』の7ページ目にあるフォームフィールドを使用するとよいだろう(図2/注釈1参照)。


図2 Windows Vista SP1におけるAdobe Reader 9の異体字シーケンス入力。Adobe Reader 9のインストールの際、異体字シーケンス対応のOpenTypeフォント「小塚明朝Pr6N」(ver.6.004)も一緒に入れられる。ここでは文字を選択の上、マウス右クリック(コントロールキー押下でも可)でメニューが表示され、「同じUnicodeの異体字」を選ぶことで異体字シーケンス入力用のウィンドウが表示される

 同時に公開された『White Paper: Ideographic Variation Sequences』は異体字シーケンスの規格と実装情報を簡潔にまとめた資料だ[*2]。ここではOSの対応について以下のように書いている。

IVSは近い将来OSレベルでサポートされることになっています。これはより多くのアプリケーションがIVSのメリットを利用できるOSレベルのAPIが、すでに存在するかもしれないことを意味します[*3]。(P.2 IVSes & OSes)


 また前掲『Ideographic Variation Sequence』の中でも「Microsoft & Apple Are Fully Aware Of IVSes」(MicrosoftとAppleはIVSを完全に知っている)と書いている。このうちAppleはすでに2000年2月の時点から異体字シーケンスに対して将来実装する意向を示していた[*4]。後で述べるようにMac OS Xのテキストエディットは異体字シーケンスに対応はしていないが字形選択子の解釈はしている。こうしたことからすれば、Mac OS Xで異体字シーケンスが使える日は意外に近くまで来ているように思える。またAdobe Systemsがここまで言うからには、恐らくWindows Vistaでも使えるようになるのではないか[*5]


「包摂字体を区別する技術」を使ってはいけない分野がある

 以上、異体字シーケンスが目指すものを説明した。そこでこれが一般に普及する前に、何か問題がないか検討してみよう。まず懸念材料として挙げられるのが、異体字シーケンスも互換漢字と同様、国際化ドメイン名(IDN)に使用できないということだ。字形選択子は第2部第8回で述べた国際化ドメイン名を規定するインターネット標準(RFC)の中で、削除される文字に指定されている。具体的にはそれらの中で引用されている文字処理の枠組み「Stringprep」(RFC 3454[*6])の中で、Unicode正規化の他にもいくつかの文字をあらかじめ削除する処理を規定しており、その中に字形選択子が入っている[*7]

 ただし、ここで指定されているのは異体字シーケンスに使う第14面のU+E0100~U+E01EFではなく、BMP(第0面)にあるU+FE00~U+FE0Fだけだ。これはStringprepが対象とする文字セットの範囲を2002年3月制定のUnicodeバージョン3.2に制限していることによる。第14面の字形選択子がUnicodeに収録されたのは2003年4月のバージョン4からなのだ[*8]

 もともとStringprepの目的は、紛らわしい文字を排除するところにある。第8回でも説明したが、「見かけはそっくりだが符号の並びは違う」というような紛らわしい文字が存在すれば、例えば外見は同じなのに違うドメイン名が登録されてしまう。「箸」の例でいえば、仮にこの字を含んだ箸や折り箱の老舗があったとして、悪意のあるライバル店は異体字シーケンスを使うことで簡単に偽ドメイン名を登録できてしまうことになる。こうした紛らわしい文字の排除は、一部の用途にせよきわめて緊急性の高い課題だ。

 つまり、Stringprepによる字形選択子を削除するという処理そのものは正しいと言わざるを得ないし、この意味からは国際化ドメイン名に異体字シーケンスは使われるべきではない。したがって将来Stringprepの対象文字セットが拡大される際には、U+E0100~U+E01EFの字形選択子が削除対象に追加されると思われる。

 では現在、異体字シーケンスを含む日本語ドメイン名は登録できるのだろうか。日本レジストリサービス(.jpを管轄)とVeriSign(.com、.netを管轄)のドメイン名検索ページで、「箸」の異体字シーケンス「U+7BB8/U+E0101」で検索してみたところ、前者は「利用できない文字を含んでいます」、後者は「通信エラーが発生しました」という表示がされた(図3)。これらの検索画面で利用可能と認定されなければ手続きが進められないため、現状でも異体字シーケンスを含む日本語ドメイン名は登録できないと考えてよさそうだ。


図3 日本レジストリサービス(左)と日本ベリサイン(右)での日本語ドメイン名検索画面

 ここで明らかになるのは、個別の規格であるStringprepの中で字形選択子が削除されるかどうか以上に、むしろ異体字シーケンスという技術そのもの、あるいは包摂字体を区別したいという要求そのものもがセキュリティ問題を発生させる可能性があるということだ。もっともこれは異体字の問題もさることながら、片仮名の「ニ」と漢字の「二」、同様に「ロ」と「口」の例が示すように、日本語そのものが持つセキュリティ問題とも言える。それでもこれは包摂とは何か、何のためにあるのかを考えさせてくれる事例ではある。


アプリやOSには「デフォルト無視可能」でも、ユーザーは無視できない

 もう1つ、UTS#37が言う「デフォルト無視可能」にも注意する必要がある。例えばMac OS Xでは、現状でも字形選択子はたいていの場合は不可視だし(図4)、普通には入力もできない。


図4 前掲PDF文書、『Ideographic Variation Sequences - Implementation Details & Demo -』で異体字シーケンスを作成、これをMac OS X付属のテキストエディットにペーストした。字形選択子はないかのように無視され、これに先行する統合漢字だけがそのままの字体で表示されている

 しかしこれは、あくまでそのように実装されているからだ。字形選択子がUnicodeに収録される2003年4月以前から稼働しているようなサーバーやOS、アプリケーションなどに対し、最先端のOSと同じ振る舞いを要求すること自体が無理な話だ。また最新のOSといっても必ず不可視にするわけではない。Windows Vistaで図3のテキストファイルをメモ帳で読み込んでみたところ、以下のような結果となった(図5)。


図5 上図で作成したテキストファイルをWindows Vistaで読み込んでみた。異体字シーケンスを解釈できずに「□」として表示している。一方で字形選択子に先行する統合漢字はそのままの字体で表示されている

 「無視」がどの程度のレベルを指すかにもよるだろうが、少なくとも字形選択子を不可視にするには、それなりの実装が必要であることがわかる。もう少し試してみよう。前掲図3~4で使用した文字列をブログにペーストしてみた。これをブラウザで読み込むとどうなるだろう(図6~8)。


図6 ブログにペーストした異体字シーケンスを、Mac OS Xバージョン10.5.4上のSafariで読み込んでみた。異体字シーケンスを解釈できずに「□」として表示している(http://d.hatena.ne.jp/ogwata/20080810

図7 上記のブログをWindows Vista SP1上のIE7で読み込んでみた。Safariと同様、字形選択子は「□」、統合漢字はそのまま表示されている

図8 上記のブログの文字列をコピーし、文字列の符号位置を表示するユーティリティUnicodeCheckerを使って調べてみた。異体字シーケンスを「Input」欄にペースト、「Compare with」欄にはキーボードから見た目が揃うように漢字を入力する。この比較結果が下段「Differences」に表示される。青字が同じ符号位置、赤字が違う符号位置だ

 UnicodeChecker自体は字形選択子を不可視として処理するだけだから、一見すると「Input」と「Compare with」に表示された漢字は全く同じに見える。しかしじつは符号の並びは違う。赤字の「U+DB40」で始まる符号の並びはいずれも字形選択子のサロゲートペア(第2部第9回の
注釈3参照)による表現。すなわち、ブログサーバーもブラウザも字形選択子を削除したり不可視の文字に置き換えたりせず、そのまま格納/出力/表示していると考えられる。その結果が図6~7の「□」だったわけだ。これこそがUTS#37のいう「無視」ではあるが……。

 UTS#37の立場からは、異体字シーケンスによってサーバーやブラウザが誤動作したわけではないから、図6~7の例は立派に「無視」されたものとなるのかもしれない。しかしユーザーの立場からはどうだろう。異体字シーケンスに対応しない環境では、これらの例のように見慣れない「□」や「・」が混入することになるだろう。一般の人々が、こうした見なれない表示をどのように受け止めるだろうか。

 キーになるのは、アプリケーションよりむしろOSでどのように実装されるかだろう。ここで私が心配しているのは、具体的にはMac OS XのテキストエディットやWindows Vistaのメモ帳などで、ユーザーがそれと意識することなく異体字シーケンスが入力されてしまうような実装を指す。慎重な両社のエンジニアがそのような実装を選ぶ可能性はあまりないとは思うが、そうして作られたテキストデータが、そのままブログなどで書き込まれれば、上図のような画面になってしまう。これから実装するメーカーには、熟慮の上で進めていただきたいと思う。


異体字シーケンスは、互換漢字の完全な代替にならない

 最後に異体字シーケンスについてまとめてみよう。この技術そのものは、これまで包摂の範囲で意図せず字体が変わっていた「混乱」に対する有効な回答の1つだと思う。現在の我々の国のように、漢字の一点の有無にこだわるような社会では良い解決法になるのではないか。これに対応した環境である限りフォントを切り替えても字体が変わることはない。また対応した環境同士ならば、字体の違いを保持したままプレーンテキストでの情報交換が可能だ。

 しかしこれも万能ではないことは覚えておきたい。まず互換漢字と同様に、国際化ドメイン名などStringprepが介在するような用途には使えない。そして対応しない環境では「□」等で表示されるから、これを入力する際はユーザーにそれと意識させるべきだし、非対応環境との情報交換ではどのようなことが起きるか周知徹底が必要だろう。その意味では異体字シーケンスは互換漢字が持つ問題点を軽減はしても根絶するものではない。

 ここまで第2部として常用漢字表に略字体が追加された場合に起こる「漢字政策の玉突き現象」、そしてインターネットとUnicode正規化の普及によって互換漢字による異体字の符号化が限界に来ている現実、そうした事態に対する技術的な解決策である異体字シーケンスの概要とその問題点について述べた。次回は結論として、常用漢字表の改訂に再び戻ろう。ここまで見てきたさまざまな現実が何を意味するのか、何が本当の問題なのか、そして今後の国語施策はどうあるべきかを考えてみようと思う。

 今、私が気になっているのは、紛らわしい文字を排除するというStringprepの目的からは、異体字シーケンスで使われる字形選択子が本来削除されるべき文字であるという事実だ。インターネットにおいては、包摂字体を区別したいという要求そのものもがセキュリティ問題を発生させてしまう。これは何を意味するのか。インターネットの発展とともに、どうやら文字そのものが持つ目的や性質が、正反対の2つに分裂しつつあるように見える。1つはドメイン名だとかID、URIなど公共性の高い文字、もう1つは私的な表現の道具としての文字。互換漢字に未来がないのは確かとして、異体字シーケンスは後者のための技術なのだろうし、そこにこの技術の豊かな未来があるのではないか。そうした意味で字形選択子がStringprepで削除されるのは、むしろ当然なのだ。

 そこで問題になるのは、常用漢字はこの2つのうちどちらに入るべきなのかということだ。しかしこの続きは次回ゆっくり考えることにしよう。どうかお楽しみに。

[*1]……『Ideographic Variation Sequences - Implementation Details & Demo -』(http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1435_ivs-demo-irg30.pdf
[*2]……『White Paper: Ideographic Variation Sequences』(http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1435_ivs-white-paper.pdf
[*3]……APIとはApplication Programing Interfaceの略。OS等の内部にありソフトウェア開発にあたって使用するOSの機能を呼び出すための機構。この文脈でいえば、MicrosoftやAppleのOSが、すでに異体字シーケンスへの対応準備のうち主要な段階を終えているかもしれないということ。
[*4]……拙稿『文字の海、ビットの舟』「特別編 MacOS Xの新フォントと2000JISの関係」を参照。ここでAppleの木田泰夫氏は異体字シーケンスについて当時使われていた「バリアント・タグ」という言葉で言及している。
[*5]……本文では触れる余裕がなかったが、主要ベンダーだけでなく日本のフリーウェアでも異体字シーケンスを実装するものが出てきている。例えばexeal氏による多言語テキストエディタ『Alpha』(http://alpha.sourceforge.jp/)や、Y.Oz氏によるフリーフォント『Y.Oz Font ペン字版/毛筆版』(http://yozvox.web.infoseek.co.jp/)が挙げられる。情報が限られる中で実際に作ってしまった努力と才能に敬意を表したい。
[*6]……『RFC 3454 Preparation of Internationalized Strings ("stringprep")』(http://www.ietf.org/rfc/rfc3454.txt)。和訳は『RFC 3454 国際化文字列の前処理("stringprep")』(http://www.jdna.jp/survey/rfc/rfc3454j.html)。
[*7]……前掲『RFC 3454』「3.1 Commonly mapped to nothing」
[*8]……RFC 3454が対象とする文字セットについては「A. Unicode repertoires」を参照。なお、RFC 3454では、「1.2 Using stringprep in protocols」において、より新しいバージョンのUnicodeに収録された文字を対象にするには自身の改訂が必要としている。



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

- ページの先頭へ-

INTERNET Watch ホームページ
Copyright (c) 2008 Impress Watch Corporation, an Impress Group company. All rights reserved.