2000/03/26
前三回で、日本語の文字コードには大きく分けてJISコード、日本語EUCコード、Shift-JISコードの3種が使われていることを解説した。このうち日本語EUCコードはUNIXなどWSの世界で、Shift-JISはMS-DOSなどPCの世界で多く使われている。では、これらOSやハードウェアの世界を越えたインターネットの世界における日本語の文字コードについてはどうなのであろうか。
インターネットにおいて最も長い歴史を持つメールの場合には、原則として7bitのJISコードで送るというルールになっている。これはコンピュータが英語圏で閉じていた昔、つまり文字はASCII(7bit)のみでよかった時代に、使われていない8bit目を通信のための制御信号か何かに使っていた場合がある、というのが理由の一つらしい。
従って、例えばPCからメールを送る場合には、Shift-JISで書かれたテキストをJISに直してからメールとして送り、受け取った側ではJISコードで書かれたメールのテキストを自分の環境で使われているコード体系のテキスト(PCならShift-JIS、UNIXなら日本語EUC)に変換して読む、ということをしている。
このコード変換自体は、通常はメールソフトが勝手にやってくれるようになっており、ユーザー側ではあまり意識しなくてもうまく変換してくれるようになっているはずである。しかし、このコードの変換が何等かの原因でうまく行われなかった場合、いわゆる「文字化け」という現象が起こる。例えばこんな具合にである。
^[(BK7<g$,V"Iw$K>e<j$KK7<g$N3($rIA$$$?!#^[$@
これが最も典型的な文字化けのパターンで、JISコードにおいて文字セットを指示するエスケープシークエンスが正しく認識されないとこのように文字化けする。実はJISコードのエスケープシークエンスにはいくつもの誤解が存在し、それが方言のようなものになって、上のような文字化けが発生したりしている。例えば、JIS英数文字セットを指定するエスケープシークエンスは正しくは「ESC,(,J」なのであるが、ある年のJISハンドブックでそれが「ESC,(,H」と誤って表記されてしまった。そのためこれを参照して作られたプログラムでは、JIS英数文字セットを指定する「ESC,(,J」を解釈しないため、変換が正しく行われない、ということがある。
最近はメールにファイルを添付して送ることも多いようだが、添付ファイルについても、インターネット内では7bitのコードに変換して流通させることになっている。添付ファイルを7bit(ASCII)のみのデータに変換する(エンコード)ことや、7bitデータから元のファイルに戻す(デコード)ための方式には、base64(現在最も一般的)、uuencode/uudecode(古くはUNIXで一般的)、ish(MS-DOSでよく使われていた)、BinHex(MacOSでよく使われていた)などがある。最近のメールソフトでは、これらの方式によってエンコードされた添付ファイルを、到着時にエンコードの種類まで判別して自動的にデコードし、元のファイルの形で出力してくれるようになっていたりする。
話を戻すと、通常のテキストのメールはJISコードで送るのがルール、のはずだったのであるが、MicrosoftのExchangeなどでは、あろうことかデフォルトの設定が「メールをShift-JISの形で外に流す」という具合になっていた。メールソフトや流通経路によってはそれでも無事に届くこともあるが、普通のメールソフトでは受信時に文字化けを起こしてしまうことが多々あり、一時期混乱を招いていた。Microsoftがインターネットについての基本的なルールを無視して、自分たちのルールを通そうとしたために起きた混乱である。
メール以外のプロトコル、つまりftpやhttpなどについては、文字コードの種類に関するルールは基本的には無い。もちろん実際にファイルを参照する環境に合わせて送るのは送る側の責任であるが、httpなどの場合は、先にも少し述べたように、ブラウザの方で文字コードを自動判別してくれるような設定も可能になっており、その場合にはHTMLファイルがどの文字コードで記述されていようときちんと読めるように変換して表示してくれるようになっている。Microsoftが作ったShift-JISコードが体系的に汚いコードであると言っても、使っていけないことにはなっていない。事実このページも、PCで作ったファイルをそのままftpでアップしているので、Shift-JISコードになっていたりするのである。