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

●常用漢字が表示できないAndroid端末

　それでは前回に引き続き、Android端末の調査結果をお伝えしよう。まず実験で集まったスクリーンショットは、下記のページで公開している。

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

　その上で、Android端末の表示結果を表にまとめたのが下図だ（図1）。

図1　Androidの調査結果。？は写真が不鮮明で視認できないことを、△は文字としての意味や読みは通じるが、形が置き換わっていることを、×は全く別の文字か「豆腐」に化けたことを表す

　表をよく見ると、ここでの問題点は次の3つに集約できそうだ。

　　・0面以外の文字の扱い　〈（1）、（2）〉
　　・一部の互換漢字の扱い　〈（5）〉
　　・JIS X 0213:2004で例示字体を変更した文字の扱い　〈（9）～（13）〉

　まず不可解なものから説明しておくと、（5）の文字のうちドコモ端末の一部、「△」の機種が、意図せず別字体である「海」に置き換えられてしまった。これはドコモ製品すべてに起こる訳ではなく、発生するアプリケーションは一定せず、さらに同じ互換漢字である（4）の文字はなぜか置き換えられないなど、どのような理由で発生するのか不明と言うしかない。おそらくUnicode正規化によるものと思われるが、これだけ結果が不揃いだと他の原因を考えるべきかもしれない[*1]。ただし原因が何であるにせよ、別の字体に置き換わるようなことは、本来あってはならないはずだ。

　他方でシンプルに原因を推測できるのが、JIS X 0213の2004年改正（JIS2004）における例示字体変更に関わる文字の扱い（9）～（13）だ。ここでは別の文字に置き換わったり消失したりはせず、ただタイプフェイス・デザインが違う文字（前回掲載の図5で〔　〕で括った字体）が表示されている。これはフォントに原因がある。JIS2004の例示字体と同じデザインのフォントがインストールされていないのだ。

　もっとも、規格には例示字体どおりにフォントをデザインしろとは書いてない。違いがJIS2004に定められた範囲に収まっていれば（言い換えれば別の字と誤解されなければ）問題はない。その意味から（11）～（13）が〔　〕内の字体で表示されたからと言って問題視すべきではない。しかし（9）、（10）は事情が違う。常用漢字だからだ。前回述べたが、常用漢字表は字体の基準を定めている。これらの字については〔　〕の字体で表示されるのは好ましくない。

　同様に0面以外の文字の扱い（1）、（2）もフォントの問題だ。iOSでは別の文字に化けたり、そっくり消失したりしていたが（前回参照）、Androidの場合は（2）の文字についてはすべて「豆腐」になってしまった。これは、図1で取り上げたAndroid端末には、（2）の文字の符号位置（U+20B9F）に文字の形を割り当てたフォントがインストールされてなかったことを意味する。これに関しては、後からJIS X 0213対応フォントを追加したa12（冒頭引用の実験ページ参照）は、これらの文字が問題なく表示できていることも傍証となろう。

●Android端末のフォントフォールバック

　ここで興味深いのは、結果がキャリアによってある程度揃っていることだ。例えば0面以外の文字（1）、（2）は、ドコモ端末はAQUOS PHONを除いて2字とも表示に失敗しているのに対し、auはすべて（1）だけ成功している。（5）の文字もほぼ同じで、auの製品はすべてこれを正しく表示できているが、ドコモの製品は不明だったAQUOS PHONを除き成功したものがない。これはキャリアによる何らかの対応策が、表示結果に影響していることを意味する。

　auはスマートフォンの製品展開（特にシャープ製端末）に当たって、標準的なフォントパッケージに新ゴR（モリサワ）を追加している[*2]。au端末における表示結果が一部ドコモと異なるのは、この追加フォントに起因すると考えられる。おそらくauとドコモにおけるフォントフォールバック[*3]は、それぞれ次のようになっているのではないか（図2、図3）。

