ブラウザごとに表示が崩れる原因と対策 Internet Explorer 4.0編
Internet Explorer 4.0が使われていた時代のウェブページは、現在のブラウザで見ると文字化けしたり、画像の位置がずれたり、フレームの一部だけが表示されなかったりします。これは単純なブラウザの性能差ではなく、HTML、CSS、JavaScript、文字コード、サーバー設定が当時の仕様に合わせて作られていたことが大きく関係しています。
特に、古いフレーム構成の日本語サイトでは、トップページと本文ページが別ファイルに分かれ、古い画像形式や固定幅のテーブルが多用されていました。kammuri.comのように、現在は日本語版への案内や別のトップページへのリンクだけが確認でき、タイトル、ロゴ、画像、文字列が正しく復元できないサイトを調べる場合も、IE4.0特有の互換性を順番に切り分ける必要があります。
IE4.0時代のHTMLに起きていた違い
Internet Explorer 4.0は、現代のHTML5を前提にしたブラウザとは設計思想が大きく異なります。当時のページは、frameset、frame、table、fontといった要素を中心に組み立てられていました。DOCTYPE宣言が省略されたページも多く、ブラウザは標準準拠モードではなく、独自の互換モードでHTMLを解釈します。
タグの閉じ忘れや属性値の引用符不足があっても、IE4.0が独自に補正して表示する場合があります。反対に、現在のChromeやFirefoxはエラーを補正できても、レイアウト計算のルールが異なるため、同じソースから別の結果が出ます。古いサイトを再現するには、HTMLが正しいかどうかだけでなく、その時代の解釈方法まで確認しなければなりません。
たとえば、フレームページでは外側のframesetが各領域の幅や高さを決め、個別のHTMLファイルを読み込みます。親ページのパスが変わったり、相対URLの基準が異なったりすると、メニューだけ表示されて本文が空白になることがあります。target属性の指定ミスも、リンク先が別フレームではなく新しいウィンドウに開く原因になります。
フレーム構成と相対パスの崩れ
IE4.0向けのサイトでは、画面全体を左右または上下に分割するフレームが一般的でした。ナビゲーション用のページ、本文用のページ、タイトル画像を表示するページが別々に保存されているため、一つのファイルだけを開くと正しい構成になりません。トップページでは表示される画像が、本文ページを直接開くと見つからないこともあります。
画像やリンクにimages/logo.gifのような相対パスが使われている場合、基準になるHTMLの場所を確認することが重要です。/images/logo.gifというルート相対パス、../images/logo.gifという親フォルダーへの指定、同じ階層を示す相対パスでは、サーバー上の配置が少し違うだけで結果が変わります。大文字と小文字を区別するサーバーでは、Windows上で問題なく見えたファイル名が公開後に読み込めない場合もあります。
対策としては、まずframesetの定義、各frame srcの値、リンクのtarget、画像の保存場所を一覧にします。ブラウザの開発者ツールが使えない古い環境では、HTMLソースを直接確認し、URLを一つずつ開いて応答の有無を確かめます。フレームを使い続ける場合でも、noframes内に通常ページへのリンクを用意すれば、フレーム非対応環境や検索エンジンにも内容を伝えられます。
文字コードと日本語の文字化け
日本語サイトの表示崩れで特に多いのが、Shift_JIS、EUC-JP、ISO-2022-JPの不一致です。IE4.0の時代にはShift_JISを使うサイトが多く、サーバーのHTTPヘッダーやHTML内のmeta要素で文字コードを指定していました。HTMLファイルがShift_JISなのに、サーバーがEUC-JPとして送信すると、見出しやリンク名が記号のように変わります。
文字コードの指定は、HTMLの先頭近くに置く必要があります。古い記述では、次のような指定が使われました。
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
ただし、meta指定だけで完全に解決するとは限りません。HTTPレスポンスのContent-Typeに含まれるcharsetが優先されることがあり、サーバー設定が誤っているとブラウザの自動判定も不安定になります。ファイル自体の保存形式、HTTPヘッダー、HTML内の宣言を同じ文字コードに統一することが基本です。
現在の環境で古い日本語ページを復元する際は、まずバイナリエディターや対応したテキストエディターで実際のエンコーディングを確認します。文字化けした状態で保存し直すと、元の文字列まで失われる可能性があります。復元用のコピーを作成し、Shift_JISとして読み込み、正しく表示できた段階でUTF-8へ変換する手順が安全です。
CSSとテーブルによるレイアウトの違い
IE4.0はCSSを扱えましたが、現代のCSS仕様をすべて実装していたわけではありません。セレクター、継承、ボックスモデル、背景画像、絶対配置などの解釈に制限や独自動作がありました。外部スタイルシートの読み込み、float、position、line-heightの組み合わせによって、ブラウザごとに幅や高さが変わることもあります。
当時のページでは、レイアウトをCSSではなく、透明画像や入れ子のテーブルで固定する方法も多く使われました。セル幅に長い英数字や画像が入ると、IE4.0は指定幅を押し広げることがあります。逆に、別のブラウザでは内容を折り返すため、メニューの幅、本文の開始位置、背景画像の範囲が変わります。
互換性を優先する修正では、まず複雑なCSSを減らし、幅、高さ、余白、背景色を明示します。画像にはwidthとheightを指定し、テーブルにはcellpadding、cellspacing、borderを必要に応じて設定します。CSSだけで位置を調整するより、古いブラウザで理解されるHTML属性と、単純なテーブル構造を組み合わせた方が再現性は高くなります。
ただし、固定幅をそのまま現代向けに残すと、スマートフォンで横スクロールが発生します。古い表示を保存する目的なら原型用ページと現代向けページを分け、IE4.0互換版では固定レイアウトを維持し、通常版ではレスポンシブ対応に切り替える方法が現実的です。ひとつのCSSだけですべての時代の見た目を完全に再現しようとすると、修正箇所が増えてしまいます。
画像形式と表示領域の問題
古い日本語サイトでロゴやタイトルが表示されない場合、HTMLだけでなく画像ファイルそのものを調べます。IE4.0で一般的だったGIFやJPEGは現在も扱えますが、ファイルの破損、拡張子と実体の不一致、サーバーのMIMEタイプ誤設定によって画像が表示されないことがあります。GIF画像をJPEGに名前だけ変更しても、ブラウザが正常に読めるようにはなりません。
画像の周囲に余白ができる原因として、HTML内の改行やスペース、テーブルセルの初期設定も考えられます。インライン画像は文字と同じ行に置かれるため、画像の下側に行の高さ分の隙間が発生します。display:blockが使えない、または期待どおりに動かない環境では、テーブル構造やalign属性を含めた古い記述を確認します。
画像が存在するかどうかは、ブラウザ上の見た目だけで判断せず、HTTPのステータスとContent-Typeを確認します。ファイルが404ならパスや大文字小文字の問題、200なのに表示されないなら画像形式や内容の破損、403なら公開権限やアクセス制限が原因です。ロゴが欠落したサイトを調べる場合は、HTMLのalt属性、ファイル名、周辺リンクも手がかりになります。
画像を差し替えるときは、原寸、色数、透過の有無を記録しておきます。古いロゴを現代的に作り直すより、元ファイルを保全したうえで、表示用の複製を用意する方が資料性を保てます。画像が復元できない場合も、空白のままにせず、alt属性に確認できた名称を記載すると情報が失われにくくなります。
JavaScriptとブラウザ判定の互換性
IE4.0向けのページでは、JavaScriptを使ってメニューの開閉、ステータスバーの表示、別ウィンドウの起動、画像のロールオーバーを実装していることがあります。当時はブラウザごとにDOMの仕様が大きく異なり、IE系ではdocument.all、Netscape系では別の記述を使うといった分岐が一般的でした。
古いスクリプトが現代のブラウザで動かない理由は、関数そのものが廃止されたからとは限りません。window.event、attachEvent、レイヤー制御、フレーム間の参照、ポップアップの開き方などが現在のセキュリティ制限に阻まれることがあります。JavaScriptエラーが一つ発生すると、後続の画像切り替えやリンク処理まで停止することもあります。
対策は、装飾目的のスクリプトをHTMLの基本機能から切り離すことです。リンクはJavaScriptが無効でも移動できる通常のhrefを持たせ、画像のロールオーバーはなくても内容が伝わるようにします。IE4.0用コードを保存する必要がある場合は、古いスクリプトを別ファイルに隔離し、現代ブラウザ用の処理と混在させない方が原因を追いやすくなります。
互換性を検証するときは、IE4.0を無理に実機でインターネットへ接続するのではなく、保存したHTMLと画像を隔離環境で確認します。古いブラウザは暗号化通信や証明書、現在のサーバー環境にも対応できないためです。表示確認と安全な公開確認を分けることで、歴史的な見た目を調べながら利用者の環境も守れます。
現代のサイトへ移行するための確認手順
古い表示を修正する際は、いきなりデザインを作り直さず、構造、文字コード、ファイル、リンクを順番に点検します。最初にトップページとフレーム定義を保存し、次に子フレームのHTML、画像、スタイルシート、JavaScriptを同じ構成で整理します。元のURLと保存後のURLを記録しておくと、相対パスの問題を発見しやすくなります。
確認の優先順位は、次のようにすると効率的です。
- HTMLファイルが正しい場所にあり、フレームの参照先が存在するか確認する
- Shift_JISなどの実際の文字コードとHTTPヘッダーを一致させる
- 画像の拡張子、MIMEタイプ、ファイル名の大文字小文字を調べる
- テーブル幅、フレーム幅、画像寸法、余白の指定を確認する
- JavaScriptを無効にしても主要な文章とリンクが利用できるか確かめる
- IE4.0相当の表示、現代ブラウザ、スマートフォンで結果を比較する
保存を目的にする場合は、元データを変更せず、修正版を別ディレクトリで公開します。noframesによる代替ページ、文字コードを明記した案内、画像の説明文を加えると、古い構造を知らない利用者にも内容が伝わります。フレームを廃止する場合は、各本文ページへ直接到達できるナビゲーションを作り、検索エンジンやアーカイブにも意味のある入口を用意します。
IE4.0での表示崩れを調べる作業は、古いブラウザを現代へ無理に合わせることではありません。どの仕様に依存していたかを把握し、必要な部分だけを保存し、利用可能な形へ整理する作業です。タイトルや画像が欠落しているサイトでも、HTMLの構造、リンク先、文字コード、サーバー応答を照合すれば、失われた表示の手がかりを積み重ねられます。
古いフレームサイトの復元や互換表示に取り組むときは、まずページ一式をバックアップし、文字コードとフレーム参照を確認してください。表示結果だけでなく、元ファイル、HTTPヘッダー、画像の実体、代替テキストを記録しておくことで、後から別のブラウザや保存環境でも検証できます。正確な復元と安全な公開を両立させ、過去のウェブ資料を読める状態で残しましょう。