【PR】 ヒアリングマラソンなど英語教材比較
【PR】 「あるある大辞典」で大ブレーク!! 痩せた。しわが取れた!!
【PR】 TOEICリスニング倶楽部
| ||||||
|
【PR】 仮面ライダーブレイド DX変身ベルト ギャレンバックル 【PR】 ヒアリングマラソンなど英語教材比較 【PR】 「あるある大辞典」で大ブレーク!! 痩せた。しわが取れた!! 【PR】 TOEICリスニング倶楽部 |
|||||
| ||||||
・ネスケ4.Xのキャッシュ機構ネットスケープ4.Xのキャッシュのメカニズムについて考える前に、「ソース」の表示について考えます。文字化けと何の関係があるかとお思いでしょうが、まずはお付き合いを。Windows版IEにおけるメモ帳でのソース表示の場合、Shift_JIS以外の文字コードで書かれたホームページのソースは文字化けします。一方、ネットスケープのソースビューアでは、Shift_JIS以外の文字コードのホームページでも文字化けせずに表示されます。そのため、メモ帳以外のテキストエディターでIEでのHTMLソースを開く方法を知らない人にとっては、ネットスケープのソースビューアの方がIEより"賢い"と思っている方も少なくありません。しかし、この"賢さ"こそが、ネットスケープ4.Xの文字化けの元凶であることを以下に論証します。 下記は、これ以上、簡単にはできないというぐらいに簡単にしたソースです。「あいうえお」と表示しているだけです。この場合、下記のように「オリジナルのソース」もネットスケープ4.Xでソースを表示させてものも全く同じである。
次に、「あいうえお」をJavascriptのdocument.writeさせてみます。すると、IE支持者には信じられない現象が起きます。
Windows版IEでは、「オリジナルのソース」のまま、「ソースの表示」を選ぶと、メモ帳で見ることができます。シンプルです。ところが、ネットスケープでは、Javascriptのdocument.writeした結果だけを書いていて、<script language=〜という必死になって書いた部分は跡形もなくなっています。変わって、「BASE HREF=〜」が表示され、さらにソースビューアの最上段のタイトルは「ソース：wysiwig〜」となっています。 What is wysiwig? Wysiwygというのは、ホームページ作成ソフトなどの機能を言及する際に使われたりしますが、「What You See Is What You Get」の頭文字を取ったものです。直訳しますと、「あなたが見るものは、あなたが得るもの」。すなわち、見たままのものが完成品（= document.writeしたものを含めて全ての処理を終えた最終結果）です、という意味合いだと思います。 このネットスケープのJavascriptのdocument.writeを巡るソース表示の方法は、反応は二通りだと思われます。まず、IEなどで開発していて、正直、どのようにdocument.writeされているか分かりにくい場合があり、デバックする際にネットスケープは便利かもしれません。もう一つの反応は「余計なことをするな」というもの。メモ帳で開けないがゆえに、特にプログラマーにとっては、ネットスケープ4.Xは非常に使いにくいのですが、さらに勝手にdocument.writeした結果を「ソース」と言い張られるので、腹が立つというものです。「これは、俺が書いたソースではない」と言いたくなる訳です。 また、余談になりますが、ネットスケープのソース表示は、改行（\n）を入れていないソースの場合はそのまま改行を入れずに表示されるため、スクロールしまくらなければならず、それが私の場合、ネスケ離れに一層の拍車をかけました。 話を文字化けのメカニズムに戻します。次にEUC-JPで書かれたホームページのソース表示について考えてみます。まずは、Javascriptのdocument.writeを利用しない場合から。
これは、前頁でウインドウをリサイズするという例で紹介したソースをdocument.writeなしで書いたものです。この場合、ソースは全く文字化けしていません。 |
（広告） |
|
次にいよいよ、これら問題が起こる漢字を使った文章をdocument.writeで出力した場合（EUC-JP）の結果について見ます。
ついに文字化け出現!! 喜んでも仕方がありませんが、これは大発見かもしれません。ネットスケープ4.Xの場合、「ウインドウをリサイズすると文字化けして表示される」と信じられていましたが（実際それは正しいのですが）、実は「ソースの表示」の時点で既に化け化けなのである。これはどういうことでしょうか？ これを解明するためには、回り道に見えるかもしれないが、実はネットスケープのキャッシュ機構を解明しなければなりません。これこそが、このページのメインテーマです。 ネットスケープ4.Xのデフォルトのキャッシュフォルダーは「C:\Program Files\Netscape\Users\ユーザー名\cache」（Windowsの場合）になります。エクスプローラでキャッシュフォルダーの中身を見てみます。見てみると、IEとの決定的違いにぶつかります。まず、ファイル名。IEの場合はファイル名は、元のファイル名のままですが、ネットスケープ4.Xでは、わざわざ別のファイル名にしています。どのファイル名が、元のどのファイル名（URL）のものと対応しているかは「fat.db」というファイルで管理しているようです。 そして、よく分からない文字列で構成されたHTMLファイルを調べてみると、さらに驚きます。ネットスケープ4.Xでは、インターネット上のドキュメント（HTMLファイル）にアクセスした場合、そのファイル内でdocument.writeされている場合は、二通りのHTMLファイルが同時にキャッシュファイルを生成させます。片方はIEで表示されるのと同じソース（ここでは、キャッシュファイルAとします）であり、もう片方はネットスケープ特有の処理を加えたファイル（document.writeの結果のみを表示するパターン。キャッシュファイルB）です。つまり、ソースビューアが表示するためのソースが、キャッシュファイルＡだけでなく同時に作成されています。 そして、ネットスケープ4.Xではウインドウサイズをリサイズすると、キャッシュファイルから読み直すように作られていて、その場合にキャッシュファイルAの方ではなく、キャッシュファイルBを参照します。しかし、このキャッシュファイルＢは非常に変わったファイルになっています。文字コードの混合も平然と行われています。 例を出します。「質問」というテキストがdocument.writeされていたとしますと、その結果である「質問」という文字列が、ソースビューア用のHTMLファイル（キャッシュファイルB）の中に生成されます。ところが、ホームページのエンコードがShift_JISの場合は問題ないのですが、EUC-JPの場合、本文はEUC-JPのまま、document.writeされた結果はShift_JISで保存されるという形を取っています。つまり一つのファイルの中で、文字コードの混合が起こっています。 では、ネットスケープ4.Xのソースビューアは文字コード混合の中でどのようにして正しく表示させているのだろうか？ 化けている文字もあるが、化けない文字も多いのである。まぐれで、化けていなかったわけではない。序論で説明したように、異なる文字コードでも、できるだけ領域が重ならないように工夫がなされている。しかし実際には重なっている部分もある。例えば、EUC-JPで（いわゆる）半角カタカナを表すのは、1バイト目が「0x8E（『0x』とはその後ろに続く文字列が16進数であることを示す符号です。）」の場合です（EUC-JPにおいては半角カタカナは「0x8E」という制御文字（ss2と呼ばれるらしいです）を持った、2バイト文字です。）。しかし、「0x8E」というコードをShift_JISでは、1バイト目にも2バイト目にも持っている場合があります。まさに、その漢字が前頁で列挙した漢字（188文字+42文字）だったのです。 そのため、Shift_JISの漢字一文字なのか、EUC-JPの半角カタカナなのかを分からなくなり、結果的にはEUC-JPの半角カタカナを採用します。そこで、ソースを表示させても文字化けしますし、ウインドウをリサイズしても文字化けすることになります。 また、実際には、document.writeした部分だけでなく、ページ全体に文字化けが見られる場合がありますが、これはdocument.writeより下に位置する文章は、たとえ<script language〜</script>の範囲外であっても、キャッシュファイルBにはShift_JISで保存されているためです。document.writeより上に書かれている「子」「字」「自」などは文字化けしませんが、document.writeより下にある該当漢字は全て文字化けするという話になります。
話が少し逸れますが、このキャッシュファイルBで文字コードの混合が見られるように、ネットスケープ4.Xでは、文字コードの混合があっても出来るだけ"正しく"表示させることが可能です。ですから、ネットスケープ4.Xでプログラム開発していると、本来EUC-JPのページに、誤ってShift_JISでPOSTされたデータを合成して表示させていても、それなりに正しく表示させてしまうため（該当の漢字188字+42字は文字化けします。IEであれば全体的に文字けします）、Shift_JISでPOSTされているバグになかなか気がつかなかった経験があります（詳しくは、「Mac版ネットスケープ4.7で、EUC-JPのページからShift_JISのデータがPOSTされるケース」の章を参照してください）。 また、このキャッシュファイルBの存在は、ネットスケープ4.Xでネットサーフィンをしていて、エンコード（ネットスケープでは『文字コードセット』というネーミングになっていますね。）をShift_JISからEUC-JPに変えても、文字化けが発生しない、表示の変化が全く見られない現象の理由となります。IEであれば、ホームページ表示の際のエンコードを変更すれば、当然文字化けしていたものが解消したり、逆に正常だったページが文字化けしますが、ネットスケープ4.Xでは、それがないことに、不思議に思われたことはないでしょうか？ 話を元に戻します。では、このネットスケープ4.Xの文字化けを解消するための方策はないのでしょうか？ 次のページで解決策を考えてみます。
   |
