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

携帯電話にもUnicode実装を促す「改定常用漢字表」


互換規準の2文字について

 今回は文字コードから見た「改定常用漢字表」の問題点を考えることにする。まず、図1を見てほしい。改定常用漢字表で追加された196字種のうち、この4文字が現行JIS X 0208との間で、いささか厄介な問題を発生させる。

図1 改定常用漢字表に追加される196字種のうち、現行JIS X 0208で表現しようとすると問題が発生する4文字。字形はそれぞれの原本から複写した

 図1のうち、上の2文字(互換規準)と、下の2文字(包摂分離)については問題が異なる。まず、上の2文字について。これらについては、規格の上からはJIS X 0208は左側の改定常用漢字表の字体を、包摂の範囲外としている。だからこれらの文字は、JIS X 0208では表現できないことになる。

 ただしJIS X 0208には、これら2文字を使うための例外規定が盛り込まれている。それが「6.6.4 過去の規格との互換性を維持するための包摂規準」(通称:互換規準)という条項だ。これは図1上にある2文字を含めた全29文字について、図2左側の略字体(規格ではA字体)と、右側のいわゆる康煕字典体(同じくB字体)を排他的に切り替えて使うための規定だ。

図2 JIS X 0208で規定された互換規準の29文字(『JIS X 0208:1997』日本規格協会、1997年、P.22)。赤枠内が改定常用漢字表の2字

 この互換規準は、1978年のJIS X 0208初版を非互換変更した1983年改正の尻拭いというべき規定で、1997年改正で加えられたものだ。ここでは「排他的」というのがミソとなっている。B字体は1978年初版の字体だ。これをA字体に変更したのが1983年改正だった。しかし双方は形の違いが大きく、1997年改正において本来してはいけなかった変更と考えられた。これに対処するには改めてB字体を追加し直すのが筋だ。しかしこの時の改正では当初から文字セットの変更はしないことが決まっていた。そこで苦肉の策として、使う際には29文字のセットごと、排他的に一方を実装すると定めた(なお、「叱」に関しては少し複雑な事情があるのだがここでは触れない。『JIS X 0208:1997』P.276を参照)。

 もっとも、現状ではこの互換規準の実装は一般的とは言えない。たとえばJIS X 0208を基本とした文字セットのうち、最も普及している実装が携帯電話のシフトJISだ。そこでは、かつてあるメーカーが一部の機種に互換規準を適用したのを除けば、ほぼすべてがA字体、つまり図1右側の略字体を実装しているのが現状だろう。

 もともと改定常用漢字表で追加された196字種には、図1以外にもJIS X 0208の例示字体と字体の違いがあるものがいくつも含まれる。したがって携帯電話が改定常用漢字表に準拠しようとした場合、これらについてはフォントの修正が必要になる(図3)。

図3 改定常用漢字表で追加された196字種のうち、JIS X 0208例示字体と字体の違いがあるもの。字形はそれぞれの原本から複写した。なお、ここでは字形の違いは取り上げていない

 しかし修正が必要な文字はそれだけにとどまらない。図1上の2文字を変える場合、互換規準で規定された残り27文字も一緒に修正しないと、JIS X 0208には適合しないことに注意すべきだろう(ただし、現行JIS X 0208は空き領域への文字の割り当てを原則禁止しており、この点で絵文字をはじめ多くの外字を割り当てている携帯電話のシフトJISは、互換規準以前に適合していないことになるのだが)。

