テキストファイルを開いたら「锟斤拷烫烫烫」や「â¥人」のような謎の文字が表示された経験はありますか？API から取得した日本語が全部「??」になってしまった、なんてことも。こうした問題のほとんどは、一つの原因に行き着きます：文字エンコードの不一致です。文字エンコードを理解することは、技術的な問題を解決するだけでなく、コンピュータがどのように文字を処理しているかを理解する基礎となります。
1. 文字と数字：コンピュータはどう文字を保存する？
コンピュータの内部は 0 と 1 しかありません。文字を保存するには「文字→数字」の対応表が必要です——「65 は大文字の A」「12354 はひらがなの『あ』」という具合に。この対応ルールが文字エンコード（Character Encoding）です。
文字エンコードには2つの要素があります：
- 文字集合（Character Set）：「どんな文字があるか」と各文字の番号（符号点、Code Point）を定義する
- エンコーディング方式：「その番号をバイト列でどう表現するか」を定義する
この区別は重要です：Unicode は文字集合（14万以上の文字に番号を付けた規格）、UTF-8 はそのエンコーディング方式（番号をバイトに変換する規則）です。
2. ASCII：すべての始まり
1963 年、米国規格協会（ANSI）が ASCII（American Standard Code for Information Interchange） を制定しました。7ビットで128文字（0–127）を定義し、英文字・数字・記号・制御文字をカバーします。
ASCII は英語には最適でしたが、128文字ではヨーロッパの重音文字も、日本語も、中国語も到底収まりません。
設計者は大文字と小文字の差を32（6ビット目の差）にしました。1ビットを反転するだけで大小変換できる、という巧みな設計です。Python で
ord('A') == 65、ord('a') == 97 となるのはその名残です。
3. 群雄割拠の時代：Shift-JIS・EUC-JP・Big5・GBK
ASCII では不十分だったため、各地域・組織が独自に拡張を始めました。これが文字化け問題の元凶です。
3.1 日本語：Shift-JIS と EUC-JP
Shift-JIS（シフト JIS）は1バイトと2バイトが混在する可変長エンコーディングで、Windows 日本語版で長年デフォルトとして使われてきました（コードページ 932）。EUC-JP は Unix/Linux 系で広く使われたエンコーディングです。この2つは互換性がなく、ファイルを相互に開くと文字化けが発生します。
3.2 中国語（繁体字）：Big5
Big5 は1984年に台湾で制定された繁体字中国語エンコーディングで、約13,060文字の常用漢字を収録します。
3.3 中国語（簡体字）：GB2312 / GBK
中国大陸では 1981 年制定の GB2312（6,763文字）が後に GBK（21,003文字）へと拡張されました。Windows 簡体字中国語版のデフォルトです。
| エンコーディング | 対象言語 | 文字数 | バイト/文字 | 主な使用地域 |
|---|---|---|---|---|
| ASCII | 英語 | 128 | 1 | 全世界（英語） |
| Shift-JIS | 日本語 | 約 6,879 | 1–2 | 日本 |
| EUC-JP | 日本語 | 約 6,879 | 2–3 | 日本（Unix系） |
| Big5 | 繁体字中国語 | 13,060 | 2 | 台湾・香港 |
| GBK | 簡体字中国語 | 21,003 | 2 | 中国大陸 |
| UTF-8 | すべての言語 | 140,000+ | 1–4 | 全世界 |
4. Unicode：分裂を終わらせた統一規格
1991 年に Unicode 1.0 が登場し、世界中の文字に唯一の符号点（Code Point）を割り当てました（U+十六進数で表記）：
U+0041→ 大文字の AU+3042→ ひらがな「あ」U+4E2D→ 漢字「中」U+1F600→ 😀（笑顔の絵文字）
現在 Unicode 14.0 では 159 の文字体系にわたる 144,697 以上の文字を定義しています。
最も多い誤解がこれです。Unicode は「文字に番号を付ける規格」、UTF-8 は「その番号をバイトで表現する方式」です。UTF-8 は Unicode を実装するエンコーディングの一つで、UTF-16 や UTF-32 もあります。
5. UTF-8：なぜ世界標準になったのか
UTF-8 は1992年に Ken Thompson と Rob Pike が設計した可変長エンコーディングで、符号点の大きさに応じて 1〜4 バイトを使います：
- 1 バイト：ASCII 範囲（U+0000–U+007F）——UTF-8 は ASCII と完全な後方互換性を持つ
- 2 バイト：大部分のヨーロッパ言語文字
- 3 バイト：日本語・中国語・韓国語など（U+0800–U+FFFF）
- 4 バイト：絵文字・古代文字（U+10000 以上）
UTF-8 が世界の Web ページの 97% 以上で使われる理由：
- ASCII との後方互換性：英文コンテンツは変換不要で既存システムと共存できる
- 自己同期性：ストリームのどこからでも正しくデコードできる
- バイト順問題なし：UTF-16/32 と違いバイトオーダー（エンディアン）の問題が生じない
- バランスの良いサイズ効率：英語 1 バイト、日本語 3 バイト
| エンコーディング | バイト数/文字 | ASCII 互換 | バイト順問題 | 主な用途 |
|---|---|---|---|---|
| UTF-8 | 1–4（可変） | あり | なし | ネット通信・ファイル保存 |
| UTF-16 | 2 または 4 | なし | あり（BOM 必要） | Windows 内部・Java 文字列 |
| UTF-32 | 4（固定） | なし | あり | 内部処理・高速インデックス |
6. 文字化けはなぜ起きる？
文字化けとは、バイト列を間違ったエンコーディングで解読することです。典型的なケースを見てみましょう：
6.1 Shift-JIS ファイルを UTF-8 で開く
Shift-JIS でエンコードされた日本語のバイト列は UTF-8 の規則に従っていないため、「â–»」や「?」として表示されます。
6.2 Big5 と GBK の相互誤読
Big5 と GBK は文字空間が重複しており、同じバイト値が全く異なる文字を指すことがあります。
6.3 データベースの「??」問題
MySQL の接続文字セットが latin1 なのに UTF-8 エンコードの日本語を保存しようとすると、解読できないバイトが ? に変換されます。この変換は不可逆で、元のデータは永久に失われます。
「锟斤拷」は GBK 環境下で UTF-8 の代替文字（U+FFFD、バイト列
EF BF BD）を誤読したものです。「烫烫烫」は初期化されていないメモリの埋め値 0xCDCD を GBK で表示した結果です。これらは中国語圏での文字化けの典型例として有名です。
7. URL エンコードと文字エンコード
URL に使えるのは限られた ASCII 文字だけなので、日本語などはパーセントエンコーディング（Percent-Encoding）が必要です：UTF-8 のバイト列の各バイトを %XX（16進数）で表します。
例：「日本語」→ %E6%97%A5%E6%9C%AC%E8%AA%9E
現代の標準（RFC 3986）では URL エンコードは UTF-8 ベースと明確に規定されています。
8. 文字化けを根本的に防ぐ方法
文字化けを防ぐ根本的な解決策は、システム全体で UTF-8 を統一することです：
- ファイル：テキストファイルは UTF-8（BOM なし）で保存
- HTML：
<head>の最初に<meta charset="UTF-8">を記述 - データベース：
CHARACTER SET utf8mb4を使用（MySQL のutf8は絵文字などの 4 バイト文字に非対応のためutf8mb4を使うこと） - DB 接続：
SET NAMES utf8mb4または PDO のcharset=utf8mb4 - HTTP ヘッダー：
Content-Type: text/html; charset=utf-8
9. まとめ
文字エンコードの歴史は、バラバラな規格が統一されていく歴史です：
- ASCII（1963）：128 文字で英語のデジタル化を実現
- 群雄割拠の時代：Shift-JIS、GBK、Big5 が乱立し、文字化けが頻発
- Unicode（1991+）：すべての文字に唯一の符号点を付与する統一規格
- UTF-8（1992+）：ASCII 互換・省スペース・エンディアン問題なし、世界の 97% 以上の Web ページで採用
技術スタック全体（ファイル・コード・DB・HTTP ヘッダー）で UTF-8 を統一すれば、文字化けはほぼ発生しません。文字化けが起きたときは、どの段階でエンコーディングの宣言と実際の保存が食い違っているかを探すことで、素早く解決できます。