電子書籍の（なかなか）明けない夜明け

●揺れている外字の境界線

　引き続き、電子書籍時代の外字問題を考えている。まず、ざっと「外字」とは何かを振り返ろう。コンピューターで扱える文字全体を、文字コード規格（標準）とフォント（実装）によって整理すると、下図のようにまとめられる。

図1　コンピューターにおける文字の、標準と実装による分類

　標準と実装を組み合わせることで、コンピューター上の文字は4つに分類され、そのうち外字は3種類に区分できる。前回は上図のうち緑の区分、つまり（あまり使われない表現だが）「内字」の部分について説明した。そこで明らかになったことは、内字とする範囲が変われば、外字の範囲も変わるということだ。つまり、内字と外字の境界線は、常に揺れている。

　今回は図1で灰色の区分（外字（1））、つまり文字コード規格に収録されているが、フォントには実装されていない文字を考える。これは簡単に言うと、Unicodeの収録字数が拡大するにともない、内字とする範囲がバラバラとなってきた状況が生んだ外字だ。

　例えば、前回も出したヒラギノ（Mac OS X）とメイリオ（Windows Vista/7）を考えてみよう。この場合、内字とする範囲は、Unicodeの符号位置を持ち、同時に両方のフォントに重複して符号位置を割り当てられている文字となる。そこで、前回はどちらか片方にしか実装されていない漢字の例として、以下のような図を示した。

図2　Windows Vista/7とMac OS Xの標準的なフォント間で、どちらか片方だけに符号位置を割り当てられている漢字の例

　これらの漢字こそが、この区分の外字だ。これらは、ヒラギノとメイリオの文字セットの違いが産み出す外字といえる。ただし、上図の漢字は使用頻度が低いので、実際に問題になることは少ない。ところが新たな実装の普及にともない、使用頻度の比較的高い漢字がこの区分の外字になることが増えてきている。厄介なことに、こうした外字は多くの文字を実装している環境、例えばパソコンのOSからは、なかなか見えづらく、だから問題にもされづらい。

●意外に少ない漢字で済む？　日本語の漢字表記

　これを解説する前に、まずUnicodeの開発状況を確認しておこう。下表は1993年の制定から現在に至るまで、漢字に関するUnicodeの開発状況をまとめたものだ（図3）。

図3　Unicodeにおける収録漢字数の推移とその特徴（1993年～2010年）。「DerivedAge-6.0.0.txt」[*1]より集計。この文書は追加年月日とその符号位置を記録したものなので、その後、U+F900～U+FA0Bの互換漢字領域の中から12字が統合漢字に変更されたのが反映されていないなど、細かな違いがある（この結果、統合漢字は74,594字、互換漢字は1,022字となる）。もちろん総計は変わらない

　ここでUnicodeの収録漢字数が、じつに75,616字もあることにご注目いただきたい。そして、そのほとんどは2001年に制定された拡張Bまでに収録が終わっている。かつて主流だったシフトJISは、両仮名や記号類を含めても収録字数は7,300字程度にとどまっていた。そうした時代では夢でしかなかった膨大な数の漢字が、規格の上では10年も前から使用可能になっていた。

　思い出してほしいのだが、前回はWindows Vista/7とMac OS Xにおける「内字」（図1で緑の区分）のうち、信頼できる文字セットの範囲はJIS X 0213だと書いた。このJIS X 0213の漢字収録数は、前述したUnicodeの収録漢字数からすると7分の1程度の10,050文字にすぎないのだ。以前は「コンピューターで使える文字が足りない」というと、文字コード規格の文字数が槍玉に挙げられてきた。しかしUnicodeの大規模化にともない、問題の焦点は規格より実装、すなわち使いたい漢字をフォントが実装しているか、そしてその文字は文字化けせずに送受信できるのかに変わりつつある。

　ここで、なぜもっと多くの漢字をフォントに実装しないのだと、OSベンダーに歯がゆさを感じるかもしれない。しかし1万字程度のフォントを、ごく普通の人間がごく普通の用途で使った場合、「この漢字がない」と思うことなど滅多にないはずだ。

