2007年01月31日

◆ JIS の破綻


 Vista 発売を期に採用された JIS2004 では、正字は使えるだろうか? 「新たに正字をいっぱい使えるようになった」と思っている人が多いようだ。だが、これは正しくはない。
 実は、新たに使えるようになった正字は、「字形の変更」をなされた 168字中の148字(?)だけである。(詳しくは次項。)
 一方、それ以外の正字(第3水準や第4水準の漢字)は、新たに使えるようになったということはない。特に、テキストファイルでは、これらの正字は使えない。 ──

 まず、初めにお詫びしておく。
 「これからは、第3水準(EFB0)の文字として、テキストファイルで表示可能。
 と前項で記したが、これは正しくない。これは、多くの人が信じていただろうし、私も信じていたのだが、実は正しくないと判明した。すなわち、第3水準や第4水準の漢字は、テキストファイルでは使えないのだ。

 そもそも、JISの文字コードは、何のためにあるか? テキストファイルで文字を表示するためだ。では、テキストファイルで文字を表示するとは、どういうことか? 文字コードが文字コード表の順にならんでいるということだ。
 具体的に言おう。JISの文字コード表では、第一水準漢字のところに「亜 唖 娃 阿 ……」というふうに漢字が並んでいる。そして、文字の符合も、この順で符号化されている。

 では、第三水準と第四水準は、どうか? もちろん、同様になるはずだ。テキストファイルで文字が表示できるはずだ。つまり、第3水準と第4水準の文字についても、文字の符合は、文字コード表の順番で符号化されているはずだ。……しかし、そうなるはずであったのだが、現実には、そうはならなかったのだ。

 ──

 そんなことはありえそうもない、と思う人が多いだろう。私だって、初めはちょっと耳を疑った。そこで、典拠を引用しておく。
Windows Vistaで追加された文字は,Unicodeでしか扱えない。シフトJISではキャラクタ・コードが割り当てられていないからだ。
 実際には, JIS2004で扱えるJIS第3/第4水準の文字についてもキャラクタ・コードを割り振った「シフトJIS2004」や「EUC2004」などのエンコーディングがある。ただしこれらは「標準(Standard)」ではない。また,シフトJIS2004では,従来のシフトJISの空いているコード領域にJIS第3/第4水準の文字を割り当てているため,Windowsの外字領域と重なっている文字がある。
 マイクロソフトは,標準でないこと,外字領域と重なっていること,そしてWindowsのコード・ページを今後増やさない方針であることを理由に,シフトJIS2004には対応しないという。 Windowsでは,エンコーディングの基本はUnicodeだ。

 なお,Unicodeでしか扱えない文字が存在するのは,Windows Vistaに始まったわけではない。Windows 98/Windows NT 4.0 SP4は,JIS X 0212(補助漢字)に対応しているが,これらの追加された文字は既にUnicodeでしか扱えなかった。

