古いJavaScriptを読み解くための実践的な視点
1990年代後半から2000年代初頭に作られたウェブページには、現在のJavaScriptとは異なる考え方で書かれたコードが残っています。特にNetscape Navigatorを対象にしたスクリプトでは、フレーム、レイヤー、ブラウザ判定、独自イベント処理などが密接に結び付いており、短いコードでも当時の環境を知らないと意味をつかみにくいものです。
古いサイトを調べるときは、文法だけを現代の基準で評価するのではなく、どのブラウザで、どのHTML構造を操作するために書かれた処理なのかを確認する必要があります。文字コードの崩れや欠落した画像、フレーム構成も手掛かりになります。表示結果が不完全でも、コードの変数名やURL、イベントの登録方法から設計意図を復元できる場合があります。
Netscape時代のJavaScriptを知る
Netscape向けのJavaScriptを読む際には、まず言語の誕生時期を意識します。初期のJavaScriptは、ブラウザ上で簡単な動きを加えるためのスクリプト言語として普及しました。現在のように標準化されたDOM APIや開発者ツールが整っていたわけではなく、ブラウザごとに利用できる機能が大きく異なっていました。
当時の資料ではJavaScriptをLiveScriptと呼んでいる例があり、Netscape Navigatorのバージョンによって実装差も見られます。document.writeによるHTML出力、フォーム部品の値変更、ステータスバーへの文字表示、ページ読み込み時の処理などが典型的な用途でした。コードに現れる機能名を見つけたら、現代のMDNだけで判断せず、対象ブラウザの世代を調べることが理解への近道です。
古いコードでは、スクリプトをHTMLコメントで囲む記述も頻繁に使われます。これはJavaScriptを実行できないブラウザにソースコードを表示させないための慣習でした。<!--と//-->の組み合わせがあっても、現代的なコメント処理として読むのではなく、当時の互換性対策として解釈します。
ブラウザ判定と分岐を読み解く
初期のウェブ開発では、ブラウザの種類を判定して異なるコードを実行する方法が一般的でした。navigator.appName、navigator.userAgent、navigator.appVersionなどの値を調べ、Netscape系ならdocument.layers、Internet Explorer系ならdocument.allを使うといった分岐がよく登場します。現代の環境ではほとんど意味を持たない判定でも、当時は画面表示を成立させる重要な条件でした。
ブラウザ判定を見つけたら、条件式だけでなく、その分岐の後で何が操作されているかを確認します。たとえば、Netscape側でレイヤーの位置や表示状態を変更し、別の分岐で要素のスタイルを変更しているなら、目的はメニューの開閉やアニメーションだった可能性があります。判定対象の名前に引きずられず、変更されるプロパティから機能を推測することが大切です。
userAgentを文字列検索して判断するコードでは、完全一致ではなく部分一致や大文字小文字の違いにも注意します。古いサイトには、特定のバージョン番号を前提にした条件や、未知のブラウザをまとめてNetscape側へ送る処理が残っていることがあります。分岐の順序を変えると挙動が変わるため、条件を現代化する場合も、まず元の優先順位を記録しておきます。
レイヤーとフレームの役割を整理する
Netscapeのdocument.layersは、当時のレイヤー要素を操作するための代表的な仕組みです。レイヤーは現在の標準的なHTML要素とは異なり、独立した表示領域として扱われることがありました。document.layers["menu"]のような記述があれば、メニューやポップアップ、重ね合わせた画像などを制御している可能性があります。
レイヤー内部の文書を参照するために、document.layers[name].documentのような階層が使われる場合もあります。最初に外側のレイヤーを取得し、次にその内部のリンクやフォームへアクセスする構造です。現代のDOM操作に置き換える際は、単純にdocument.getElementByIdへ変換するのではなく、外側の表示領域と内側の文書が担っていた役割を分けて確認します。
フレームを使ったサイトでは、parent、top、self、framesといった参照が頻繁に現れます。ナビゲーション用フレームから本文フレームを変更するなら、parent.main.locationやtop.frames["main"]のような記述になることがあります。リンク先だけを見ていると処理の目的を誤認しやすいため、どのウィンドウ階層のURLを変更しているかを図にして整理すると効果的です。
フレームを使わずに同等のレイアウトを再現する場合は、構造をCSSへ置き換える考え方も役立ちます。古い画面の区画を現代のレイアウトへ移行する際には、CSSによる代替案のような発想を参照し、表示領域、固定メニュー、本文の関係を一つずつ分離すると、JavaScriptの役割も見えやすくなります。
イベント処理の古い作法を確認する
初期のJavaScriptでは、HTMLタグに直接イベント属性を書く方法が主流でした。onload、onclick、onmouseover、onmouseoutなどがbodyやa要素に埋め込まれ、マウスを乗せたときに画像を交換したり、ページ読み込み時に初期化関数を呼び出したりします。イベントリスナーを登録する現代の書き方とは異なり、HTMLと処理が強く結び付いています。
画像のロールオーバー処理では、document.images、new Image()、srcの代入がよく使われます。読み込み前に別画像を生成しておき、マウス操作に応じて表示画像を差し替える仕組みです。画像ファイル名にover、on、off、hoverなどの語が含まれていれば、対応する通常画像と強調画像の組み合わせを推測できます。
イベントハンドラが文字列として設定されている場合や、evalで関数名を組み立てている場合は、実際の実行経路を慎重に追います。変数に入った名前がどの関数へ結び付くのか、同じイベントが複数の箇所で上書きされていないかを確認する必要があります。イベント処理を現代化するときは、元の順序を保ちながら一つの責務へ整理すると、意図しない動作を抑えられます。
文字コードとHTML構造を手掛かりにする
古い日本語サイトでは、JavaScriptの問題に見えて実際には文字コードの不一致が原因ということがあります。Shift_JISで保存されたHTMLをUTF-8として解釈すると、日本語の文字列だけでなく、コメント、画像の代替テキスト、URLに含まれる文字まで崩れます。まずHTTPヘッダー、meta要素、実ファイルの保存形式を確認し、どの段階で変換が起きたのかを切り分けます。
文字化けしたソースでも、英数字の関数名や拡張子、区切り記号は比較的読み取れます。location.href、window.open、document.writeなどの定型的な記述を目印にし、前後の文字列を少しずつ復元します。日本語のメニュー名が失われていても、リンク先のファイル名やフレーム名から、ホーム、案内、本文といった役割を推測できることがあります。
HTMLの閉じタグが欠けている場合は、ブラウザが自動補正した結果と元のソースを区別しなければなりません。特に古いフレームページでは、frameset、frame、noframesの構造が通常のbodyと異なります。表示画面だけを基準にDOMを想像すると、スクリプトが参照するウィンドウ階層を取り違える可能性があります。
コードを安全に実行して調査する
古いJavaScriptを調べるために、現行ブラウザへそのまま読み込む方法は安全とは限りません。外部サイトへの送信、ポップアップの大量生成、無限ループ、書き換えられたリンクへの遷移などが起こる可能性があります。調査用のローカル環境を用意し、ネットワークを制限したうえで、元ファイルのコピーを使って検証するのが基本です。
最初に行うのは実行ではなく、静的な確認です。関数名、グローバル変数、外部スクリプト、Cookie操作、フォーム送信先、document.writeの使用箇所を記録します。その後、コメントアウトやログ出力を加え、ページ読み込み、マウス操作、リンククリックのどの段階で処理が動くのかを確認します。元ファイルを直接編集せず、変更履歴を残すと比較が容易になります。
危険な処理としては、eval、動的に生成されたURL、入力値をそのままHTMLへ連結する処理に注意します。古いコードの読み解きは保存や再利用を意味しないため、当時動いていたから安全だと判断してはいけません。動作の再現と本番投入を明確に分け、移植する場合は入力検証、出力エスケープ、同一生成元の制約を現代の基準で改めて設計します。
現代のコードへ置き換える手順
古いスクリプトを修正する際は、最初から全面的に書き換えるより、機能を小さな単位へ分解する方が安定します。まず、ブラウザ判定、表示切り替え、リンク遷移、画像交換、フォーム検証などの役割を分類します。次に、どの処理が現在も必要で、どの処理が当時の互換性対策として不要になったのかを判断します。
document.layersやdocument.allに依存する分岐は、標準DOMとCSSへ移行できます。表示非表示は可能ならstyle.displayを直接書き換えるより、クラスを付け外しする方法が管理しやすくなります。フレーム間通信は、単に一枚のページへ統合するのか、複数の領域を維持するのかを先に決め、URL履歴や戻る操作への影響も確認します。
古いコードの変数は、短い一文字名や用途不明の略語になっていることがあります。挙動を確認した後で、nをナビゲーション要素、imgOnを有効状態の画像のように、意味が伝わる名前へ変更します。ただし、名前変更と機能変更を同時に行うと原因追跡が難しくなるため、段階ごとに動作確認を実施します。
読み解きの記録を未来へ残す
解析結果は、修正後のコードだけでなく、元の環境と推測した目的も記録しておくと価値があります。対象ブラウザ、想定画面サイズ、文字コード、フレーム構成、利用画像、イベントの発火条件を簡潔にまとめれば、後から別の担当者が判断を再現できます。失われた画像や読めない日本語がある場合も、確定事項と推測事項を分けて書くことが重要です。
復元作業では、ソースコード、画面キャプチャ、ネットワーク記録、変換前後のファイルを別々に保存します。ファイル名やパスの変更履歴も残しておけば、リンク切れが元から存在したのか、移行時に生じたのかを区別できます。古いJavaScriptの挙動を完全に再現できない場合でも、何が判明し、何が不明なのかが明確なら、資料として十分な成果になります。
Netscape向けのコードは、単なる古い記法の集まりではありません。限られたブラウザ機能、通信速度、表示領域、当時のサイト構造に合わせた設計の記録です。ブラウザ判定、レイヤー、フレーム、文字コード、イベント処理を順に読み解けば、崩れた表示の背後にあるページの構成と目的を少しずつ復元できます。
手元に残る古いHTMLやJavaScriptを一つ選び、元ファイルを保存してから、関数、参照先、イベント、文字コードの順に記録してください。安全な検証環境で当時の動きを確かめ、現代の標準技術へ置き換えた結果と元の挙動を並べて残すことで、失われかけたウェブ資産を読みやすい資料へ変えられます。