最後の提言 シフトJISをいかに軟着陸させるか



加藤弘一

JIS X 0213の問題点

 JIS X 0213の規格票が間もなく店頭に並ぶようだが、昨年来、「月刊ほら貝」の方でお伝えしてきたように、JIS X 0213の最大のセールスポイントだったシフトJISの隙間を使う符号化方式は正式規格化が見送られ、参考規格にとどまった。

 大まかに言うと、文字コードは文字セットと符号化方式からなる。文字セットが胴体だとするなら、符号化方式は手足にあたる。JIS X 0213は生れ出る前に手足をもがれたに等しい。なぜ、こんなことになったかといえば、『四つの悪夢』などで繰りかえし指摘してきたように、隙間方式実装は利点が大きい反面、副作用も大きいからである。特にフォントを取りかえることのできないiモードの文字化けは防ぎようがない。

 JIS X 0213のもう一つの問題点は「高」、「間」のような社会的必要度の高い漢字が抜けていることである(「高」は法務省の『誤字・俗字一覧』が許容している155字の俗字に含まれているし、「間」は常用漢字の康煕字典体であり、どちらも戸籍に使うことができる)。この2字をふくむWindowsの機種依存文字の漢字360字のうち、JIS X 0213では85字ほど落ちており、残っている隙間にははいりきらない。

 これ以上増やすとなると、一部で取りざたされているように、「半角カナ」の領域を使わざるをえない。「半角カナ」は今、現在、使われており(iモードでは特に)、ここを転用する影響ははかりしれない。「半角カナ」領域は絶対につぶすべきではない。

 シフトJISはさまざまな製品が勝手に機種依存文字を追加しているが、パソコン通信時代以来、機種依存文字を使うべきではないというコンセンサスがネットワーカーの間に浸透しており、幸い、これまでのところ、さほど深刻な事態にはいたっていなかった。

 また、機種依存文字の位置が比較的分散しており、「見えない文字化け」ですんでいたことも、不幸中の幸いだった。パソコン通信などでも「見えない!」とか「豆腐になった」という苦情はよく目にしたが、「見える文字化け」となると、NEC記号とマッキントッシュ記号のバッティングくらいだったような気がする。

 ところが、JIS X 0213のシフトJIS実装は、隙間をほぼ埋めつくしているので、99%「見える文字化け」になる。

 もし、JIS X 0213の隙間方式にJISのお墨付がついていたとすると、文字化けの起こるWWWページを堂々と公開したり、フォーム入力による電子取引で文字化けが頻発するという事態がもちあがったわけで、大変な混乱がおきていたと思われる。日本工業標準調査会の英断を評価したい。




2年間のモラトリアム

 JIS X 0213の文字はユニコードから使うようになるわけだが、ユニコード未収録の400字近い漢字は今後の収録を待たなければならない。アイヌ語を表記するための「か゜」のような仮名は、ユニコード側が収録に反対しているので、「か」+「゜」という合成で出さざるをえず、OSに文字合成機構が実装されるまで使えないだろう。結局、JIS X 0213の文字セットが完全に使えるようになるのは2002年ぐらいだろうと思われる。

 この間、各ベンダーはユニコード化を大車輪で進めるだろう。

 ユニコードは「多言語処理はどこまで可能か」で指摘したように、完全な多言語処理は無理にしても、日本語とアルファベット文化圏の共存といった限定された多言語処理には使える。

 漢字の数にしても、2000年中には全貌が明らかになるという拡張Aと拡張Bで相当な僻字まで収録されるようであるし、異体字についても、これまで封印されてきたCJK互換漢字にJIS X 0213の異体字がはいったことで、収録に道が開かれた。台湾がかねて収録を求めていたCNS 11643の異体字など、相当数の漢字がCJK互換漢字としてはいると予想される。

 CJK互換漢字は、漢字文化圏の多言語処理をする上で、将来、問題となる可能性があるが、目先のことだけでいえば、ユニコード化の流れは決定的である。CJK互換漢字と結合音節文字の問題が浮上する時まで、ユニコードの天下がつづくのは間違いない。

 問題はシフトJISである。最近はレガシーフリーが流行語になっているが、ハードウェアのレガシーフリーは実現できても、ソフトウェアのレガシーフリーやデータのレガシーフリーは簡単ではない。ソフトウェアは5年ないし10年のタイムスパンで見るなら、不可能ではないかもしれないが、データとなると絶望的である。そもそもデータとはレガシー(過去の遺産)そのものではないか。

 2000年紀をむかえ、文字コードの世界でも大きな変動が起きようとしているが、今、もっとも緊急に考えなければならないのは、シフトJISをいかに軟着陸させるかだと思う。




シフトJISをいかに軟着陸させるか

 一番簡単で望ましい解決法は、なにもしないことである。シフトJISは現状のまま凍結しておき、新しいデータはユニコードで作成するようにする。しかし、二年後、すべてのソフトウェアがユニコード化されているとは考えにくい。その場合、JIS X 0213を隙間方式で使いたいという要望が出てくる可能性はある。

 では、どうすべきか?

 わたしが注目するのは、南堂久史氏がかねてから提唱されている文字化けの起こらないシフトJIS拡張法である。もちろん、すべての機種で文字化けが起こらないようにすることなど不可能であるが、もっとも普及しているWindowsとMS Dosで文字化けが起こらないように配慮した点は傾聴に値する。南堂提案は、もっと早くから真剣に議論すべきだったと思う。

 Windows外字が同じ文字を二重に収録している点の解決法など、南堂提案には周到な工夫が見られ、勉強になるが、ただ、すべての点で南堂氏と考えを同じくするわけではない。拙案では、あくまでつなぎの文字コードとして、保留領域を多くしている。

 そこで、南堂提案をもとに、わたしなりの案を練ってみた。「iWinコード」という名称を考えたので、「iWinコード試案」とでも呼んでもらえればと思う。


iWinコード試案

  1. Windowsの機種依存文字をすべてそのままの位置で収録する(南堂私案のように、IBM外字を太字にするという工夫も考慮すべき)。
  2. iモード絵文字をすべてそのままの位置で収録する。
  3. Windowsの外字領域のうち、最初の376字分(第一バイト0x80〜81)はユーザーが外字を置いている可能性が高いので、保留領域とする。
  4. JIS X 0213の文字セットのうち、地名・人名典拠の漢字をすべて収録する。
  5. 法務省が『誤字・俗字一覧』で許容している俗字をすべて収録する。
  6. 常用漢字表に対応する正字(いわゆる康煕字典体)のうち、JIS X 0208の例示字体にない字体をすべて収録する。
  7. 国語審議会が答申する予定の『常用漢字表表外字字体表』のうち、JIS X 0208の例示字体にない字体をすべて収録する。
  8. あまった文字番号は空けておくが、その際、シェアの比較的高いシステムの機種依存文字の文字番号を優先的に空けるように配慮する。

以上はあくまで思いつきを書いただけだが、シフトJISの今後を考える議論のきっかけとなれば幸いである。



Copyright 2000 Kato Koiti
This page was created on Mar13 2000.



文字コード

ほら貝目次