|
|
図1 Webページが表示されるまでの処理 まず，Webブラウザは，WebサーバーにHTMLデータを送ってもらうようにリクエストを送信する。それを受けて，Webサーバーは，HTMLデータを含んだレスポンスをクライアントへ送る。クライアントは，受け取ったデータを見て文字コードを判断し，画面に表示する。 |
Web（ウェブ）ページが文字化けを起こした典型例，画面いっぱいに呪文が並んでいるような半角カタカナだらけのページが表示される原因を考えていこう。そのために，WebブラウザがWebサーバーとどのような情報をやりとりしているのか，そしてその情報をどのように利用しているのか，というところから探っていく。
まずは，WebページがWebブラウザに表示されるまでの流れを大まかに追っていこう（図1[拡大表示]）。
英数字だけなら問題ない
WebブラウザとWebサーバーのやりとりには，HTTPと呼ぶプロトコルを使う。これは単純なメッセージのやりとりを定めたもので，まずWebブラウザがどんなデータをほしいかという「リクエスト」をWebサーバーへ送信する。すると，Webサーバーはリクエストの処理結果を伝えるメッセージとともに，要求されたデータを返信する。これを，レスポンスと呼ぶ。
もちろん，Webページはテキスト・データ以外に，画像やマルチメディア・データも利用できる。ただ，今回のテーマとはあまり関係がないので，話はここまでにしておこう。
このやりとりで重要なポイントは，WebブラウザとWebサーバー間で，文字情報を交換する際，「文字コード」という形で送受信していることである。よく考えれば当たり前のことだが，コンピュータや通信で扱えるのは，0と1のビット列だけ。文字もビット列として扱う必要がある。そこで文字をビット列に割り当てる規則を決め，この規則に従ったビット列のことを文字コードと呼ぶのである。
例えば，「A」という文字を8ビットで表すと，「01000001」（16進表記では41H）となったとしよう。Webサーバーはこのビット列を送信する。Webブラウザは受けとったこのビット列から，これがもともと「A」という文字だったことを推測して，実際に表示するのである。
半角の英数字や記号だけなら，標準の文字コードとしてASCII（アスキー）コードを利用する。ほとんどのコンピュータはこのASCIIコードを標準でサポートしているので，英数字だけならほぼ問題なく，文字をやりとりできる。
複数ある日本語文字コード
ところが，日本語文字をビット列に割り当てる規則（符号化方法）は主なものだけでも三つある。実際，インターネットに公開されている日本語のWebページは，シフトJIS，日本語EUC，ISO-2022-JP（JISコード）のどれかの文字コードを使って記述されており，統一されていない。
この環境で，Webサーバーが「た」という文字を日本語EUCでビット列に変換して送ると，
1010010010111111
となる。ところが，これを受信したWebブラウザは，このビット列をシフトJISだと思い込むと，「、ソ」という文字に変換してしまう。これが文字化けの根本的な原因なのである。ブラウザの文字コード対応は進んだ
ただ上記の例は，実際のWebブラウザ側での処理を非常に単純化したものだ。
たしかに1990年代前半，まだWeb利用が学術目的などに限られていたころのWebブラウザは，Webブラウザを動かすOSが採用している文字コードしか利用できなかった。例えば，UNIX向けWebブラウザは日本語EUC，パソコン向けならシフトJISで記述されたWebページ以外を表示すると文字化けが起こった。つまり，上記の例がそのまま通用したのだ。
一方，最近のWebブラウザは，サーバーから受信した文字コードを自分自身が処理できる文字コードに変換できるようになった。例えば，JISコードで受けとったデータをWebブラウザがシフトJISに変換してから，実際に文字を表示する。
したがって，サーバーがどの文字コードで文字データを送信してきたかということがわかれば，Webブラウザはきちんと文字を表示できる。しかし，Webブラウザは受信したデータの文字コードを間違って判別してしまうこともある。すると，呪文のようなWebページが表示される。
