文字化け (Mojibake)（モジバケ）
文字エンコーディングの解釈ずれで文字が誤表示される現象。「文字化け」は国際的にも "mojibake" として知られ、Shift_JIS/EUC-JP/UTF-8 等の混在で発生。1990-2010 年代の日本で頻繁に発生した代表的な情報技術トラブル。
概要
文字化け (mojibake、モジバケ) は、文字エンコーディングの解釈ずれで文字が誤表示される現象で、「文字化け」という日本語が国際的にも "mojibake" としてそのまま使われるほど日本固有の問題として知られています。Shift_JIS・EUC-JP・UTF-8・CP932 など複数のエンコーディングが共存していた 1990-2010 年代の日本で頻繁に発生した代表的な情報技術トラブルで、送信側と受信側で異なるエンコーディングを使うことで漢字が記号や全く異なる文字列に化けます。典型的なパターンとしては「縺翫＞縺励＞」(おいしいを UTF-8 として書いて Shift_JIS で読んだ)・「譁・ｭ怜喧縺」(文字化けを UTF-8 として書いて Shift_JIS で読んだ)・「ã" (絵文字を Latin-1 で読んだ) などがあり、これらの典型例から原因のエンコーディング組合せをある程度推測可能です。UTF-8 への移行が完了した現代 (2025 年以降) でも、レガシーシステム・古いメール・古い CSV・古い Excel ファイルとの連携で依然発生し続けています。
主な特徴・仕組み
- 発生原因: 送信側と受信側のエンコーディング解釈不一致
- 典型パターン 1 (UTF-8 → Shift_JIS): 「縺翫＞縺励＞」「譁・ｭ怜喧縺」
- 典型パターン 2 (Shift_JIS → UTF-8): 「\x82\xa0\x82\xa2」のような生バイト表示
- 典型パターン 3 (UTF-8 → Latin-1): 「é」「ã" のような西欧アクセント文字化
- 典型パターン 4 (EUC-JP → Shift_JIS): 罫線が全角記号に化け
- BOM 関連: BOM 付き UTF-8 ファイルを BOM 非対応ツールで開くと先頭に「」表示
- HTTP ヘッダ vs HTML meta タグ: HTTP
Content-Type: text/htmlと<meta charset>の不一致 - データベース文字コード: MySQL の
latin1設定で日本語データを保存して文字化け - 検出ツール: nkf -g (Linux)・file コマンド・chardet (Python)・Encoding Detector (VSCode)
- 修復ツール: iconv・nkf・Python の codecs モジュール
スペック比較表 (代表的な文字化けパターン)
| 原データ | 元エンコーディング | 誤解釈エンコーディング | 化け文字例 |
|---|---|---|---|
| おいしい | UTF-8 | Shift_JIS | 縺翫＞縺励＞ |
| 文字化け | UTF-8 | Shift_JIS | 譁・ｭ怜喧縺 |
| こんにちは | UTF-8 | Latin-1 | ã"ã‚"ã«ã¡ã" |
| ありがとう | Shift_JIS | UTF-8 | \x82\xa0... |
| 日本語 | EUC-JP | Shift_JIS | 罫線記号 |
具体例・対応技術
- メール文字化け (1990s): ISO-2022-JP/Shift_JIS の解釈ミス、Outlook・Becky! で頻発
- Web 文字化け (2000s): HTML の
<meta charset>不一致、PHP/MySQL の latin1 - Excel CSV 文字化け: Excel が CSV を Shift_JIS で開く、UTF-8 BOM 付加で解決
- Git 文字化け: Windows Git で日本語ファイル名、
core.quotepath=falseで改善 - 絵文字文字化け (2010s): 古いシステムが Unicode 補助文字 (絵文字) 非対応、サロゲートペアエラー
自作PCでの選び方・注意点
文字化けは 2026 年現在も完全には解決していない問題で、特に以下のケースで頻発します: (1) Windows 11 で UTF-8 ソースコードを CP932 デフォルト cmd.exe で実行→chcp 65001 で解決、(2) Excel CSV エクスポート→UTF-8 BOM 付き保存または PowerShell の Export-Csv -Encoding UTF8BOM、(3) MySQL の文字コード不一致→utf8mb4 統一、(4) WSL2 と Windows のファイル交換→ファイル別エンコーディング設定。予防策として、新規開発はすべて UTF-8 統一・BOM なし UTF-8 を原則・テキストエディタの自動判定機能を有効化・データベース文字コードを utf8mb4 で統一・HTTP ヘッダと HTML meta タグを一致させる、などの徹底が必要です。デバッグツールとしては Visual Studio Code の「Encoding 表示」機能や nkf -g file.txt (文字コード自動判定) が便利。
関連用語との違い
- エンコーディングミスマッチ: 文字化けの厳密な技術用語
- モジバケ: 日本語俗称、国際的にも mojibake として通用
- Tofu (☐): フォント不足で表示できない四角、文字化けとは別現象
よくある質問（FAQ）
Q1: 文字化けはどう修復する? A: 原データのエンコーディングを特定 (nkf -g)、適切なツールで変換 (iconv -f shift_jis -t utf-8)。完全自動化は難しい、人手判断が必要なケースが多い。
Q2: なぜ日本で頻発した? A: Shift_JIS/EUC-JP/CP932/ISO-2022-JP/UTF-8 と多数の日本語エンコーディングが共存していたため。英語圏は ASCII/Latin-1/UTF-8 程度で混乱が少なかった。
Q3: 完全に解決する方法は? A: 全システム UTF-8 統一・BOM なし統一・HTTP/HTML 一致が原則。レガシーシステム連携では iconv 等で都度変換、新規開発で混乱を持ち込まないことが重要。
まとめ
- 文字化け = エンコーディング解釈ずれによる文字誤表示
- 「縺翫＞縺励＞」「譁・ｭ怜喧縺」が典型パターン
- 国際的に mojibake として知られる日本固有の代表的トラブル
- UTF-8 統一で減少、レガシーシステムで現代も発生継続