図2　Android端末におけるフォントフォールバックの推測図（ドコモ）。平行四辺形は個々のフォントにおける符号位置を表す。ここでは2つのフォントのフォールバックを解説している。上に位置するフォントが優先表示され、そのフォントがサポートしない符号位置がある場合、下位のフォントが参照される

図3　Android端末におけるフォントフォールバックの推測図（au）。auの場合は新ゴRが追加され、これが最上位のフォントとなっているようだ。しかし（1）～（13）の漢字すべてがサポートできているわけでなく、一部はDroid Sans Fallbackにフォールバックしているように見える。なお、筆者がライセンスを所有してない関係で、図の新ゴRの表示は、新ゴMで代替してあることをお断わりしておく

　2つの図を比べると、スマートフォンでは後発であるauが、なぜフォントを追加したかが分かる。それはDroid Sansシリーズだけでは日本語表記に不安があるからだろう。もともと日本語のタイプフェイス・デザインを採用したDroid Sans Japaneseの漢字収録数は、JIS X 0208とほぼ重なる6,619字にすぎない[*4]。それを補完する役目を負うのが日中韓国語向けレパートリを持つDroid Sans Fallbackだ[*5]。ところが、これは中国語簡体字のタイプフェイス・デザインであるため、日本人には違和感が大きい（図4）。auが新ゴRを追加したのは、こうしたドコモ端末での不足を解消する目的があったのではないか。

図4　Droid Sansシリーズにおける新常用漢字の表示。ここに挙げた漢字は、すべて新しく常用漢字表に追加された漢字だ。比較のために、Mac OS Xにおける標準的なフォントであるヒラギノ角ゴProN、同じくWindows Vista/7におけるメイリオも掲載する。これらPC用フォントはJIS2004対応のデザイン（いわゆる康煕字典体）だが、Droid Sans Japaneseはその前のJIS90対応（略字体）のデザイン、そしてDroid Sans Fallbackは、いずれとも違う中国語簡体字のデザインである。なお、「喩」はJIS90の時点からいわゆる康煕字典体という、少々珍しいグループに属す

●問題が多いAndroid端末の日本語表示

　以上のようなAndroid端末の結果を、一言でまとめると「法定文字への対応不足」ということになるだろう。例えば常用漢字である（2）の文字を、ドコモ端末を含む全機種が表示できなかった。同様に（9）、（10）の文字も、常用漢字表で規定した字体で表示できなかった。つまり、図1にあるすべての機種は常用漢字表に対応できていない[*6]。さらに下図をご覧いただくと分かるとおり、人名用漢字でも多くの文字化けが見られる（図5）。

図5　Android端末における人名用漢字（一部）の表示結果。人名用漢字のうち、常用漢字の異体字（旧字体）212文字をツイートし、Mac OS XのSafari（上段）と、au製Android端末（IS03）のTwitter（下段）にて表示してみた。IS03では多くの人名用漢字が化けている。画面はau製端末だが、同じDroid Sansフォントを使うドコモ製端末でも、あまり結果は変わらないと思われる

　これらの文字は複数の頻度調査に基づいて選定されており、一定の科学的根拠を持つと考えられる[*7]。それら調査によれば、常用漢字表や人名用漢字といった法定文字は、日本語の語彙においては最も使用頻度が高いグループを構成している。多くの人が持つ携帯電話のような製品では、法定文字のサポートは必要と言えるのではないか。

　前回紹介したiOSの調査結果からは、日本の法定文字をサポートしようとする意志が伺える。世界共通の使いやすさと、国や地域固有の特性を両立させる努力は賞賛されてよい。一方で、Androidも同様に世界市場を想定して開発されているはずだが、残念ながら今回の結果は、iOSと対照的なものとなった。

