笹山登生の発言・寸感アラカルト

200年1月日 欧羅巴(ヨーロッパ)は遠し、されど、文字化けは強し。

(掲示板から)


「欧羅巴は遠し」と、明治の文人達は、マルセイユ行きの客船で嘆いたらしいが、このIT時代にも、この言葉が通用しそうな出来事に、私自身出会った。

ひょんな事で、クリスマスに、ドイツの方から、あるホームページの日本版を作りたいからという誘いを受け、忘年会を一方でこなしながら、暮れの数日間、貧しい語学力で取り組んだ。

そして一応出来上がり、FTP経由で、先方サイドで、いざ、日本版ホームページをアップロードしてもらったところ、ブラウザの言語選択をいくら自動にしても、ページをジャンプさせると、どうしても「シフトJIS」に変わってしまい、エンコードの設定をやり直さなければならない羽目になった。

当然、文字は、めろめろもじである。

そこで検索で「MOJIBAKE」なるキーワードであたって見ると、「英語と日本語交じりのページでの、エンコードの自動選択がスムーズに行くには、ページの先頭に,「この文字で行きますよ」という、何らかのアルゴリズム(手順)の宣言記述(文字エンコーディング・スキーム)がプログラム上にあれば,機械がそれに従う。」との趣旨の記述があった。

そこで、ドイツの先方に、その旨ページの先頭に書いてもらうと同時に、METAタグなるもので、使用している日本語文字コードのタイプを、「charset:****」という形で明記、指定してもらった。

これでどうやら、日本語コードの自動選択は、スムーズになったものの、今度はJavaを使っているページが、文字化けしている。

これも、検索であたってみると、Javaでは典型的な日本語コードのおなじみ文字化けパターンのようである。

カタカナの「−」と伸ばすところに限って、?の文字化けが生じるのである。

文字化け修正情報なるものは先方に伝えたものの、先方は、このプログラムを直せず、しばらくの間、堂々と文字化けのまま、アップされていたのは、なんとも気恥ずかしいかぎりであった。

まさに、週刊アスキーの「トホホ日記の気分」とは、このことなのだろう。

それでも、おかげで、文字化け防止のテクニックなるものが、かなりあることがわかったのは収穫であった。

例えば、エスケープ文字などといって、文字化けのあとに、"\"の字をつけるとシフトJISになり、文字化けしない、などというテクニックを見て、「やはり文字化けの世界も、金次第なのかな」などとも、正直おもったりした。



どうして、Javaプログラムの元で、文字化けが生じるのか。

このようなことらしい。

同じように見える文字でも、シフトJISとWindows(CP932)とで、UNICODEのコードが違うものがある。

これらの文字をシフトJISで入力した場合、UNICODEでは、それに似た文字をWindows(CP932)で探し、同じ文字とみなし、変換してしまう。

ところが、Javaプログラムが、UNICODEに忠実に、シフトJISで入力された文字を変換しようと、Windows(CP932)に変換要求すると、同じコード番号のUNICODEの文字がWindows(CP932)上にないため、「?」の文字となって、文字化けしてしまう、という訳だ。

だから、ここで文字化けを起こした真犯人は、Javaではなく、UNICODEの文字コードそれぞれに対応していないWindows(CP932)にある、ということになる。

もっとも、やむを得ずにではあるが、勝手にみなし変換してしまったUNICODEにも、一部の責任があるといえばそうですが。

いわば、平たくいえば、UNICODEというワンマン社長が、最大顧客のWindows(CP932)のご機嫌をとるあまり、裁量権を発揮し過ぎ、Windows(CP932)がちゃんと品揃えしていないのに、「まあカニがなくてもカニもどきでもいいや」、といったような感覚で、勝手に、シフトJISとWindows(CP932)との間を、あいまいのまま取り持ってしまったものだから、結局忠実な部下のJavaが、割を食って、悪い子になってしまっている、という構図ですね。

Javaとしてみれば「そんな-、カニもどきでいいなんて話、社長からは聴いていません。??????」となるわけでしょうね。

だから、いくら国際規格の文字コードを増やしても、このような問題は、これからも出てくるのではないだろうか。

ところで、私のその後の文字化け対策は、いとも原始的な方法で解決した。

それは、文字化けする文字を探し出し、その文字を使わない文章で、ファイルを作り変えたのだ。

これが、もっとも簡単で、もっとも有効な方法だった。

世の中のほかのケースやトラブルでも、通用しそうな対処方法にも思えた。



日本なりアジア圏の言語が、ヨーロッパ圏から発信されるには、今回の私の経験ひとつとって見ても、コード変換に伴う相当な障害があることがわかった。

アルファベッドを使う国は、文字化けなるものとは無縁の存在である。

その道の人に言わせれば、日本語以上に、もっとも手を焼かせるのが、中国語とキリル文字、アラビア文字だそうである。

もっとも、それはそれで、意外なメリットがあるらしく、面倒な文字コードほど、ソースを盗まれにくい、という敬遠効果があるという。

デジタル時代の鎖国効果とでもいうのだろうか。

今、世界共通の「UNICODE」設定の動きもあるが、そのUNICODE使用のJavaでさえ、上記の文字化けがあるような有様である。

また、天下のYahooでさえ、日本語コードの文字化けに悩まされているとのことである。

これでは、日本は、その面倒な日本語コードの存在によって、誰からも近寄ってこられなくなるおそれがある。

情報の世界にも、「輸入超過・輸出超過」の概念があるとすれば、日本の情報は、完全に輸入超過状態にあるといえる。

つまり、
(1)海外には、日本語で発信しても、相手にされない。

(2)海外からの日本語の発信は、コード変換の面倒さと文字化けを敬遠されて、こない。

(3)日本からの英語による情報発信は、極端に少なく、しかも、低質である。

(4)海外よりの英語による発信情報にのみ,日本での需要と信頼がたかまっている。

との四重苦によるものである。

ITにおいて、日本がインドに立ち遅れないためには、この辺のところからのIT対策を考えていく方が、ハードや、通信回線の整備以前に必要なことなのではなかろうか。


H

HOMEへ目次へ

HOME -オピニオン -政策提言 -発言- profile & open - 著書 - 政策行動-図書館-掲示板 -コラム- リンク- 政策まんが