日本国内における電子機器での文字使用には，いろいろな問題点が存在している。文字コードを巡る周辺状況の経緯や動きに対して，WindowsやMac上でUnicodeをベースとしての実装はどう進んでいるのか，Javaなどのプログラム言語の開発環境を例にとった現在の日本の文字コードの混乱，また新聞業界の文字セットなどの動向はどうなっているのだろうか。
　PAGE2004グラフィックトラック【B5】では，文字コードの規格開発や実装の最前線で活躍する
　■ジャストシステムデジタル文化研究所　小林龍生氏（モデレータ）
　■マイクロソフトプロダクトディベロップメントリミテッド　阿南康宏氏
　■Apple Computer, Inc.　木田泰夫氏
　■NTT未来ねっと研究所　風間一洋氏
　■共同通信社　山本容士氏
からそれぞれお話を伺った。

■JIS X 0213:2004の実装と標準化動向

　現状の問題意識として2点考えられる。1つは，2004年2月20日にJIS X 0213:2004ということで，JIS X 0213が改訂される。その改訂も含め，JIS X 0213を各ベンダがどのように実装していったかという点である。
　文字コードを作る人間は，文字コード標準を作ってしまうとそれで終わりで，世間に受け入れられているかどうかは関知しない立場に立つことが多いが，それでうまくいくことは稀である。やはり，作った標準がどのように世の中に受け入れられ，それがどのような影響力を持つかということも見届けたい。

　もう1点は，JIS X 0213制定の頃から，国語審議会に代表されるような，日本の言語行政をどうしていくか，また工業標準としてのJIS情報交換用符号化文字集合，国際的に非常に影響力を持つようになってきたUnicode，ISO/IEC10646，UCSがどのような関わりを持っているのかという点である。
　1996年に第21期国語審議会が始まり，「表外漢字字体表」に至る議論が始まった。1999年にはJIS X 0213のレパートリーがほぼ固まり，JIS X 0213の中でそれまでのUCSに含まれていなかった文字が260文字程度あったが，それをExtension-BやCompatibility Ideographsに追加するような議論が行われた。

　2000年1月にJIS X 0213が制定され，2000年12月には国語審議会「表外漢字字体表」が出された。そして，2001年4月には，ISO/IEC10646の2000年版に相当する翻訳規格であるJIS X 0221-1:2001が発行された。この5年間に，随分大きな動きがあったということがわかる。
　それを受けて，JIS X 0213をどのように国際規格のUCSと折り合いをつけていくか，JIS X 0213と「表外漢字字体表」の関係をどのように整理するかという議論が始まった。長くかかったが，結果的に2月20日にJIS X 0213の改正版，JIS X 0213:2004が発行されることになった。
　変わった点は簡単に言うと3つある。1つは168文字の字体を変更した。コードポイントを10個追加した。また，JIS X 0213とUCSとの対応関係を決めたことである。

■表外漢字字体表とWindows上の利用環境

　JIS X 0213:2004改正のポイントは，印刷標準字体1022字および簡易慣用字体22字のJISへの対応の要旨であり，
　1. JIS X 0213もしくはJIS X 0221（Unicode）を使用した場合，表外漢字字体表に掲げられた1022字の印刷標準字体がすべて利用できる
　2.JIS間の相互運用性を維持するために：
　　JIS X 0213に，「UCS」互換文字を追加する
　　JIS X 0208には，文字を追加しない
　3.JIS X 0212には追加も変更も行わない
　4.JIS X 0221には追加も変更も行わない
　5.JIS X 0208およびJIS X 0213の包摂の範囲は変更しない
である。

　これで表外漢字字体表をどのようにJISに反映したかという方針が決まり，そこで，Microsoft社はそれをどのように実装すべきと顧客から求められているかを理解した。
　表外漢字字体表の前文を読むと，「平成12年に現行JIS規格0208を拡張するために制定されたJIS X 0213において，括弧内の字体，（鴎）（祷）（涜）の康煕字典体が現時点ではワープロ等から打ち出せないという現状は変わっていない」とある。1998年以降のWindowsは，すべてこの3文字を出すことができる。しかし，これはまだ実装が十分ではなかったのだということである。