　残念という意味では、実際の製品に仕立てた日本のキャリア達も同様だ。特にドコモは法定文字をよく知らずに開発されたであろうAndroidの標準フォントセット（Droid Sansシリーズ）を、ただ丸呑みして製品化してしまった。私は素朴な疑問を抱くのだが、ドコモは上掲のような日本語表示で、市場が満足すると思ったのだろうか？

　もう一方のauは、フォントを新規追加することで日本語表記の弱点を克服しようとした。その姿勢には好感が持てるが、ポイントがいささかずれているように思われる。なぜ日本市場に合わせて追加するフォントが、常用漢字表や人名用漢字をサポートしないで済まされるのか、少し不思議に思える。

　同様にJIS X 0213:2004（JIS2004）への対応ができていないことにも落胆させられる。ドコモ端末におけるデフォルト日本語フォントであるDroid Sans Japaneseも、そしてauが追加した新ゴRも、JIS2004より前の90JIS（JIS X 0208:1990）のデザインを採用している（前掲図4参照）。しかしJIS2004に対応しておけば、自動的に新常用漢字にも人名用漢字にも対応できたのだ。既にパソコンのOSは、2007年にはJIS2004対応を終えているのだが[*8]。

　このようなドコモ、auの両社に共通するのは、自国の言語政策に対する無関心と言える。一部では電子書籍の普及が進まない打開策として、スマートフォンに期待をかける見方もある[*9]。私も電子書籍の未来に期待する者の一人だが、言語政策にも注意を払わない会社の製品が、果たして快適な読書体験をもたらしてくれるのか、不安に思わないでもない。

●「内字のバラツキ」が外字を産み出す

　では、ここまでの結果を前々回から参照してきた内字・外字モデルに位置付けてみよう（図6）。

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

　Android端末の表示結果（図1）が分かりやすいが、ここで化けた文字はすべてUnicodeに収録済みの文字だ。したがって、もしもフォントが（1）～（13）の文字をサポートしていれば何の問題もなく表示できた。ところがそれができないことにより文字化けは起きた。つまり、ここで化けてしまった文字は図6での灰色の区分、「文字コード規格に収録されている／フォントに実装されていない」外字（1）ということになる。

　ここで注意すべきは、Android端末の場合、キャリアによって「内字」とする範囲が異なることだ。つまり、Android端末とPCとの間、あるいはiOS端末との間で化けるのは当然として、au端末とドコモ端末の間でも文字化けが起こるのである。一方でiOSはどうか。前回の結果を再掲しよう（図7）。

図7　iOSの調査結果

　Android端末と違い、ここで化けた原因はフォントではない。しかし、iOSで集中して化けたのは0面以外の特殊な処理を必要とする文字だ。つまりアプリケーション内で扱える文字の範囲（内字）の違いが文字化けを生んだと言える。言い換えればアプリケーション内の実装のバラツキにより、iOSの文字化けは起きている。iOSもAndroidも「実装のバラツキ」という意味では同じ外字（1）の仲間なのである。

●さまざまな所に広がる「内字のバラツキ」

　ここまでスマートフォンという、いわば旬のジャンルにおける「内字のバラツキ」に焦点をあてたが、この問題はスマートフォンに限ったものではない。例えば国税庁の国税電子申告・納税システム『e-Tax』で利用可能文字のリストを見てほしい（図8）。

図8　国税庁『e-Tax』における外字と内字[*10]。常用漢字表の字体が使えない

　ここでは常用漢字であるはずの（8）の文字は使用不可になっており、常用漢字ではない「頬」を使用せよと指定されている。つまり、国税庁のこのシステムでは、「頬」が内字で、（8）の文字は外字ということになる（じつはINTERNET Watchも同様）。

　見たところ、ここでの内字はシフトJISの範囲に収まるようだ。おそらくずっと以前に構築した当時の文字セットを大事に守っているうちに、化石化してしまったものと思われる。つまり、今や珍しい内字の範囲なのだが、送受信をともなう以上、他者にとっては「内字のバラツキ」に他ならない。多くのユーザーが文字化けに苦しめられている（この場合は納税や電子申告が受理されない）と想像できる。