情報交換すると「?」になってしまう「改定常用漢字表の字体」

 続いて図1下の2文字については、JIS X 0208は規格の上では図1下にある左右の字体を包摂している(「剥」は包摂連番167、「叱」は同じく77)。一方でJIS X 0208を拡張する規格、JIS X 0213:2004(2004年改正版。以下、JIS X 0213)では、これを包摂分離して、改定常用漢字表と同じ字体を別面区点に収録している。

 ここまで述べたことが、シフトJISを実装する携帯電話にどのような問題を発生させるか、図3に掲げた文字も含めて考えてみよう。携帯電話では図1下の2文字に関しては、右の「JIS X 0208の例示字体」だけが使えるフォントを実装している。また、前述のように図1上の2文字もほとんどは互換規準を適用していないので、結果として「JIS X 0208の例示字体」だけが使える。図3の文字も「JIS X 0208の例示字体」の方を実装している。

 つまり現代において情報機器の代表格とも言える携帯電話は、ここまで取り上げてきたすべての文字について「改定常用漢字表の字体」を表示できないということになる。

 もっとも、本当の問題はそれにとどまらない。ここまでは携帯電話でのフォントの実装、つまり表示の問題を取り上げたが、「情報化時代」であるからにはフォントのデザインだけを取り上げても意味はない。むしろフォントに割り当てられた符号の方が問題となる。符号はさまざまな実装環境との間で情報交換を繰り返す。そこでは旧来のような印刷文字とは違う振る舞いを見せることになる。そこで、ここまで述べた携帯電話に代表されるシフトJISが、JIS X 0213を実装した環境と情報交換した場合を考えてみたい。

 まず双方の実装環境が、図1や図3の文字をどう実装しているのか確認しておこう。Windows Vista、Windows 7、Mac OS X 10.5以降などでは、2004年に改正した現行JIS X 0213を文字セットとして実装している(符号化方法はUnicode)。JIS X 0213では図1にある字体をすべて別々の面区点位置に収録しているから、これらの環境では「改定常用漢字表の字体」と「JIS X 0208の例示字体」のそれぞれを使い分けることができる。また図3の文字に関しては、符号位置はそのまま、フォントのデザインを「JIS X 0208の例示字体」から「改定常用漢字表の字体」に変更することでJIS X 0213に対応している(逆に言えば図3「JIS X 0208の例示字体」は表示できない)。

 一方で、シフトJISを実装する携帯電話はどうかというと、前述したように図1や図3の文字の文字は、すべて「JIS X 0208の例示字体」を実装している。

 それでは、こうした状況でJIS X 0213の文字セットを実装した環境と、シフトJISを実装した環境との間で情報交換をするとどうなるだろうか。実際に図1と図3の文字を、Mac OS X 10.5からKDDIの携帯電話(W56T)にメールしてみた(図4)。

図4 Mac OS X 10.5(上)から図1の左右の字体、および図3の文字を、KDDIの携帯電話(下)にメールとして送信した

 KDDIの携帯電話は、図1の文字に関しては「JIS X 0208の例示字体」の方はそのまま表示された(図4下、1行目)。しかし「改定常用漢字表の字体」は「?」に化けてしまった(同、2行目)。つまり、符号化不可能な符号が送信されてきたので、解釈不能として「?」を表示したわけだ(図5)。図3の文字に関しては「JIS X 0208の例示字体」の方が表示された(同、3行目以降)。

図5 「改定常用漢字表の字体」はJIS X 0213の実装環境では符号位置を持つ。しかしシフトJISの実装環境では符号位置がないので「?」に置き換えられてしまう

 この実験から分かるように、携帯電話に関しては、図1や図3で掲げた改定常用漢字表の字体を表示できないというだけでなく、図1「改定常用漢字表の字体」をメールなどで送信すると、意味不明な文字に置き換わってしまう。これが現状だ。

改定常用漢字表はUnicodeへの移行を促す

 では、こうした問題点について改定常用漢字表はどのように考えているのだろう。漢字表の冒頭にある「表の見方」には「付」として、以下のような一文が付けられている。