ユーザの要求として，
　1.情報機器に印刷標準字体が標準的に搭載
　2.意識することなしに印刷標準字体がまず最初に打ち出される
　3.印刷標準字体が文字化け，字体化けをすることなく文書中に表示できる
　4.作った文書の印刷標準字体が文字化け，字体化けをすることなく印刷できる
　5.作った文書の印刷標準字体が文字化け，字体化けをすることなく情報交換できる
の5つがある。
　メーカーとしてMicrosoft社がやるべきことは最初の4つであり，それを満足する個々のOS，アプリケーション，情報機器の提供である。5.は各社単独では実現できない。

次期，Windowsでの対応方針のまとめとして，
　1.エンコーディング
　　表外漢字字体表の印刷標準字体および簡易慣用字体はUnicodeで対応
　2.日本語システムフォントのアップデート
　　MSゴシック，MS Pゴシック，MS UI Gothic
　　MS明朝，MS P明朝
　3.IMEの対応
　4.関連技術情報の開示，パートナー各社との連携
を打ち出している。

■Mac OS Xと文字コード

　最近の文字コードを巡る状況を一言で表すと，UnicodeアプリケーションやXMLなど国際規格での採用と応用例の増加など，Unicodeへの着実な流れがある。
　Apple社は，JIS X 0213をUnicode上で実装した。つまり，どのアプリケーションでもUnicode対応ならJIS X 0213をすぐに使うことができる。JIS X 0213で定義されている独自の文字コード，例えばShift-JIS形式，EUC，ISO2022形式等は変換テーブルを通じてサポートしている。ただし，変換テーブルはJIS X 0208の時代と違い，かなり重要性が減少している。

　JIS X 0213追補は，対応済みである。JIS X 0213の独自エンコーディング側から見ると複雑に見えるが，Unicode側から見ると0213に含まれていなかった，既にあった10文字が含まれたというだけである。また，規格の一部ではないが，例示字形が変わった。それらの例示字形も，すべてAdobe-Japan1-5でカバーしている。つまり，ヒラギノの中に既に存在している。
　Unicodeを利用する際の基本をなす考え方について，注意点がある。それは，データと，そのデータが実際に表示される形は1対1に対応しないことである。例えば，身近な例で言うと，日本語の長音，括弧記号などは，横書きする場合と縦書きする場合，同じ文字でも形が違ってくる。

　これは，データつまり文字コードが論理的意味を担い，それがどう表示されるかということと分離できる。この考え方は，従来の文字コードでも暗黙のうちに一部採用されていた。例えば，JIS0208では長音は1つで，縦書き用の長音と横書き用の長音があるわけではない。
　Unicodeではこの考え方にキャラクタ・グリフモデルという名前を表して，設計の基礎としている。Unicodeを利用したシステムを設計する際には，この考え方を常に意識する必要がある。TureTypeやOpenTypeの仕組みの中にシーマップというテーブルがあるが，これもその考え方に基づいて設計されている。
　キャラクタ・グリフモデルに基づくと，フォントが実装するものは，すべからく文字ではなくグリフであるということになる。つまり，フォントはグリフを実装する。どのようなグリフを実装すればよいかという基準になるのがグリフセットである。

　漢字の異体字は，キャラクタ・グリフモデルの考えではうまく処理できない例がある。つまりコード化の必要がある。異体字については，どこまでがキャラクタなのか，どこまでがグリフなのかという境目が，用途により明確ではない。
　現在から将来にわたっての課題は，文字規格のあり方である。文字コード規格に携わる人は，文字規格を作るとき，Unicode，その他の国際規格との整合をまず第一に考えてもらいたい。例えば，JIS X 0213ではUnicodeで合意されていないコードポイントが括弧付きで示されていたり，また文字の定義の矛盾などが見られる。独自のコードなど作らずに，文字の同定，使われ方の記述をしっかり行ってほしい。