　他にも、こうした例はいくらでも挙げられる。例えば7月13日、Twitterで日本語ハッシュタグがサービス開始された[*11]。非常に便利な機能なのだが、残念なことにハッシュタグに使える日本語の範囲がどうも特殊なようだ。長音記号や「・」「々」、そして図1で（1）の文字も使えないという報告がある[*12]。これなども別の言い方をすれば、Twitterにおける「内字のバラツキ」と言えるだろう。

●JIS X 0213第3水準までを「日本語の共通ミニマムセット」に！

　こうした状況は、Unicodeの普及とその大規模化がなければ起きなかったと思われる。大規模だからこそ、実装者はてんでにバラバラな範囲を実装できたのだ。しかしそれだけでは、このようなことにならない。日本においては、シフトJIS時代に内字であったJIS X 0208（漢字6,355字）の後継として、どの文字セットにするかという社会的合意が成立していなかったのだ。合意できる文字セットがあれば、ここまで内字はバラバラにならなかった。

　JIS X 0208の後継として作られたJIS X 0213（漢字10,050字）は、2004年改正からでも7年がたつが、パソコン向けフォントを除いて普及しておらず、後継たり得ていない。その結果こそが、ここまで述べた「内字のバラツキ」なのだ。

　こうしたトラブルは漢字ではリッチな環境であるPC同士では分かりづらい。しかし少し視点を変えるだけで、いくらでも目に入ってくる。前述の納税システムやTwitterはその一例であり、逆に裾野が広くなかなか目が届かないという意味で、深刻な問題をはらんでいる。

　これを避けるためには常に相手との「内字」を意識しながら送受信する必要があるが、それが完璧にこなせるほど知識のある人は少ない。つまり、多くのユーザーにとっては、いつ、どこで文字化けが起こるか分からず、もしも起きても原因がつかめない。ずっと以前、使える文字が少なかったシフトJIS時代と比べれば、好きなだけ漢字を使える私達は少しは幸せになったのだろう。しかし、このような文字化けと背中合せの暮らしが、本当の幸せと言えるのか。

　こうした状況を解消するためには、現在各所で行われている、文字セットを拡張する作業は、残念ながらあまり役に立たない。むしろ必要なのは逆の方向の作業だ。より小さな、しかしJIS X 0208よりは大きい、そして誰もが納得する、実装してもよいと思えるセットを考えること。もっとも、そうしたセットは既に存在している。JIS X 0213の第1～第3水準（7,614文字）だ。これを「日本語における共通ミニマムセット」にしてはいかがか。

　JIS X 0213のフル実装である第4水準までより2,436字も少ないので、スマートフォン等リソースに余裕のない環境にも優しい。その他にも常用漢字表は当然として、人名用漢字、康熙別掲字など、日本語でよく使われる漢字は、おおよそ第3水準まででカバーできる（全部とは言わない。例えばIBM拡張文字）。何より既にJISになっているので（JIS X 0213は部分実装を認めている）、過大な作業が発生しない。

　次回は図1の「外字（3）」、文字コード規格に収録されていないが、フォントには実装されている外字、具体的にはIVSについてについて取り上げたいところだが、申し訳ないが1回だけ寄り道させてもらい、別テーマをお送りしたいと思う。何が飛び出すかお楽しみに。

●追記

　原稿の執筆中に、さるところでKDDIの担当者に会える機会があった。さっそくこの原稿の内容を説明した上で、いくつか質問をしたいとお願いしたところ、メールを送ってもらえれば対応可能との返事をいただいた。そこで送った質問と、その回答が下記のものだ。回答をいただいたのは執筆後だったが、こうして見ると原稿での見方が裏付けられるように思える。お忙しい中、わざわざ対応くださったKDDI株式会社パーソナルプロダクト企画部Android企画グループの畑瀬泰博課長代理に深くお礼申し上げたい。