　例えば、凸版印刷で2004～2006年に印刷された書籍860冊分の組版データを調査した『漢字出現頻度数調査（3）』では、対象とした漢字総数は4,907万2,315文字あったのに対し、異なり文字数は8,576文字まで絞られることが分かっている。さらにその96.39％までもが、たった1,945文字（当時）の常用漢字で占められている[*2]。つまり、これが現代日本語における漢字の振る舞いなのだ。

　こうした調査結果からすれば、メイリオが符号位置を割り当てる13,654文字、同じくヒラギノの11,459字という漢字数がいかに多いものか、そしてUnicodeが収録する75,616字が、いかに浮き世離れした数かがよく分かると思う。実際、「コンピューターで～～という漢字が使えない」という人の話をよく聞いてみると、すでにその字はJIS X 0213（漢字収録数10,050文字）に収録済みで、とっくの昔に自分のパソコンで使えていたというオチがついたりする。

●スマートフォンにおける厄介な漢字の表示実験

　さて、こうした近年のUnicode収録漢字数の増加は、結果としてこの灰色の区分の外字――フォント実装のバラツキがもたらす外字を目立たせることになった。どういうことかというと、図1でいう緑の区分、内字とする範囲（互いに重複する範囲）についての標準が普及しておらず、その結果実装がばらばらになり、差分が化けてしまう。その最も顕著な例がスマートフォンだ。これについて、ちょっとした実験をしてみた。

　あらかじめ情報交換で問題になりそうな漢字を選定し、これをTwitterにて送出、スマートフォンのオーナーの方々に、スクリーンショットをとってリプライしてもらうようお願いした（図4）。

図4　厄介な漢字のツイート。これはMac OS XにおけるSafariでの表示結果であり、何ら問題はない。しかしスマートフォンではどのように見えるだろうか？

　その結果をまとめたのが、以下のウェブページだ[*3]。

◆スマートフォンにおける厄介な漢字の表示実験
https://idisk.mac.com/ogwata//Public/yakkaina_moji/index.html

　概括すると、Android端末における文字化けが目立つ。後からユーザーがフォントを追加したa12を除けば、すべてが何らかの文字化けを発生させており、悲惨といってよい結果に終わっている。一方、iOS端末は概して文字化けが少ないが、一部で文字化けしたり（i10、i11、i12、i13、i22）、アプリによっては0面以外の漢字を消失してしまうものもあり（i18、i20）、油断はできない。

●どんな漢字が厄介なのか

　調査結果の前に、送出した漢字について簡単に説明しておこう（図5）。

図5　縦が調査で送出した漢字。横がその属性。使用頻度を知るために、参考として前掲『漢字出現頻度数調査（3）』での順位も添えた。順位のないものは3,501位以下であることを示す

　まず「新常用漢字」（2）、（6）～（10）とは、2010年11月に改正された常用漢字表において、追加された196字のこと[*4]。常用漢字表は日本における言語政策の基本だ。文字コードとの関連では、比較的新しいJIS X 0213だけ含まれている文字（図9で6～8。以下同）が正しく扱えるかが焦点となる。また、0面以降の文字の中にも新常用漢字は含まれている（（2））。常用漢字表は字体を定められているので、文字として表示できるのは当然として、正しい字体が表示されるよう期待したいところだ。

　次に「面」（1）、（2）は、収録されているUnicodeの場所のこと。もともとUnicodeは、256×256＝65,536字を1つの面として、ここに世界中の文字を収録する文字コードとして出発した。この最初の面を0面と呼ぶ。しかしすぐに65,536字だけでは足らなくなり、面を増やす必要が生じた。しかし、0面以外の文字を使う際には、過去との互換性のため特殊な表現方法を使う場合もある。この場合は実装側の対応が必要だ[*5]。

　IBM拡張文字（3）、（4）とは、Unicode以前に主流だったシフトJISにおける代表的な外字セットのこと。Windows 3.1以降のマイクロソフトのOSに採用されたが、2000年のJIS X 0213制定時に（3）など数文字を残して収録されるまで、JIS文字コード規格とは無縁だったため、よく文字化けを起こした。なお、（3）の文字は固有名詞でよく見かける字体だが、JIS X 0213では「高」と同一視（包摂）されている（前回参照）。