　もう1点は，Unicodeのインプリメンター側の問題である。これはUnicodeを正しく利用しようということに尽きる。1つの例は，私的利用領域，プライベートユースエリアの無責任な乱用が見られる。
　Unicodeというのは，他のISOが管理している規格に比べて，ある意味，私企業が影響力を及ぼしやすい存在である。会費を払えば加わることができ，投票権利が得られるからである。しかし，日本からUnicodeに参加しているのはジャストシステム1社で，とても情けない状況である。日本の企業は，自分の持っている影響力をよく考えず，無責任なUnicodeの実装をしている例が見られるので，改善する必要がある。

■Java言語とUnicode

　多言語情報検索や分散情報検索の研究をするとき，UNIXで作ったものをWindowsにポーティングする等，限られた予算の研究セクションは大変である。Javaを使用することにより，1つプログラムを書けばWindows，Max OS，UNIX上で動くということで，いち早くJavaを利用して研究している。
　ただし，初期の頃のJava言語自体は，Unicodeを使っていると言えば，これですべて終わりという理解で作られていて問題が多かった。その後，ISOのJavaSGができたこともあり，最終的にSun Microsystems社が作ったJavaコミュニティープロセスで，実際にJavaの仕様を作成するようになった。

　Java言語というのは，1つプログラムを書くことにより，いろいろなOS上で動く言語と考えればよい。この言語の特徴は，言語処理系を作る時点で国際化を考えていたと言われている。即ち，基本的な文字の扱いを，Unicodeそのものにしてしまった。
　C言語等では，最初の設計時点ではしっかり決めずに，アスキーさえ使えればよい，特定の文字コードに依存しないように作ることがあったが，Java言語はUnicodeに完全に依存するデザインをとった点で，比較的先駆的な言語である。現在では，そのようなアプローチをとっている言語はかなり増えてきている。

　当時，キャラクタを表すのに16ビットあれば十分で，Unicodeの65,536文字は表せると考えた。このときにはコードユニットとコードポイントが一致していた。
　ソースコードも，アスキーだけでなく，任意の文字コードで書いてよい。ただし，例えば英語だけしか通らない環境では，UnicodeのバックスラッシュUでUnicodeのコードポイントを16進数で書けば，どのような文字でも使えるようになっていた。
　また，内部で行うプログラムのテキスト処理は，すべてUnicodeである。例えば，日本語のShift-JISや日本語EUCがあっても，それをUnicodeに変換し内部ではすべてUnicodeのテキスト処理を行い，出力するときに再び，日本語EUCに戻すということを行っている。

　特にJavaで特徴的なのは，いろいろなプラットフォームで動くということである。したがって，プラットフォームによってUnicodeの扱いが微妙に異なることがある。例えば，日本語のある文字をどのコードポイントに割り当てるかが違っている。
　また，ネットワーク系のサーバ等にも使われているので，この扱いの差が一番問題になりやすいプログラムは，Javaで書かれたものになる。他の場合，例えばWindowsで閉じている場合は全然問題が起こらない。

■新聞業界の文字

　共同通信社は，全国多々ある加盟新聞社に記事を配信している。その際，どのように伝達するかということが一番基本になる。実装というよりは，どう相手に伝えるかということから，今回U-PRESSを考えた。新聞社に配信するという観点から，新聞社に送る共通コードという位置づけである。U-PRESSのコード体系，文字セットを使って，共同通信社の内部では2002年から動かしており，新聞社に配信を始めたのは2003年12月からである。

　各新聞社には，それぞれ昔からのやり方があり，いろいろなところから情報を集めている。昔は職人が鉛を溶かして組版して文字を作っていたが，システム化が進み写真写植からフィルム系に変わってきた。熱い鉛をホットと言っていたが，それに対してシステム化したものはCold Type System（CTSシステム）と言っている。そこで使われているコードは新聞社ごとに違っていたり，導入するシステムメーカーのコード体系を使っている。