( → ITpro
ここでは最初のあたりの、二番目のセンテンスに着目しよう。「シフトJISではキャラクタ・コードが割り当てられていない」とある。これが決定的に重要だ。これがつまりは、(第3水準と第4水準の漢字について)「テキストファイルでは使えない」ということであり、「文字コード表の順に符号化されていない」ということだ。
 なお、なぜ「文字コード表の順に符号化されていない」かというと、「JISの文字コード表」でなく「 unicode 」の文字コード表の順に符号化されているからだ。
( ※ unicode の文字の順序は、「ユニコードの文字コード表」を見ればわかる。IME のツールでわかる。文字講堂にも、「unicode の漢字一覧」というデータファイルがある。)

 ──

 話を戻そう。
 とにかく、第3水準や第4水準の漢字は、テキストファイルでは使えないのだ。このことが決定的に重要である。
 なぜか? テキストファイルで使えないとすれば、「unicode テキスト」というファイル形式で使うしかない。しかし、「unicode テキスト」というファイル形式で使うのだとすれば、これまでとまったくかわらない。WindowsXP 時代とまったく同じだ。いや、Windows98 時代とまったく同じだ。はるか昔から、何ら変わっていないことになる。

 では、unicode テキストで使えばいいか? 「unicode テキストだって、テキストファイルじゃん」と思う人もいるだろうが、残念ながら、そうではない。unicode テキストのファイルは、テキストファイルではない。ワードや一太郎のファイルと同様で、バイナリファイルである。「ただの文字データだけのファイル」ではなくて、「アプリ専用の特殊なファイル」である。その難点は、次のことだ。
  • ファイル形式を明示する必要がある。具体的には、ファイルの冒頭に「このファイルはこの形式のファイルですよ」という専用のファイル情報を入れておく必要がある。
  • もしその専用のファイル情報を入れておかないと、ファイルを正常に読み取れない危険が高い。なぜなら、「 unicode テキスト」には、さまざま種類があるからだ。すなわち、「UTF-7,UTF-8,UTF-16 LE,UTF-16 BE」の四種類である。(LE は Little Endian で、BE は Big Endian である。)
 で、この四種類の unicode のうちのどれが標準的かというと、標準的なものは一つもない。具体的には、次の通り。

  ・ 現時点での HTML では UTF-8 が優勢。
  ・ 将来的には、HTML では UTF-16 LE が優勢。
  ・ パソコン内部で利用する「 unicode テキスト」では UTF-16 BE が優勢。

 つまり、UTF-8,UTF-16 LE,UTF-16 BE の三つが勢力を競いあっていて、とても統一されそうにない。

 ──

 また、unicode には、別の問題もある。

 第1に、UTF-16 LE,UTF-16 BE の場合、「サロゲート・ペア」というのを使っているせいで、文字を消すことが困難になることがある、ということだ。たとえば、ある文字を BS (バックスペース)キーで削除しようと思っても、MS-Excell などでは削除できないことがある。二回キーを押して、ようやく削除できる。そういうことが起こっている。( → MS-Office 2007 の不具合 )(これはまあ、製品のバグみたいなものだが、もっと致命的なこともある。次のことだ。)

 第2に、「ファイル名には unicode の文字を使えないことが多い」ということがある。下手に unicode の文字でファイル名をつけると、ファイルが行方不明になったりしかねない。これはつまり、第3水準や第4水準の文字でファイル名を使えない、ということだ。

 第3に、こいつが一番困るのだが、エディタでは unicode の文字を使えないことが多いのだ。たとえば、変換表の 39字をクリップボードへコピーしてから、エディタに貼りつける。すると、どうなるか?
  ・ 秀丸エディタ …… すべて表示される。
  ・ QXエディタ …… すべて表示されない。
  ・ WinXP版メモ帳 …… 部分的にダメ。
                 「蝉騨倶剥呑嘘妍叱」の正字が非表示。

 要するに、第3水準や第4水準の文字は、一般的な文字として使うことはできない。ワープロやブラウザなどで使えるだけであり、ファイル形式も文書用の形式(ワープロ文書やHTMLなどのファイル形式)を使う必要がある。「この文字は unicode のこのタイプの文字です」という符号化情報をつけておかないと、まともに文字として使えないのだ。

 ──

 そもそも JISという文字コード規格は、テキストファイルとして使えるための文字コード規格であったはずだ。なのに、上記の通り、狙い通りのことができていない。としたら、これはもはや、文字コードの規格としては破綻していることになる。自己矛盾。規格の破綻!
 では、なぜ、こんなことになったのか? とうてい理解しがたいだろう。まったく不思議なことである。
 しかしこれは、次のように答えることができる。
 「本来は、破綻しないはずだった。つまり、穴に落ちないはずだった。しかし、あえて穴に落ちようと努力したせいで、狙い通り、穴に落ちてしまった」

 歩いている人の前に、穴があるとしよう。その人が歩いて、穴に落ちた。それを見ると、たいていの人は、「なぜ穴に落ちたのか?」と不思議がるだろう。しかし、不思議はない。なぜなら、その人は、あえて穴に落ちようとして穴に落ちたからだ。つまり、狂人だったからだ。
 JISの規格制定者は、狂人ぞろいだった。──これが、穴に落ちたことの理由である。
 もちろん、以上は、比喩的な表現だ。その具体的な事情は、次の通り。

 ──

 直接的な理由は、最初のあたりに引用した文書に書いてあるとおりだ。再掲すると、こうなる。
シフトJIS2004では,従来のシフトJISの空いているコード領域にJIS第3/第4水準の文字を割り当てているため,Windowsの外字領域と重なっている文字がある。
 マイクロソフトは,標準でないこと,外字領域と重なっていること,そしてWindowsのコード・ページを今後増やさない方針であることを理由に,シフトJIS2004には対応しないという。
 ここでは、「外字領域と重なっている」という理由があるが、もう一つ、理由がある。「機種依存文字と重なっている」ということだ。つまり、「外字領域と機種依存文字の領域で、JIS2004 と 既存の Windows の領域では、重複がある。重複のある部分については、とんでもない文字化けが生じる。

 つまり、JIS2004 というのは、既存の Windows版のシフトJISに対して、上位互換ではなかった。まったく別の「置き換わる」規格だった。そして、置き換わる規格を提供すれば、従来の規格との間で、とんでもない文字化けが起こる。……それは絶対に避けなければならない。
 この文字化けは、「字形の変更」の文字化けとはまったく異なる。「字形の変更」ならば、略字と正字との間で文字化けが起こるだけだ。それは「文字」が化けるのではなく、「字体」が(略字と正字との間で)化けるだけだ。字体は変わっても、漢字としては同じ意味内容をもつから、たいして問題ではない。もちろん、文書が読み取れなくなるというようなことはない。
 しかし、「置き換わる」規格を使うと、たがいに文字が読み取れなくなる。特に致命的なのは、従来の文書におけるローマ数字や外字(企業ロゴや人名異体字で使っていることが多い)で、まったく別の漢字に化けてしまうことだ。……これでは、とてつもない混乱が起こる。とすれば、マイクロソフトが、「置き換わる」規格を使わなかったのは、当然である。
 要するに、第3水準と第4水準をもつ規格を、シフトJISで使わなかったのは、まったく当然なのだ。JIS2004をシフトJISで使えないようにしたのは、まったく当然なのだ。JIS2004 が文字コードの規格として自己破綻するのは、まったく当然のことなのだ。……とんでもない文字化けを避ける、という必要性ゆえに。

 ──

 では、どうすればよかったか? JIS2004のかわりに、MS版のJIS90 に対して上位互換となる新規格を作ればよかったのだ。上位互換であれば、文字化けは生じない。たとえば、ローマ数字などの機種依存文字は、文字化けを生じない。また、マイクロソフトの外字となる文字は、今まで通り外字として使える。
 だから、「上位互換の規格にする」というふうにすればよかったのだ。そして、それは、私の提案そのものだった。「上位互換にすれば、文字化けが起こらないが、上位互換にしないと、文字化けが起こる」と理由を述べた。つまり、「上位互換にしないと、失敗するぞ」と。なのに、その忠告に逆らって、JISの委員会は、上位互換でない規格を採用した。「そのままだと穴に落ちるぞ」という警告に逆らって、あえて上位互換でない規格を採用した。そのせいで、穴に落ちるべくして、穴に落ちたのである。私の警告通りに。

 ──

 では、なぜ、JISの委員会は、上位互換でない規格を採用したのか? その理由は、大きく分けて、二つある。
 一つは、マイクロソフトを無視したことだ。「マイクロソフトの規格なんか、しょせん世の中の多くの規格の一つじゃないか。そんなものは無視してしまえ」と主張して、マイクロソフトの機種依存文字や外字文字を無視した。そのせいで、JISそのものがマイクロソフトに拒否されてしまったのだ。(現実無視ですね。私のような現実重視とは違う。)
 もう一つは、彼らの理想主義だ。彼らには理想があった。「正字以外のすばらしい文字を採用しよう」という理想が。その理想には、たくさんの文字が含まれていた。

 (1) 「クシストヌハヒフヘホプムラリルレロワ」を小さくした文字や「セツト」に半濁点をつけた文字。(彼らはこれを「アイヌ語の文字だ」と称したが、嘘八百。アイヌ語は口承言語であり、文字をもたない。)
 (2) 2バイトの欧文文字。(これらは本来ならば unicode で表示するべき文字だ。それを、日本語専用の規格であるシフトJISに入れる、という倒錯的な発想。)
 (3) 漢和字典にも載っていないような、変な歪んだ(書き間違えが固定された)人名漢字。


 要するに、これらを一言で言えば、「日本語以外の文字」である。で、日本語以外の文字を、日本語の文字コード規格に入れようとすると、文字を入れる場所が足りなくなってしまう。そこで、マイクロソフトが使っていた機種依存文字の領域と、外字の領域を、つぶしてしまった。しかし、そんなことをすると、既存の Windows ユーザーが大迷惑をこうむるので、マイクロソフトがその規格を拒否せざるを得ない。

 結局、理想に燃えて、「日本語以外の文字をたくさん入れよう」と狙ったせいで、他の日本語といっしょに規格全体が、マイクロソフトに拒否されてしまったわけだ。単純に言えば、「あれもこれも」と過剰に欲張ったせいで、すべてを失ってしまったわけだ。
 比喩的に言うと、積載可能量10トンの船に、荷物をきっちり10トン載せようとしたら、「そんなにギリギリまでたくさんあると、積みきれません。船員と乗客と食料と予備燃料が積めません」と言われて、船が出航できなくなったわけだ。本当は、必要な「漢字」だけを載せればよかったのに、必要でもない「エセ文字」みたいなものをたくさん載せようとしたから、載せられるはずの漢字まで載せられなくなってしまったわけだ。
 全部を望んだせいで、全部を失う。欲張りの丸損。──それが JIS2004 だ。
 そして、このことは、1999年3月の時点で、すでに指摘されていたのである。(「文字講堂」の「南堂私案」において。)

 ──

 まとめ。
 第3水準・第4水準の文字を見ると、JIS2004 は文字コードの規格として破綻している。
 ここにある第3水準・第4水準の文字は、ただの unicode の文字集合であって、テキストファイルで使えるようなシフトJISの文字集合ではない。JIS2004 における符号化番号など、何の意味もない。意味があるのは、unicode の符号化番号だけだ。どうせ文字コード表を使うなら、JIS2004 でなく unicode の文字コード表を使うべきだ。(第3水準・第4水準の文字については。)
 JIS2004 において、まともに使える正字は、「字形の変更」をした箇所だけだ。この箇所だけは、南堂私案にしたがっており、何ら問題なく使える。
 しかしながら、第3水準・第4水準の文字は、南堂私案に逆らった仕方で規格化された。そのせいで、「テキストファイルでは使えない」という大問題が発生した。そして、この問題は、南堂私案においてもともと指摘されていたのである。「そんな馬鹿げた非互換な規格は採用するな。まともな上位互換の規格を採用せよ」と南堂私案が示していた。なのに、その警告を無視して、非互換な規格を採用した。
 こうして、穴に落ちると警告されていたのに、あえて穴に落ちたわけだ。
 そして、JISの規格担当者が穴に落ちたせいで、彼らもろとも、日本人の全員が、穴に落ちることになった。──つまり、馬鹿に先導を委ねたせいで、全員が穴に落ちてしまった。
 船頭愚かにして、舟 陸に上がる。船頭愚かにして、JIS 穴に落ちる。

 [ 余談 ]
 これを見て、「ひどいものだ」というのが、大方の感想だろう。ただし、このひどさは、JISに限ったことではない。経済だって、進化論だって、物理だって、数学だって、同様である。どの分野でも、人々は警告に耳を貸さない。で、文字コードの場合には、警告から8年たって、予想された「穴に落ちる」という現実が発生したわけだ。で、その現実が発生してから、「8年前の警告に耳を傾ければよかった」と思っても、後の祭りというわけだ。
 馬鹿は死ななきゃ直らない。……それがまあ、日本という国民である。少しは反省すればいいのにね。
 ( ※ そういえば、納豆騒ぎ以前の「あるある」にも、ずいぶん長い間、だまされていたものだ。だまされたことに気づくまで、何年もかかったわけだ。それがまあ、日本という国民である。……そういえば、イラク人質事件でも、ライブドア事件でも、だまされっぱなし。)


 ────────────────────────────────

  【 追記 】

 第3水準・第4水準の文字は、テキストファイルで使えない(シフトJISで使えない)。このことには、いろいろと不便な点がある。

 典型的なのは、「ファイル名に使えない」ということだ。ファイル名には(文書内冒頭の)符号化方式の記述などはあるはずがないから、ファイル名には unicode は使えない。これでは、さまざまな漢字や記号について、「ファイル名に使える文字と使えない文字がある」というふうになって、非常にわずらわしい。初心者に対しても「文字コードの知識をもて」と要求するわけだ。とんでもない不便さだ。
( ※ 「だからファイル名は英字だけを使えばいいんだよ」なんて言わないでくださいね。はるか昔のワープロ専用機でさえ、英字以外の日本語文字を使えた。しかも、マシン内部では無制限に使えたので、「使えない文字はどれか」と意識する必要はなかった。)

 また、文書内部で使うにしても、使いにくい。
 たとえば、正字を使いたくても、第3水準・第4水準の正字であると、使いにくい。(「嘘 噛 倶 掻 痩 祷 呑 蝋 妍 并」の正字など。) また、第3水準の記号(ハートなどのトランプ記号,白抜き数字,丸数字ならぬ丸英字,丸カナの記号,斜め矢印など)を使いたくても、使いにくい。
 具体的に言おう。MS-Office2007 の「記号と文字」という文字入力ツールで、これらの文字を出そうとしても、うまく出すのが困難だ。というのは、ここでは、「unicode の文字コード表」と「シフトJISの文字コード表」しかないからだ。「unicode の文字コード表」では、文字が6万字ぐらいあって、探すのが大変だ。「シフトJISの文字コード表」では、第3水準・第4水準の文字は消えている。(従来通り。)
 一方、ATOK の文字入力ツールでは、「 X 0213 の文字入力ツール」というのがあって、これが実質的に「JIS2004」の入力ツールになっているので、第3水準・第4水準の文字を容易に出せる。しかし、これは非正規の方法だ。なぜなら、3水準・第4水準の文字はシフトJIS(X 0213)では符号化されていないからだ。つまり、文字コードになっていない体系を、あたかも文字コードになっているかのごとく扱っている。文字コードの観点からすれば、正規の方法とは言えない。(符号化されていないものを符号化されているかのごとく扱っているので。)

 で、こういうメチャクチャなことになったのは、前述の通り。「JIS2004 はシフトJISでは符号化されない文字規格だ」ということが理由だ。つまり、JIS2004 は、文字集合の規格ではあっても、文字コードの規格ではない。(狙いはともかく、現実には。)
posted by 管理人 at 21:35| Comment(8) |  文字規格 | 更新情報をチェックする
この記事へのコメント
最後に 【 追記 】 を加筆しました。
タイムスタンプは、下記。↓
Posted by 管理人 at 2007年02月01日 19:56
< お詫びと修正 >

 変換表
  http://hp.vector.co.jp/authors/VA011700/moji/convert2.htm
 が正しく表示されない場合があったので、修正しました。

 ※ char-set で UTF-16 と書いただけでも正常に表示されるはずでしたが、
   正常には表示されないことが多いとわかったので。(文字化けします。)
   正式表示の UTF-16LE (または UTF-16BE )というふうに書かないと、
   ちゃんと表示されないことが多いようです。
   現時点では修正されています。
Posted by 管理人 at 2007年02月03日 12:10
上記で修正した「変換表」について、再度、バージョンアップしました。
 ファイル自体は同じですが、ファイルに同じ内容の画像をつけました。
 つまり、文書を正常に表示できない環境でも、正しく見えるように、その画像をつけました。
(結果的に、同等の画面が二つあるように見えます。一つは画像で、一つは文書。)
Posted by 管理人 at 2007年02月03日 22:55
「ファイル名には unicode は使えない。」っていつの話ですか?XPでは使えますよ。Meでは駄目だと思いますが。
Posted by 通行人 at 2007年02月04日 01:22
> ファイル名には unicode は使えない

 ご連絡ありがとうございました。
 特にいちいちチェックする必要がないと思ったので、ご趣旨の事象については確認しませんでした。そこで、次のように注記します。

 (1) unicode では《 安心して 》使えない。XP以降の環境では《 機構的には 》使えるが、Win98の環境ではファイル名が消失する。該当箇所が _ という半角文字に文字化けして、ファイル名が見えなくなる。
 非常に危険なので、絶対にやってはならないことだ。

 (2) アプリによっては「使いたくても使えない」場合がある。アプリ上で「名前を付けて保存」をするとき、ダイアログボックスが unicode に対応していないらしい。
 最新のMSのアプリならば大丈夫だが、秀丸 ver3.19ではダメ。秀丸 ver3.19 では、文書上では unicode を使えるが、名前を付けて保存では unicode を使えない。QX でも名前を付けて保存では unicode を使えない。当然ながら、秀丸でも QX でも、unicode のファイル名のファイルを開くことができない。ファイルがあっても、ファイルを開けないのだから、困ったことになる。
(エクスプローラ上でファイル名を変更すれば大丈夫だが、素人だとパニックを起こすかもしれない。)

 ──

 以上のことゆえに、原則として、ファイル名では unicode では使うべきではない。「使える」けれども、「使ってはならない」。
 これは、どちらかと言えば、「使えない」よりも危険である。「使えない」ならば、ミスの恐れがないが、「使ってはならないのに使える」のだと、ミスが起こる。啓蒙の必要があるかもしれない。

 ━━━━━━━━━━━━━━━━━━━━━━━━━━

 なお、本文中の言葉は、特に修正する必要はないと思います。「ファイル名には unicode を使えない」という言葉は、「原理的に絶対に使えない」というふうに記述してあるわけではありません。次のように記述しているだけです。

   「ファイル名には unicode の文字を使えないことが多い」と
   いうことがある。下手に unicode の文字でファイル名をつける
   と、ファイルが行方不明になったりしかねない。

 これは、上記の (1) のとおりです。「ファイル名には unicode は使えない」というふうに単独で解釈するべきではありません。
Posted by 管理人 at 2007年02月04日 12:29
事態はもっと深刻なので、修正します。

> エクスプローラ上でファイル名を変更すれば大丈夫

というのは、間違いでした。

unicode の文字をファイル名にすると、Win98 環境で扱ったとき、最悪の事態になります。

  ・ ファイル名を変更できない。
  ・ ファイルを削除できない
  ・ ファイルをコピーすることもできない。
  ・ ファイルそのものが完全に消失する。
   ( 0KB の空ファイルとなってしまう。)

要するに、本体は消失して、脱殻だけが残り、その脱殻を消すこともできない、というふうになります。(USB メモリなどの記憶媒体に入ったまま、操作できなくなる、ということ。)

また、メールの添付ファイルにした場合も、unicode のファイル名だと、添付ファイルにできないことがあるし、仮にできたとしても、相手側のメーラーで処理できなくなるでしょう。

以上のことから、ファイル名に unicode を使うことは、厳禁です。強く啓蒙する必要があるでしょう。
Posted by 管理人 at 2007年02月04日 13:28
興味深く拝見させて頂きました。

このJISの輩って、日本文字コードを「バベルの塔」にでもしたいのでしょうか?何か必至に「自国オリジナル」に拘る余り、時流を見逃している様な・・・
Posted by Eiji at 2007年02月09日 17:00
興味深く読みました。
JIS規格だけでなく、役人のやることはすっとぼけてます。中央でコントロールしたがるところ、特定の会社に左右されたくないところ、左右されたくないけれど袖の下が潤えばすぐに左右されてしまうところなど、感覚が江戸時代のままです。
もしかすると、これは役人だけの問題でなく、このような役人制度を作ってしまった日本国民的な問題かも知れません。
Posted by おっさん at 2008年04月30日 00:20
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

  ※ コメントが掲載されるまで、時間がかかることがあります。

過去ログ