文字化けのパターンを31種・10分類で図鑑形式にまとめ、加えてなぜ起きるか（文字コードの基礎）と直し方（実体験を含む実用解説）まで一括で解説しました。「繝・繝ｪ・縺」のようなUTF-8↔Shift-JIS誤認、英語圏で頻出の「café」「don’t」、置換文字「�」、豆腐「□」、HTMLエンティティ「&」が消えない、URLエンコード「%E6%96%87」がそのまま表示、BOMが「」と見える──といった代表パターンを網羅。文字化けは「保存時のエンコード」と「読み出し時のデコード」がズレることで発生する単純な現象で、原理が分かれば直し方の見通しも立ちます。漢字・文字シリーズの動物を表す漢字157選・2ちゃんねる用語・ネットスラング102選（AA・顔文字＝文字コード文化の系譜）もあわせてどうぞ。
文字化けのパターン31種（10分類）
実際に目にする文字化けを、原因系統で10分類・合計31パターンに整理しました。「見覚えのある化け方」から逆引きしてください。
A. UTF-8 ↔ Shift-JIS 系（3種・日本語圏で最頻出）
UTF-8で保存された日本語をShift-JISとして読み込むと起きるパターン。日本のWeb・メール・ファイルの文字化けの大半がこれに分類されます。
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| 譁・ｭ怜喧縺・ | 「繝」系・カタカナ系の化け | UTF-8（「文字化け」）をShift-JISと誤認 |
| ・・繧・繝サ多発 | 中黒「・」多発の化け | UTF-8の3バイト文字の途中バイトがShift-JIS未割当領域に当たり中黒に置換 |
| ｱ｢｣・ｲｳ系 | 半角カタカナ風の化け | UTF-8の特定バイト範囲がShift-JISの半角カナ領域と一致する誤認 |
B. UTF-8 ↔ Latin-1 / Windows-1252 系（5種・英語圏で頻出）
UTF-8の西欧アクセント・スマート引用符などを、古い1バイトコードLatin-1（ISO-8859-1）またはWindows-1252として読み込むと起きるパターン。英語圏で「Mojibake」と呼ばれる代表例です。
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| café | 「Ã」付きアクセント化け | UTF-8の「é（C3 A9）」をLatin-1で「é」と読む |
| don’t | 「’」アポストロフィ化け | UTF-8の「’（U+2019）」をWindows-1252で「’」と読む |
| â€" / â€" | em/enダッシュ化け | UTF-8のem/enダッシュ（—／–）の3バイトが「â€」と化ける |
| “ ... †| スマート引用符化け | 「""」のスマートクォートが「“」「â€」と化ける |
| ñ・ó・á | 西欧アクセント全般の化け | UTF-8のñ・ó・áがLatin-1で「Ã+別文字」に化ける |
C. 置換・不明文字（3種）
デコード失敗時にシステムが代替表示する文字。具体的な化け方というより「文字情報の喪失」を示すサインです。
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| � | 置換文字（U+FFFD REPLACEMENT CHARACTER） | デコーダが解釈不能なバイトをこの文字に置き換える |
| □ | 豆腐（とうふ／tofu） | フォントに対応するグリフ（字形）が存在しない |
| ? | クエスチョン置換 | エンコード変換時に対応コードが無くフォールバック |
D. エンコード残骸（デコード忘れ・5種）
文字化けというより「エンコード文字列がデコードされず生で表示」されているケース。表示処理の手順抜けで起きます。
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| あ | Unicodeエスケープが生 | JSON／JavaScriptで「あ」などがエスケープのまま出力 |
| & / あ / あ | HTMLエンティティが生 | テンプレートで二重エスケープ・デコード忘れ |
| %E6%96%87 | URLエンコードが生 | パーセントエンコードがdecodeされずそのまま表示 |
| =?UTF-8?B?...?= | MIMEヘッダBase64が生 | メールヘッダのRFC 2047エンコードが残ったまま表示 |
| =E6=96=87 | Quoted-Printableが生 | メール本文のQP符号化が残ったまま表示 |
E. BOM・不可視文字（3種）
見えない／見えないはずの制御文字が、特定の状況で可視化されたり挙動を狂わせるパターン。
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| （） | BOM残り | UTF-8 BOM（EF BB BF）がテキスト先頭に「ZWNBSP」として表示 |
| ZWSP（U+200B） | ゼロ幅スペース混入 | コピペ時に不可視のZWSPが混じり検索・比較がズレる |
| NBSP（U+00A0） | ノーブレークスペース | 通常の半角スペースと別文字。grep等で見落としやすい |
F. 二重デコード（2種）
一度文字化けしたデータが、さらに別のコードで再解釈されて連鎖的に崩壊するパターン。修復難易度が高くなります。
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| ã‚ã„ã†ã‡ã‰ | UTF-8の二重デコード | UTF-8→Latin-1→UTF-8と段階を経て元データが二重に化けた状態 |
| 再帰文字化け | リカーシブ・モジバケ | 化けたままDB保存→再表示で再デコード失敗→さらに化ける |
G. 機種依存文字・互換文字（3種）
文字コードの拡張領域や正規化方式の差で見た目や扱いが変わるケース。「化けて見える」より「環境で見え方が違う」パターンです。
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| ①②③ / ㈱ / ㊤ | 機種依存文字（CP932拡張） | Windows-31J（CP932）独自の領域で他環境では表示不能 |
| ﾓｼﾞﾊﾞｹ | 半角カナ | JIS X 0201由来。古いシステム間で全角/半角の変換ミスが起きやすい |
| が / が（NFC vs NFD） | 合成形と分解形の差 | NFC「が」とNFD「か+゛」が見た目同じでもバイト列が異なる（macOS↔Windows） |
H. 絵文字・サロゲートペア（3種）
Unicode拡張領域（U+10000以降）の文字をめぐる現代的な文字化けです。
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| 😀 → □ | 絵文字の豆腐化 | 絵文字対応フォントが無く□で代替表示 |
| 😀 → □□ | サロゲートペアの2文字化 | UTF-16表現で2つのコード単位（サロゲート）を別々の文字として誤表示 |
| 😀 ↔ 🤣 等の差 | プラットフォーム間の絵文字差 | iOS／Android／Windows／Twitterで同じコードポイントの絵が異なる |
I. 言語間の文字コード誤認（2種）
日本語コード同士、または日中の文字コードを取り違えるパターンです。
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| EUC-JP↔Shift-JIS 誤認 | 日本語コード間誤認 | UNIXで作ったEUC-JPのファイルをWindowsでShift-JISと誤認 |
| GB2312／Big5↔Shift-JIS 誤認 | 日中の文字コード誤認 | 中国語のGB2312（簡体）／Big5（繁体）テキストを日本語コードと誤認 |
J. その他（2種）
| 化けた見た目の例 | 通称 | 原因 |
|---|---|---|
| 文中の隠れた制御文字 | 制御文字・NUL混入 | 0x00〜0x1Fの制御文字・NULが混じり表示崩れや切れる |
| 文末の改行ズレ | 改行コード差 | LF（Unix）／CR（旧Mac）／CRLF（Windows）の差で表示・処理が崩れる |
文字コードの基礎（なぜ文字化けが起きるのか）
文字化けの根本原因はシンプルで、「保存時のエンコード（文字コード）」と「読み出し時のデコード」が一致していないだけです。同じバイト列でも、どの文字コードで解釈するかで全く違う文字に化けます。
主要な文字コード
| 文字コード | 概要・用途 |
|---|---|
| UTF-8 | Unicode可変長1〜4バイト。現在のWeb・ファイルの世界標準 |
| Shift-JIS | 日本のWindows系で長く使われた2バイトコード。Mojibakeの主原因 |
| EUC-JP | UNIX系で広く使われた日本語2バイトコード |
| ISO-2022-JP | 7ビット日本語メールで使われたエスケープシーケンス方式 |
| Latin-1（ISO-8859-1） | 西欧8ビットコード。café等のラテン拡張を1バイトで表す |
| Windows-1252 | Latin-1の拡張。スマートクォート等を含むWindowsの英語版コード |
| UTF-16 | 2バイト/4バイトのUnicode。Windows内部・JavaScript内部表現 |
| ASCII | 7ビット128文字。英数字・記号のみ。Unicode等の基礎 |
| Big5 | 繁体字中国語の伝統的コード |
| GB2312／GBK／GB18030 | 簡体字中国語の標準。GB18030は中国国家標準で必須 |
仕組み：同じバイト列・違う解釈
「文字化け」の3文字をUTF-8で保存すると E6 96 87 E5 AD 97 E5 8C 96 E3 81 91 の12バイトになりますが、これをShift-JISだと思って読み出すと「譁・ｭ怜喧縺・」のような別の文字列に解釈されます。保存と読み出しの規格が違えば、同じバイト列でも別の文字が現れる──これが文字化けの正体です。
文字化けの直し方
文字化けは原因の特定が9割。「どの文字コードで保存したものを、どの文字コードで読んでいるか」が分かれば、直し方は機械的に決まります。
1. ブラウザのエンコーディング変更
Chromeは現在UTF-8固定で変更不可ですが、Firefoxは「表示メニュー → テキストエンコーディング」から切り替えられます。一時的に文字コードを切り替えて中身を確認するのに有効です。
2. エディタで文字コードを指定して再オープン
VSCode・サクラエディタ・秀丸などのエディタは「ファイルを別のエンコーディングで開き直す」機能を持っています。文字化けしたファイルは、まず別のコードで開き直して中身を確認するのが第一歩です。
3. 変換コマンド（nkf／iconv）
LinuxやmacOSのターミナルでは、nkf や iconv で文字コードを変換できます。
- nkf -w in.txt > out.txt（→UTF-8に変換）
- iconv -f SHIFT_JIS -t UTF-8 in.txt > out.txt
4. HTMLの<meta charset>指定
WebページではHTMLの<head>内に <meta charset="UTF-8"> を入れることで、ブラウザに文字コードを明示できます。古いページでこれが抜けていると、ブラウザの推測が外れて化けます。
5. サーバー設定（.htaccess の AddCharset）— 実体験から
筆者のサイトでも実際に起きたケースですが、UTF-8で保存したテキストファイル（.txt）をサーバーに置いたところ、サーバーがそれをShift-JISと誤認して配信し、ブラウザ表示で日本語が化けてしまいました。原因はApacheの初期設定で、「.txtファイルはShift-JIS」と仮定してContent-Typeヘッダを送っていたためです。
解決策は、サイト直下の .htaccess に次の1行を追加するだけでした。
AddCharset UTF-8 .txt
これでサーバーが「.txtはUTF-8として配信せよ」とブラウザに伝えるようになり、文字化けは即座に解消しました。HTMLの<meta charset>が効くのはHTMLファイルだけで、純粋なテキストファイル（.txt）はサーバー側の設定が決定的に効く点に注意です。
6. データベースの文字コード
MySQLやMariaDBで日本語を扱う場合、utf8ではなくutf8mb4を指定するのが現代の正解です。utf8は3バイトまでしか扱えず、4バイトUTF-8（一部の絵文字・補助漢字）が化けます。
7. メールのエンコード設定
メーラの送信文字コード設定（UTF-8／ISO-2022-JP）が受信側と合っていないと化けます。古いメーラは半角カナ・絵文字の扱いに弱いので、注意が必要です。
8. BOMの付与・除去
UTF-8 BOM（先頭の EF BB BF）はWindowsで歓迎される一方、UNIX系のスクリプト先頭で問題を起こすことがあります。テキストエディタで「BOM無しUTF-8」「BOM付きUTF-8」を使い分けてください。
9. Unicode正規化（NFC／NFD）
macOSのファイル名はNFD（分解形）、Windowsや一般的なテキストはNFC（合成形）で扱われがちです。ファイル交換時に「が」が「か+゛」に分離していないか確認し、必要ならPythonのunicodedata.normalize("NFC", s)等で変換します。
文字化けの豆知識
「mojibake」は英語圏でも通じる
文字化けを表す英単語は……ありません。Mojibakeという日本語そのものが英語圏で外来語として定着し、Oxford English Dictionary（OED）にも収録されています。文字化けが世界共通の現象であり、かつ日本語圏が真っ先に・最も激しく経験した現象であることの証です。
「豆腐（tofu）」も国際用語
フォントにグリフが無いときの「□」も、英語圏でtofu（豆腐）と呼ばれます。Googleは「No more tofu（豆腐撲滅）」というスローガンで、Notoフォントファミリー（Noto = No tofu の短縮）を開発しました。Noto Sans／Noto Serifの名前の由来はここです。
90年代のメール文字化けは社会問題級
Windows・Mac・UNIXがそれぞれShift-JIS／MacJapanese／EUC-JPを使い、メールはISO-2022-JPを推奨されていた1990年代、メール文字化けは深刻な社会問題でした。「半角カナを使うな」「機種依存文字を使うな」が当時のネチケットの最重要項目で、それ自体がネット文化を形成する一因となりました。
携帯キャリア間の絵文字文字化け
絵文字がUnicodeに統合される2010年以前、日本のドコモ・au・ソフトバンクはそれぞれ独自の絵文字コードを持っており、キャリアをまたぐと絵文字が文字化けしました。今の絵文字Unicode統一は、この時代の混乱が背景にあります。
Unicode制定の歴史
Unicode 1.0が1991年に公開され、当初は16ビット（65,536文字）で世界の全文字を表現するつもりでした。しかし漢字だけで足りないことが判明し、現在は1,114,112コードポイント（U+0000〜U+10FFFF）を扱う規格に拡張。文字化けの「サロゲートペア化」問題は、この拡張の副作用です。
まとめ
文字化けのパターンを10分類・31種で網羅し、文字コードの基礎・直し方・豆知識まで一括で解説しました。日本語圏で最頻出のUTF-8↔Shift-JIS系から、英語圏のLatin-1／Windows-1252系、置換文字「�」、豆腐「□」、HTMLエンティティやURLエンコードの未解決まで、化けて見える理由はすべて「保存時のエンコードと読み出し時のデコードが一致していない」というシンプルな原因に集約されます。直し方は原因の特定が9割で、エディタでの再オープン・変換コマンド・サーバー設定（.htaccess の AddCharset）・データベースのutf8mb4・Unicode正規化（NFC/NFD）まで、状況別の処方箋を用意しています。文字化けは過去の現象に見えて、絵文字やサロゲートペアの問題として現代でも形を変えて起き続けています。漢字・文字シリーズの動物を表す漢字157選・2ちゃんねる用語・ネットスラング102選もあわせてご覧ください。
