UTF-8 vs Shift_JIS vs EUC-JP — どの日本語エンコーディングを選ぶべきか
CSV 書き出し・ファイル送付・レガシーシステム連携で「どのエンコーディングで保存すべきか」を、文字集合・バイト構造・現代の互換性で整理。文字化けが起きる組み合わせも。
何を見て選ぶか — 4 つの判断軸
日本語のテキストエンコーディング選びは「どれが新しいか」ではなく「相手の環境が何を期待しているか」で決まります。判断軸は 4 つです。文字集合のカバー範囲 は、JIS X 0208 までで足りるのか、Unicode 全体 (絵文字・繁体字・ハングル) が要るのかを決めます。バイト構造 は、ASCII 互換か、可変長か固定長か、というパース実装の難しさに直結します。相手側の互換性 は、Excel で開く CSV なのか、社内 Web なのか、メールヘッダなのかで突然厳しくなります。用途 は、新規開発なのか、レガシー連携なのかでデフォルト解が逆転します。
「UTF-8 が事実上の標準だから何でも UTF-8 にすればいい」という単純化は、Excel が UTF-8 (BOM なし) の CSV を開くと文字化けする現実の前ではすぐ崩れます。エンコーディングは送り手と受け手の合意で、合意を壊すと文字化け (mojibake) が起きるだけ — 良い悪いはありません。
4 つのエンコーディングを並べて見る
| 項目 | UTF-8 | Shift_JIS (CP932) | EUC-JP | ISO-2022-JP |
|---|---|---|---|---|
| 文字集合 | Unicode 全体 | JIS X 0208 + 半角カナ + NEC/IBM 拡張 | JIS X 0208 + 0212 | JIS X 0208 |
| 1 文字あたりバイト数 | 1-4 (可変) | 1-2 (可変) | 1-3 (可変) | 1-7 (escape 含む) |
| ASCII 互換 | あり (1 バイト目で判別可) | 部分的 (0x5C が円記号扱い) | あり | あり (escape で切替) |
| BOM | あり / なし両対応 | なし | なし | なし |
| 主な利用環境 | Web / 新規開発 / Linux / macOS | Windows 日本語版 / Excel CSV | 古い UNIX / 旧 Web | メールヘッダ・本文 |
| 規格 / 年 | RFC 3629 (2003) | MS CP932 / JIS X 0208 (1978) | EUC (1985) | RFC 1468 (1993) |
| Web 利用率 (2026) | 約 98% | 1% 未満 | 0.1% 未満 | メールのみ |
UTF-8 は ASCII (0x00-0x7F) をそのまま 1 バイトで表現し、日本語の漢字・かなは 3 バイトで表現します。Shift_JIS は ANK 部分を 1 バイト、漢字を 2 バイトで表現するため、同じ文章は UTF-8 より小さくなることもありますが、Windows 拡張 (NEC 特殊文字 / IBM 拡張漢字) を含む CP932 を厳密な Shift_JIS と区別せず扱うと「①」「髙」「﨑」あたりで化けます。EUC-JP は JIS X 0212 (補助漢字) まで含めると 3 バイトになる文字があり、扱いの難しさが嫌われて UTF-8 に押されました。
状況別の選び方
新規開発 / Web サイト / API / モバイルアプリ: UTF-8 (BOM なし) で固定。HTML の <meta charset="UTF-8">、HTTP の Content-Type: text/html; charset=utf-8、データベース (MySQL なら utf8mb4) を全段で揃えれば文字化けは起きません。BOM (EF BB BF) を付けるとシェルスクリプトや JSON パーサが先頭で詰まることがあるので、Web 系では基本付けません。
Excel で開く CSV を配布する場合: UTF-8 BOM 付き、または Shift_JIS。Excel for Windows は BOM なし UTF-8 の CSV を Shift_JIS と誤読して全角部分が「ﾆﾎﾝｺﾞ」のような化けを起こします。BOM を付けるか、思い切って Shift_JIS で書き出すのが安全。「Excel で開いてもらう前提なら BOM 付き UTF-8」は実務でよく使われる解です。
古い基幹システム・社内 Web (1990 年代設計) との連携: 相手の指定に従う。EUC-JP / Shift_JIS の指定が来たら、変換時に丸字や特殊記号 (Unicode にしかない文字) が「?」や「〓」に落ちるリスクを事前に伝える。
メール件名・本文の送信時: ISO-2022-JP がいまだに標準。エスケープシーケンス (ESC $ B 等) で 7-bit ASCII と JIS X 0208 を切り替える独特の構造です。MIME ヘッダで =?ISO-2022-JP?B?...?= のように Base64 でくるむのが慣例。
ブラウザ内で文字化け復元 / エンコーディング変換する
エンコーディングを間違えたまま保存したファイル・コピーした文字列の救出には mojibake-fix を使います。「繧ｴ繝｟ｱ」(UTF-8 が Shift_JIS と誤読された) や「ã®ã」(UTF-8 が Latin-1 と誤読された) のような典型パターンを試行錯誤で復元できます。CSV ファイル丸ごとを別エンコーディングに変換したいときは csv-encoding-convert を使えば、Shift_JIS の CSV を UTF-8 BOM 付きへ、あるいは逆方向へ、ブラウザ内で完結します。
ハマりやすいポイントは 3 つ。(1) BOM の有無: Shift_JIS には BOM の概念がないので、BOM 付き UTF-8 を Shift_JIS にそのまま変換すると先頭 3 バイトがゴミになる。(2) Shift_JIS と CP932 の混同: 「①」「㈱」「髙」を含むテキストを「Shift_JIS」と指定して保存しても、純粋な Shift_JIS には存在しない文字なので相手のパーサ次第で消える。Windows 由来なら CP932 (Microsoft の拡張版) を選ぶ。(3) Excel CSV の改行コード: エンコーディングが正しくても改行が LF だけだと古い Excel で 1 行扱いになるので CRLF を選ぶ。実装は GitHub で公開しており、DevTools の Network タブで「変換中にファイル本体がどこにも送信されていない」ことを目視確認できます。