文字コード戦争 — Shift_JIS vs EUC-JP vs UTF-8、日本語Webが経験した混沌

日本語の文字コード史は、1978年のJIS C 6226（後のJIS X 0208）から始まります。この規格は日本語で必要とされる文字として6,879文字を「区点コード」という体系で定義しました。

重要なのは、JIS X 0208は文字の集合と番号（区点コード）を定めただけで、コンピュータ上のバイト表現は規定していないという点です。この「番号はあるがバイト列が決まっていない」状態から、3つの符号化方式が生まれました。

Shift_JIS（正式にはJIS X 0208の附属書1で規定）は、1982年にアスキー社の技術者とMicrosoftが共同設計しました。設計の制約は厳しいものでした:

• JIS X 0201の半角カタカナ（0xA1-0xDF）をそのまま残す
• ASCIIの1バイト文字領域（0x21-0x7E）と重複しない
• 当時のMS-DOSで動作すること

これらを満たすため、2バイト文字の第1バイトを0x81-0x9Fと0xE0-0xEFに、第2バイトを0x40-0x7Eと0x80-0xFCに割り当てました。この「シフト」が名前の由来です。

5C問題 — バックスラッシュの罠

Shift_JISの最大の構造的欠陥は、2バイト文字の第2バイトに0x5C（バックスラッシュ / ¥記号）が現れることです。影響を受ける漢字の一部:

C言語やPerlでは0x5Cはエスケープ文字です。ファイルパスの区切り（Windows）でもあります。Shift_JISのテキストを1バイトずつ処理するプログラムは、「表」の第2バイトをバックスラッシュと誤認し、次のバイトをエスケープシーケンスとして食べてしまうのです。

「表示」「能力」「ソフト」— これらの日常的な単語がバグを引き起こすため、「ダメ文字」と呼ばれ、日本のプログラマの悩みの種でした。

EUC-JP（Extended Unix Code for Japanese）は、AT&TがUnix向けに設計した符号化方式です。設計思想はShift_JISと対照的でした:

• 2バイト文字は第1バイト・第2バイトともに0xA1-0xFE（最上位ビットが常に1）
• ASCIIの範囲（0x00-0x7F）と完全に分離
• JIS X 0212（補助漢字）にも対応（3バイトシーケンス）

最上位ビットで1バイト文字と2バイト文字を区別できるため、5C問題は原理的に発生しません。grepやsedなどのUnixツールとの相性がよく、1990年代のLinuxサーバーやSolarisでは事実上の標準でした。

しかし問題もありました:

• 半角カタカナに0x8E（SS2）プレフィックスが必要で2バイトになる
• Windows上ではほぼ使われない（Windowsの内部コードはShift_JIS → UTF-16）
• Webブラウザでの自動判別精度がShift_JISに劣ることがあった

結果として、サーバーサイドはEUC-JP、クライアント（ブラウザ）はShift_JISという分裂が生まれました。PHPのmb_convert_encoding()やPerlのEncodeモジュールが重宝された理由です。

電子メールにはさらに別の文字コードが使われていました。ISO-2022-JP（通称「JISコード」）は、RFC 1468 (1993) で定義された7ビット完結の符号化方式です。

なぜ7ビット？ 1980-90年代のメールサーバー（MTA）には、8ビット目を勝手に落とす実装が存在しました。Shift_JISやEUC-JPは8ビットを使うため、そうしたサーバーを経由すると文字化けします。ISO-2022-JPはエスケープシーケンスで文字集合を切り替えることで、7ビットの範囲内ですべてを表現します。