　互換漢字（4）、（5）とはUnicodeにおける文字の属性のひとつ。本来は統合漢字（図5［　］内の文字）と統合されるべきだが、他の規格との互換性を維持するために特別に収録された漢字だ。現時点で互換漢字最大の問題点は、実装者がUnicode正規化を安易に組み込んだことにより、意図せず［　］で括った漢字と置き換ってしまうケースが増えつつあることだ[*6]。置き換わっても漢字としての意味や読みは変わらないが、固有名詞など字体に拘りたい場合は困る。また互換漢字には人名用漢字の一部が含まれており、この場合は法定文字が化けることになってしまう。

　JIS X 0213:2004（2）、（4）～（13）は、日本で主軸をなすJIS文字コード規格だ。この規格は、Windows Vista/7やMac OS Xでは、図1でいう「内字」の位置を占めていることは前回述べた。したがって、このグループに入っている文字が正しく表示されない場合、これらのOSとの間でも文字化けする可能性がある。

　JIS X 0213は2000年に制定した後、2004年に表外漢字字体表（2000年国語審議会答申）に対応するための改正を行なっている。これが現行版（JIS X 0213:2004、JIS2004とも）だ。この際に、168面区点の符号位置は変えず例示字体のみを変更した。そのグループに該当するのが（9）～（13）だ。変更前の字体を〔　〕で括ったが、このうち（9）と（10）は、さらに新常用漢字のグループとも重なっている。この問題は符号位置ではなく、フォントのタイプフェイス・デザインの問題だ。パソコンの場合、Windows Vista/7にバンドルされているMSフォント及びメイリオ、Mac OS X 15.0以降にバンドルされているヒラギノProNを使用すれば、改定常用漢字表に基づいたタイプフェイスを表示する。これに対して、はたしてスマートフォンではどうかが試される。

●総じて成績優秀なiOS

　以上のような漢字を、8つのグループに分けて結果をまとめる[*7]。まずは問題が少ないiOSから（図6）。

図6　iOSの調査結果。横列の角数字は図5における番号。×は他の文字に化けたことを、四角に×は文字が消失したことを表わす

　一見して「×」が一部分に限られることが分かる。つまり総じてiOSは問題が少ない。トラブルは0面以外の文字（1）、（2）の扱いに限定されるが、それも一部のアプリケーションだ。つまりOSの不備というよりも、アプリケーションのコーディングの問題であることが伺える。なお、文字が化けた場合はすべて同じ字に化けているが、符号値を16進数で表した際、5桁目だけが脱落してしまったことが原因と思われる（図7）[*8]。アプリケーションの内部で文字を表す符号の長さを、あらかじめ16ビット（16進数4桁）と決め打ちして作った可能性もある（この部分、注4も参照）。

図7　0面以外の文字が化けた原因

　文字化けしたもののうち、「SOICHA」はアプリケーション実行環境「Adobe Air」に対応したものであり、原因はそこにある可能性を考慮すべきかもしれない。その他も、いずれも特定のアプリケーションに依存して発生している。問題のあったTweetbotは米国の、Twippaはフランスのアプリケーションだ。新常用漢字がUnicodeの2面に存在している日本はいざ知らず、欧米の人々にとって0面以外のサポートは負担が大きいことを表しているようにも思える。

　思ったより長くなったので、この続きは次週にさせていただく。今回に続いて、Android端末の調査結果をお伝えする。

●注釈

[*1]……データの出典はUnicode, Inc.「DerivedAge-6.0.0.txt」2010年10月5日
（http://unicode.org/Public/UNIDATA/DerivedAge.txt）