情報機器に搭載されている印刷文字字体の関係で,本表の掲出字体とは異なる字体(中略)しか用いることができない場合については,当該の字体の使用を妨げるものではない。
『改定常用漢字表』P.2)

 つまり、現に図1および図3の右側の略字体を実装している実装環境、たとえば携帯電話などは、あえてフォントを変更したりしなくてもよいと言っている。これによって、図3にある文字に関しては、ひとまず心配する必要はなくなる。

 ただし図1に掲げた文字に関しては問題が残る。メールなどで図1左の「改定常用漢字表の字体」を受信すれば、図4のように「?」になってしまうからだ。つまり画面表示という意味だけからは「当該の字体の使用を妨げるものではない」という記述でよいかもしれないが、情報交換を繰り返す「符号化文字」という性質を考えれば、これで問題は解決しないように思える。

 これらの字体が常用漢字表に入れば、今後は学校で教えるようになるなど、格段に使用範囲が広くなる。そうなれば使用頻度も高くなるだろうし、字体の区別も厳しくなる、メールで使う機会も増えるだろう。そうした意味からも、何らかの対処が必要になるはずだ。

 ユーザーの側からこの問題を根本的に解決するには、シフトJISのように片方の字体だけを使える符号化方法から、Unicodeのように複数の字体を使用可能な符号化方法に移行することだ。同時に2004年に改正した現行JIS X 0213の文字セット(フォント)に対応することも必要だ。

 前述したWindows VistaやWindows 7、Mac OS X 10.5以降などのように、UnicodeとJIS X 0213を組み合わせた環境であれば問題は起きない。その意味から改定常用漢字表は、シフトJISからUnicodeへの移行を促すものと言えるだろう(実はこの記事自体もシフトJISで符号化されている。編集部がこの事態にどう対処するのか、執筆者として興味を持っている)。

 もっとも、移行には時間もかかれば金もかかる。この不景気では簡単に移行するわけにもいかないのではないか。これについて、安岡孝一氏(京都大学)は『新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能』(『日経コンピュータ』2009年12月9日号)で、図1右「JIS X 0208例示字体」を許容字体とすることを提案しているが、確かにそれも一案だろう。こちらも許容字体になれば、現在の携帯電話で符号化できない改定常用漢字表の文字が、一応はなくなるからだ(許容字体については次回詳述)。

 とりわけ「叱」については「凸版調査(3)」で略字体が1837位、いわゆる康煕字典体が2168位と、むしろ略字体の方が頻度が高いことが分かっている(『漢字出現頻度数 順位対照表(Ver.1.3)』P.37、P.44)。

 今回の改定では追加字種の字体として、いわゆる康煕字典体を採用した根拠の1つに、これが「最も頻度高く使用されている字体」であることを挙げ、その一例としてここで問題になっている「頬」[訂正1]の頻度調査結果を掲げている(『改定常用漢字表』P.(13))。しかし、「叱」に関しては、明らかにこれに当てはまらない。社会的慣用という意味からは、略字体の「叱」も十分に慣用されていると言える。その意味からも、「叱」については何らかの形で略字体の方も表内字として処遇すべきと思える。

 ただし、たとえ図1右の字体を許容字体とした場合でも、それは表示における問題を解決するだけということは理解しておいた方がよい。図4のようにシフトJISで表現できない符号を外部から送信された場合には対処しようがない。やはり根本的な解決策としては「複数の字体を使用可能な符号化方法」に移行するべきだろう。

 以上、今回は文字コードから見た問題点を説明した。次回は第2次試案に焦点をあて、第1次試案との違いを詳しく説明したい。前回・今回は具体的に挙げなかった追加196字や、その示し方の変更なども次回説明することにしよう。

修正履歴

[訂正1]……改定常用漢字表』P.(13)で例として挙げられているのは「剥」ではなく「頬」だった。お詫びして訂正します。(2009/12/21)


今回の改定では追加字種の字体として、いわゆる康煕字典体を採用した根拠の1つに、これが「最も頻度高く使用されている字体」であることを挙げ、その一例としてここで問題になっている「剥」の頻度調査結果を掲げている(『改定常用漢字表』P.(13))。


今回の改定では追加字種の字体として、いわゆる康煕字典体を採用した根拠の1つに、これが「最も頻度高く使用されている字体」であることを挙げ、その一例としてここで問題になっている「頬」の頻度調査結果を掲げている(『改定常用漢字表』P.(13))。


関連情報

2009/12/17 14:00


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