ESC $ B  → JIS X 0208 (日本語) に切り替え
ESC ( B  → ASCII に切り替え

例: "Hello世界" の場合
Hello ESC$B @$3& ESC(B

RFC 2047 (MIME) によるヘッダーのBase64/Quoted-Printableエンコーディングと組み合わせ、日本の電子メールは2010年代までISO-2022-JPが標準でした。Gmailがメール送信にUTF-8をデフォルトにしたのは2012年頃のことです。

「Windowsで作った文書をMacで開いたら①が(日)になった」— これが機種依存文字（プラットフォーム依存文字）の問題です。

原因は、Shift_JISの未使用領域（0xF040-0xFCFC、いわゆる「外字領域」）に、MicrosoftとAppleが異なる文字を割り当てたことです。

さらに、MicrosoftのShift_JIS実装であるCP932 (Windows-31J)は、JIS X 0208にない文字（①②③、㈱、㍉、ローマ数字など）を独自に追加しました。つまり「Shift_JIS」と「CP932」は厳密には別物です。

Webでcharset=Shift_JISを指定しても、ブラウザは実質的にCP932として解釈します。WHATWGのEncoding Standardでは、Shift_JISというラベルはCP932にマッピングすると明記されています。

1999年、NTTドコモのi-mode開発チームの栗田穣崇氏が、12×12ピクセルの絵文字176種を設計しました。携帯メールで感情を伝えやすくする目的でしたが、これが文字コードの新たな戦場を生みました。

au (KDDI) とSoftBank (旧Vodafone) も独自の絵文字を実装。3社の絵文字はコードも図柄もバラバラで、キャリア間メールでは変換テーブルが必要でした。変換できない絵文字は〓（ゲタ）に置換されました。

Unicode 6.0 (2010) — 絵文字の統一

GoogleのMark DavisとMarkus Schererが2007年にUnicode Consortiumに絵文字の提案書を提出。Appleも賛同し、2010年のUnicode 6.0で722個の絵文字がUnicodeに正式収録されました。

2026年現在、Unicode 16.0には3,790以上の絵文字が収録されています。日本のガラケー文化が生んだ独自拡張が、世界標準になった稀有な例です。

日本語の文字コード判定は確率的な推定であり、100%の正解は原理的に不可能です。理由は以下の通り:

• Shift_JISとEUC-JPのバイト範囲が重なる領域がある
• 短いテキスト（数文字）では統計的な判断材料が不足する
• 半角カタカナのみのテキストはShift_JISとEUC-JPで区別できないケースがある

代表的な判定ライブラリとそのアプローチ:

これらのツールでも、例えば「カナ」の3文字だけを判定させると、Shift_JISともEUC-JPとも解釈可能なため誤判定することがあります。

2000年代後半から2010年代にかけて、日本のWebは段階的にUTF-8へ移行しました。主なマイルストーン:

UTF-8がShift_JISとEUC-JPの両方を置き換えられた理由は明確です:

• 5C問題がない — UTF-8の継続バイトは0x80-0xBFで、ASCII範囲と重複しない
• 1つのコードで統一 — サーバー/クライアント/メール/DBすべてUTF-8にすれば変換が不要
• 絵文字に対応 — Shift_JIS/EUC-JPではUnicode絵文字を表現できない
• 国際化が容易 — 多言語混在テキスト（日英中韓混在）も1エンコーディングで完結

UTF-8がWebを制覇した2026年でも、Shift_JIS（CP932）が使われ続けている領域があります:

• Windowsコマンドプロンプト (cmd.exe) — デフォルトのコードページは932 (Shift_JIS)。PowerShellやWindows TerminalではUTF-8がデフォルトになったが、レガシーバッチファイルはShift_JIS前提
• CSVファイル — ExcelはBOM付きUTF-8でないとCSVを正しく開けない。多くの業務システムが「Excel互換」のためShift_JIS CSVを出力
• 官公庁・金融のレガシーシステム — COBOLやメインフレームとの接続でShift_JISやEBCDICが健在
• 一部のゲーム機・組み込み機器 — メモリ効率やレガシー互換でShift_JISを使用

新規開発でShift_JISを選ぶ理由は皆無です。既存システムとのインターフェースでやむを得ず変換が必要な場合にのみ、iconvやプログラミング言語の変換ライブラリを使いましょう。

• 日本語の文字コードはJIS X 0208（1978年）の文字集合を3つの方式で符号化したことから分裂が始まった
• Shift_JIS: MS-DOS/Windows標準。半角カナ互換のため2バイト目に0x5C（バックスラッシュ）が出現する「5C問題」を抱える
• EUC-JP: Unix/Linux標準。最上位ビットで1バイト/2バイトを区別でき安全だが、Windowsでは普及せず
• ISO-2022-JP: メール標準。7ビット完結のためエスケープシーケンスで文字集合を切り替える
• 機種依存文字: Shift_JISの未使用領域にMicrosoftとAppleが異なる文字を割り当て、クロスプラットフォームで文字化け
• 絵文字: ドコモ・au・SoftBankの独自実装 → Unicode 6.0 (2010) で世界標準に
• UTF-8がすべてを解決: 5C問題なし、変換不要、絵文字対応、国際化対応
• 新規開発はUTF-8一択。レガシーとの接続のみ変換ツールを活用