　新聞社によっては文字の扱い方が違うため，それが問題点になる。各新聞社は編集上の基準を持ち，読みやすくすることを第一前提に考えている。基本は常用漢字で，記述が表せないものは康煕字典体を使うが，わかりやすくするために，交ぜ書き等，言い換えして新聞を作っている。しかし，そこでも各社考え方が違っているという実情がある。
　また，従来はペンと紙を使って人間が意識していたものが，システム化が進み，ワープロやパソコンが入ってきて，文字の形が大切になってきた。常用漢字の範囲が主ではあるが，どうしてもない文字が出てくる。主に地名，人名などの固有名詞である。これは特定した文字の形を使わざるを得ない事情がある。その点が原因で，システムは導入されたが，ユーザ側がそれに追いついていけない問題点がある。

　システムが抱える問題としては，文字数が少ない点がある。基準はJIS X 0208であるが，記述を変えたいものや，特定の文字を使いたいものがある。それは今まで各社が外字処理をしていたが，情報伝達するためには，より多くの文字が必要になる。
　各新聞社が導入しているシステムはマルチベンダで，処理形態によって導入するシステムのメーカーが違う。例えば，まだ78JISを採用している新聞社が新しいシステムを入れると，それが83JISベースになっているので，社内で文字が変わって混乱を起こしている。これが新聞社の中であまり気づかれていないということが一番問題である。
　それを解決するために，共同通信社は各新聞社と取り決めをして，JISの規格ができる前からコードと文字を決めて配信していた。

　K-JISとは，JIS X 0208をベースにして，それまで使っていた文字をそこに割り当て，コード体系だけJISを採用したものである。これが，新聞社側でもなかなか管理されず，配信する共同通信社側との間でも，文字コードがうまく伝わっていないので，U-PRESSを考えるときに，システムを全面公開することにした。
　U-PRESSでは，新聞社からの要望をなるべく吸収していこうとした。それは，特殊な文字やコードを使わず，文字数を増やすことである。なるべく標準的に，受け手側でもわかりやすいようなコード体系，文字セットにするのである。

　U-PRESSは，UCSの基本多言語面だけを使って表現しようというものである。これは新聞社側の事情によるが，今まで2バイト系で動いていたので，他バイト系の処理をすると影響が大きい。そこで，2バイトで表せる基本多言語面だけで行うことになった。
　そこに網羅する文字集合は，JIS X 0201，JIS X 0208は当然，JIS X 0213も入れなければならない。標準化に向かうことで，既に基本多言語面に入っている補助漢字のJIS X 0212も入れておく。JIS X 0213の場合は，印刷標準字体がかなり含まれている。新聞業界で使っていたCO-59，CO-77あるいはK-JISは，康煕字典体が数多く含まれているので，移行措置として影響が少なくなるように，先取りした形で印刷標準字体をセットしてある。また，それ以外に，新聞で使う外字類がある。

　新聞業界での共通コードという位置付けでU-PRESSという文字セットを作ったのと並行して，フォントメーカーに新聞各社で使用するU-PRESS文字セットのフォント作成を依頼した。これは新聞各社と共同通信社がNewsML化，文字コードの変更という問題に向けて業界全体で取り組んだことで，U-PRESS対応フォント化までたどり着けた。
　いずれはJISの第3，4水準などの文字も標準で使えるパソコンが出回るだろうが，先んじる形でU-PRESSフォントという市販品ができたことで，実装段階までは解決したとも言える。
　今後はより標準的なものに近づけることを念頭に，各アプリケーションソフトの供給側も含めて広がりをもたせられれば，現在の共通コードに代わるものになり，業界以外でも自由なやりとりが可能になるだろうと考える。

2004/03/14 00:00:00