[*2]……総漢字数は『改定常用漢字表』（文化審議会、2010年、P.（9））、異なり文字数は『漢字出現頻度数調査（3）』（文化庁、2007年、P.（4））による。なお、『漢字出現頻度数調査（3）』では総漢字数が「50,052,724文字」とあるが、これは刊行後に『改定常用漢字表』にある数字（49,072,315文字）に訂正されている。これについては『第29回国語分科会漢字小委員会・議事録』（http://www.bunka.go.jp/kokugo_nihongo/bunkasingi/kanji_29/pdf/gijiroku.pdf）の「経過概要」で、結果だけ短く記述されている。この時の事務局による資料説明によって補足すると、『漢字出現頻度数調査（3）』にある数字は、凸版印刷のミスにより古典が算入されないままだったことが刊行後に判明した。その訂正後の集計結果が、『参考資料2「漢字出現頻度数調査（3）」のデータに関連する資料』（http://www.bunka.go.jp/kokugo_nihongo/bunkasingi/kanji_29/pdf/sanko_2.pdf）で公開されている。ただし、〈現代の国語を書き表す場合の漢字使用の目安〉である常用漢字表の改正審議では、かえって古典を除いた方が適切だろうという理由から、そのままとすることになった。なお、この部分は議事録に記載されておらず、当日傍聴した者が記憶するのみだ。また、同じ調査に基づいた田原恭二氏（凸版印刷）のスライド資料、『Unicode化の事例紹介：漢字出現頻度数調査』（http://bizpal.jp/epub/Download?id=166c2854-bede-49c8-a52b-272150f30a97）では、別の47,924,433文字という総漢字数が掲載されているが、これは『改定常用漢字表』から、さらに教科書の調査分を除いた数字であろう。

[*3]……なお、その際のTwitter上でのやりとりは、次を参照されたい。『文字化けの饗宴：スマートフォンにおける厄介な文字の表示実験（当日編）』Togetter（http://togetter.com/li/152349）、『文字化けの饗宴：スマートフォンにおける厄介な文字の表示実験（後日編）』Togetter（http://togetter.com/li/160102）

[*4]……文化審議会答申『改正常用漢字表』2010年11月
（http://www.bunka.go.jp/bunkashingikai/soukai/pdf/kaitei_kanji_toushin.pdf）

[*5]……具体的には「特殊な方法」とはUTF-16を指す。これについて簡単に説明しておく。あらかじめ0面に1,024個からなる特定領域を2つ確保しておき、これを組み合わせることで1,048,576文字を表現可能としておく（1024×1024=1,048,576）。その上で、この組み合せを0面以降の符号位置に1字ずつ順番に対応付けておく。こうすることで、0面における組み合わせを「代理」（サロゲート）として扱うことで、16ビット以上の文字を表現可能となる。つまり、16ビット以上（16進数5桁以上）の文字を16ビット単位（16進数4桁を2つ）で扱えるようにして、互換性のハードルをなるべく下げようとする考え方だ。この組み合わせを「サロゲートペア」（代用対）と呼ぶ。JIS X 0213に収録された文字の一部は、Unicodeでは16ビット以上の面に対応付けられており、このサロゲートペアの扱いが必要になる。より詳細は次の記事を参照。安岡孝一「Vistaで化ける字，化けない字」IT Pro、2006年12月14日（http://itpro.nikkeibp.co.jp/article/COLUMN/20061211/256519/）、さなみ「サロゲートペア入門」CodeZine、2007年8月28日（http://codezine.jp/article/detail/1592）。

[*6]……より詳細は、過去に書いた拙稿を参照。『“情報化時代”に追いつけるか？　審議が進む「新常用漢字表（仮）」第2部第7回　Unicode正規化と互換漢字』
（http://internet.watch.impress.co.jp/cda/jouyou/2008/09/05/20740.html）

[*7]……表にまとめるに際し、いくつかの応募写真は入れなかったことをお断わりする。具体的にはa12、i19、i23の3枚だ。このうちa12は後からフォントを追加しており、デフォルト状態ではないからだ。i19は、私が0面以外の文字が消えていることを気付かないまま誤って送出したツイートを撮影したものだった。最後のi23だが、元来Twitterにはsearch APIを使ってツイートを検索・表示した場合に限り、0面以外の文字が消失してしまうというバグがあるのだが、このi23はsearch APIを使ったものだったことが分かったため。確認に際しては応募者に直接問い合わせた。これらの他に、a07とi06も誤ったツイートを撮影していたが、応募者が改めて撮影したものを送ってくださったので、これに差し替えている。なお、Twitterにおけるsearch APIのバグに関しては以下を参照
（http://twitter.com/ogwata/status/87885550119428096、
http://twitter.com/ogwata/status/87910831483920384）

[*8]……直井靖氏よりのご教示
（http://twitter.com/moji_memo/status/83059411882491904）