一九九〇年代、日本語ウェブの文字コードは何を伝えていたか
一九九一年、世界最初のウェブサーバーがスイスで起動したとき、日本語はその枠組みの中にまだ居場所を持っていませんでした。ティム・バーナーズ＝リーが設計したHTTPとHTMLは、英語圏のアルファベットと数字、そして少数の記号を扱う前提で作られていました。当時のページが読み書きできるのは事実上ASCIIの範囲に限られており、日本語の文字は画面に表示されることすら叶わなかったのです。
しかし同時に、日本国内ではパソコン通信や電子掲示板といった草の根のネットワークが既に数千の漢字をやり取りしていました。その蓄積をウェブに持ち込もうとした技術者たちは、早急に文字を運ぶ仕組みを考えなければなりませんでした。平仮名、片仮名、漢字、そして記号類を、欧米生まれの小さな枠の中に押し込める作業は、文字コードという静かな戦場の始まりでもありました。
一九九〇年代を通じて、この問題は試行錯誤の連続でした。ある時期は読めたページが、別の年には文字化けで判読不能になる。リンクを辿るたびに、まるで暗号が切り替わるかのように文字列が崩れていく。日本語ウェブの黎明期には、そうした光景が日常的に繰り広げられていました。
今日、古い個人サイトや企業のアーカイブを開くと、ときどき当時の名残に出会うことがあります。壊れたレイアウト、表示されない画像、そして何より意味の通らない記号の羅列。それらは単なる失敗ではなく、九〇年代に何が標準であり、何が過渡期にあったかを示す歴史的な痕跡でもあります。
ASCIIとLatin-1が支配した黎明期
一九九一年から一九九三年にかけて、日本から発信されたウェブページの多くは、英語を前提としたコードで書かれていました。利用されていたのはUS-ASCIIと、それを西欧向けに拡張したISO-8859-1、通称Latin-1です。これらのコードは七ビットまたは八ビットで一文字を表現し、アルファベット、数字、基本的な記号を網羅していました。
日本語の文字を扱うにはまったく足りないこの枠組みの中で、日本語版のページを作ろうとした人々は、いくつかの苦肉の策を取りました。最も単純だったのは、ローマ字で日本語を記述する方法です。「こんにちは」を「konnichiha」と書き、外国人にも分かる形で挨拶を伝える工夫がなされました。
もう一つの手段は、画像化されたテキストの利用でした。GIF形式で出力された日本語の文字列は、どのブラウザでも正しく表示できました。サイズが小さく、レイアウトも崩れず、しかし検索エンジンには引っかからず、音声読み上げにも対応しない。視覚的な妥協と引き換えに、確実な伝達を実現したのです。
一九九三年頃になると、Mosaicや早期のNetscapeがリリースされ、状況が大きく変わりつつありました。マルチメディアへの対応が進む中で、日本語表示への期待も膨らんでいきました。それでも、当時はまだ日本語を直接表示できる環境はごく限られており、文字の壁は厚く立ちはだかっていました。
Shift_JISがWindowsと共に広まった理由
一九九五年を境に、状況は一変しました。Windows 95の発売と共に、日本語版Windowsが世界的に普及し、Windows版のNetscape NavigatorやInternet Explorerが日本語を直接表示するようになったのです。このとき、標準として採用されたのがShift_JISでした。
Shift_JISは、マイクロソフトが開発した文字コードで、JIS X 0208で定義された六千三百余りの漢字や仮名を、パソコンで扱いやすい形に配置していました。一文字を二バイトで表現し、ASCIIコードと衝突しないように工夫された設計は、当時のハードウェアとソフトウェアにとって扱いやすいものでした。
特に重要なのは、Windows環境で作成されたファイルとウェブページが、原則としてShift_JISで保存されていたことです。テキストエディタで日本語を書き、そのままFTPでアップロードすれば、ブラウザでも日本語が表示される。日本語を母語とする制作者にとって、この一連の流れは劇的な利便性向上でした。
Shift_JISには独特の癖もありました。半角カタカナの扱いです。一バイトの領域に片仮名の一部が詰め込まれたこの設計は、当時の通信容量が貴重だった背景を反映していますが、同時に多くの混乱を生む原因ともなりました。一九八〇年代のパソコン通信で培われたこの慣習は、ウェブの時代になっても長く尾を引くことになります。
EUC-JPがUNIX系サーバーで重用された背景
Windows陣営がShift_JISを採用する一方で、UNIX系のサーバーではEUC-JPが事実上の標準でした。EUCとはExtended Unix Codeの略称で、日本語版UNIXであるFreeBSD、Linux、Solarisなどにおいて標準的に使われていた文字コードです。
EUC-JPは、JIS X 0208とJIS X 0212という二種類の漢字集合を効率良く扱うことを目指して設計されました。一バイトでASCIIを表現し、二バイトで漢字を表現するという構造は明確で、サーバーサイドでの処理に適していました。
一九九〇年代後半、日本の学術機関や大手企業のサーバーでは、このEUC-JPが広く採用されました。CGIやPerl、Pythonなどのサーバーサイドスクリプトも、UNIX環境との相性が良く、EUC-JPへの対応が進んでいたのです。掲示板ソフトやアクセスカウンタ、メールフォームなど、日本語処理を前提としたシステムは、EUC-JPを前提に作られることが一般的でした。
結果として、同じ日本語のページを見ているはずなのに、アクセスする環境やリンク元の違いによって、文字化けが発生するという現象が頻発しました。Shift_JISで書かれたページがEUC-JPのサーバーから配信されれば、読者の画面には意味の通らない記号が並びます。逆もまた同様でした。この混沌こそが、九〇年代日本語ウェブの特徴の一つでした。
JISコードとISO-2022-JPの特殊な役割
Shift_JISやEUC-JPが主流となる中でも、ISO-2022-JP、通称JISコードは電子メールの分野で特別な地位を保ち続けました。RFC 1468として標準化されたこのコードは、エスケープシーケンスを使って文字集合を切り替える仕組みを持っていました。
ISO-2022-JPの最大の特徴は、七ビットで日本語を伝えられる点にあります。ASCIIと同じ七ビットの枠組みの中で、「これから漢字を伝えます」というシグナルを送受信し、その後再びASCIIに戻る。インターネットの初期、中継されるメールサーバーが七ビット制限を持っていた時代には、この特性が決定的に重要でした。
ウェブの世界でも、メールフォームの処理やニュースグループへの投稿においては、ISO-2022-JPが活躍しました。受け取った文字列を内部でShift_JISやEUC-JPに変換し、表示するという工程は、当時のCGIスクリプトではお馴染みの処理でした。
しかし、エスケープシーケンスを正しく解釈できない環境では、JISコードはまるでノイズのように表示されます。Windows版の初期ブラウザの中には、JISコードの扱いに難があるものも少なくなく、このコードが一般のウェブページで広く使われることは、結局ほとんどありませんでした。
半角カタカナ問題と文字化けの時代
一九九〇年代の日本語ウェブを語る上で、半角カタカナの存在を無視することはできません。これは文字コードの問題というよりも、表示上の問題でしたが、結果としてウェブ文化全体に強い影響を残しました。
半角カタカナは、Shift_JISの一バイト領域に収められた片仮名で、狭いスペースに文字を詰め込むことができました。タイトルバーやメニューのような場所では重宝された一方、本文中にこれが混ざると、表示環境によって幅が異なり、レイアウトが崩れる原因となりました。
文字化けもまた、九〇年代日本語ウェブの名物でした。「ããã«ã¡ã¯」「・｣・ｿ・､・ｧ・ｹ」のような無意味な文字列を見たことがある人は少なくないはずです。これは、文字を送り出した側と受け取った側で異なる文字コードが仮定されたときに発生する現象です。
ブラウザの「自動判定」機能が発達したのは、まさにこの問題への対応でした。Internet ExplorerやNetscape Navigatorは、受信したバイト列のパターンから文字コードを推測し、適切な表示を試みる機能を備えていました。しかし、この推測は完全なものではなく、ページごとに設定を切り替える必要が残りました。当時のユーザーは、メニューから「エンコード」を選び、「日本語（シフトJIS）」「日本語（EUC）」「日本語（自動選択）」を何度も切り替えることを強いられたのです。
ブラウザ戦争が運んだ仕様の分裂
一九九〇年代後半、Internet ExplorerとNetscape Navigatorの激しい競争が繰り広げられました。このブラウザ戦争は、単なる市場シェア争いだけでなく、文字コードの扱い方にも深い影響を及ぼしました。
Internet Explorerはマイクロソフト製であるため、当然ながらWindows環境のShift_JISと深い親和性を持っていました。これに対し、Netscape Navigatorはマルチプラットフォーム志向で、UNIX環境を含む様々なシステムで動作することを目標としていました。
この違いが、ウェブページの制作者を悩ませました。新しいHTMLタグやJavaScriptの一部は、片方のブラウザでしか動かないことがありました。文字コードの宣言もそうで、Internet Explorerはある特定のHTMLの解釈方法で文字コードを認識し、Netscapeは別の方法を用いる。制作者は、両方のブラウザで問題なく表示されるよう、細心の注意を払う必要がありました。
charset属性やmetaタグによる文字コード宣言の仕様が安定するまでに、時間がかかりました。HTML 4.01の勧告が一九九九年十二月に出されるまで、UTF-8を正式にサポートするブラウザは限られており、九〇年代末になっても、日本語ページの多くは依然としてShift_JISかEUC-JPで書かれていました。
UTF-8の登場と世紀末の静かな予兆
一九九〇年代の終わり近く、それまでの状況を一変させる可能性を持った規格が登場しました。UTF-8です。これは、Unicodeの文字を八ビット単位で扱う可変長のエンコード方式で、一九九三年頃に設計されました。
UTF-8の革新性は、英語圏のASCIIと完全な互換性を持っていた点にあります。英数字と一部の記号は、一バイトで従来通り表現されます。これは、ASCII圏のシステムに追加の変更をほとんど必要としないということを意味し、UTF-8の普及を後押しする重要な要因となりました。
一九九〇年代末には、Netscape Navigator 4やInternet Explorer 4以降がUTF-8をサポートするようになり、いくつかの先進的なウェブサイトがこの新しいコードを試み始めました。特に学術的なサイトや、海外との連携を意識した国際的なプロジェクトでは、UTF-8の採用が徐々に進みました。
一九九九年当時、日本国内でUTF-8は依然として少数派でした。既存のページとの互換性、エディタやサーバーの対応、そして何よりも「動いているから変えない」という保守的な姿勢が、新しいコードへの移行を阻んでいました。Shift_JISとEUC-JPの二大勢力が並立する構図は、世紀をまたいでもすぐには解消されなかったのです。
今日、あの時代の日本語ウェブを再訪するためのツールが揃いつつあります。古いブラウザの挙動を再現するビューアや、過去のURLを保存するデジタルアーカイブ。文字化けした文字列の中身を解読する技術も、少しずつ蓄積されてきました。九〇年代の日本語ウェブは、もはや消え去った過去の遺物ではなく、手を伸ばせば触れられる歴史として、私たちの目の前にあります。もし手元に古いバックアップや、かつてお気に入りに入れていたURLがあれば、ぜひそのページを開いてみてください。液晶画面の向こうに、九〇年代の息遣いが、崩れた文字の並びの向こうに、きっと待っているはずです。