質問1：御社は日本の法定文字（常用漢字表、人名用漢字）をサポートする必要性を感じておられますか。

回答1：今後お客様からのご要望が多いようでしたら、積極的にサポートしていきたいと考えております。

質問2：新ゴRでJIS X 0213:2004をサポートすればこれらの問題はすべて避けられたのですが、なぜそうしなかったのでしょか。

回答2：搭載するフォントについては、端末メーカー様で判断いただいております。当社としてもお客様からのご要望が多いようでしたら、サポートするよう各端末メーカー様へ要求していきたいと考えております。

●注釈

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

[*2]……搭載されているフォントとその技術については以下を参照。モリサワ「KeiType」（http://www.morisawa.co.jp/biz/products/main/device/keitype/）

[*3]……前回も述べたが、現代における多くの実装が、フォントの不備を補うフォントフォールバックと呼ばれる機構を備えている。これはあるフォントがサポートしていない符号位置があった時、それをサポートしてる別のフォントに表示を代替させる仕組みだ。つまりフォントが互いに補完し合うことで、全体としてサポートする符号位置を増やす機構だ。Android OSでもこれが備わっている。

[*4]……@2SC1815J氏が次のような貴重な資料を公開している。『DroidSansJapanese.ttfのUnicodeコードポイントリスト』（http://123.writeboard.com/tqg0zxp8o6uk45j2/login?password=DroidSansJapanese）、『DroidSansFallback.ttfのUnicodeコードポイントリスト』（http://123.writeboard.com/sgolcuv5dh87bj2e/login?password=DroidSansFallback）、『MTLmr3m.ttfのUnicodeコードポイントリスト』（http://123.writeboard.com/ygzl0ojbdr16pthv/login?password=MTLmr3m）

[*5]……Droid Sans Fallbackがサポートする文字コード規格は、日本語がJIS X 0208、中国語簡体字がGB 2312、中国語繁体字がBig 5、韓国語がKS C 5601。全部で43,000以上の文字を収録するという。 “Droid Fonts Overview” (http://www.droidfonts.com/droidfonts/)。この件、@2SC1815J氏よりのご教示（https://twitter.com/#!/2SC1815J/status/89263842638573568）。

[*6]……図1の中で最も古いIS03の発売は2010年11月26日だ（リリース：http://www.kddi.com/corporate/news_release/2010/1116a/index.html）。一方で常用漢字表を改正する内閣告示訓令は、その4日後の11月30日（http://www.bunka.go.jp/kokugo_nihongo/kokujikunrei_h221130.html）に出ている。この点からIS03が改正常用漢字表に対応するのは無理と思われるかもしれない。しかし、改正常用漢字表の答申自体は半年前の6月7日にされていた。当時多くの新聞が詳細を報じていたし、答申のPDFも入手可能だった（http://www.bunka.go.jp/oshirase_other/2010/kaitei_jyoyokanji_nyusyu.html）。

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

[*8]……マイクロソフトはWindows Vista（2006年11月発売開始）から、アップルはMac OS X 10.5 Leopard（2007年10月発売開始）からJIS X 0213:2004に対応している。

[*9]……サンケイビズ「電子書籍、先行き“読めず”　専用端末・コンテンツが伸び悩み」（http://www.sankeibiz.jp/business/news/110622/bsj1106220503000-n1.htm）

[*10]……国税庁「利用可能文字一覧」（http://www.e-tax.nta.go.jp/tetsuzuki/mojiichiran.pdf）。なお、「e-Tax」（http://www.e-tax.nta.go.jp/index.html）も参照。

[*11]……『＃日本語ハッシュタグ』Twitterブログ、2011年7月13日（http://blog.jp.twitter.com/2011/07/blog-post.html）

[*12]……『#日本語ハッシュタグ で使える文字、使えない文字』Togetter（http://togetter.com/li/161061）