エンコード変換・文字化け修復ツール

早わかり

文字化けとは

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

このツールでできること

実例で見る

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

（部分的にのみ復元可能）

使い方

1. 1

   文字化けしたテキストを貼り付ける

   そのまま貼るだけで、先にエンコードを特定する必要はありません。短い断片で十分——十数文字あればたいていチェーンは絞り込めます。

2. 2

   先頭の候補とバッジを読む

   完全一致は、同じチェーンを逆にたどると入力を一字一句再現できるという意味です。部分的なら再現できないので、結果は手がかり止まりと考えてください。

3. 3

   エンコードチェーンを確認する

   各候補には、原文が実際に書かれたエンコードと、それを誤読したエンコードが表示されます。文章の中身だけでなく、上流のどこを直すべきかがわかります。

4. 4

   必要ならバイト列を見る

   2 つ目のセクションは任意のテキストを主要エンコードすべてのバイト列で表示し、生の hex を逆方向にデコードもします。カラム長の見積もりやプロトコルのフレーム確認に使ってください。

かえって悪化させる操作

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# まず現在のエンコードを確認する
file -I correct.txt   # charset=utf-8 → 変換不要

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- 一度バイナリ型を経由してバイトを保持し、再解釈させない
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// バッジが何と言おうと先頭の候補を採る
db.update(row.id, candidates[0].text);

// 往復検証を通ったものだけ書き戻す
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# 境界で一度だけ、ファイルが実際に使っているエンコードでデコードする
with open(path, encoding='gbk') as f:
    text = f.read()

こんなときに使う

データベース移行のあとが全部文字化け

実体は UTF-8 のバイトなのに latin1 と宣言されたレガシー MySQL のテーブルが、単一の原因としては最も多い出どころです。ALTER TABLE を書く前に、化けた行を本ページに貼って実際のチェーンを確認してください——逆方向に変換してしまうと、復元できたはずの問題が永久的な破壊に変わります。

CSV を Excel で開いたら読めない

Windows 版 Excel は今も、BOM のない CSV をシステムのコードページで解釈します。そのため UTF-8 で書き出したファイルは文字化けして開きます。本ページでチェーンを確認したうえで、BOM 付きで書き出し直すか、テキストウィザードからエンコードを明示して取り込んでください。

レガシーなサービスが吐くログ

GBK や Shift_JIS に合わせて作られたアプリケーションは、ログもそのエンコードで書きます。一方、現代のログ収集基盤はすべてを UTF-8 として読みます。1 行貼れば復元できますし、何もアップロードされないので本番ログのままで作業できます。

ZIP のファイル名が壊れた

ZIP フォーマットにはエンコードを記録するフィールドがありません。そのため日本語や中国語の Windows で作られた書庫は、ファイル名を Shift_JIS や GBK のまま持ち、Unix 側のツールがそれを UTF-8 として読みます。リネームする前に、ここで本当のファイル名を復元してください。

データベースのカラム長を見積もる

バイトビューは同じテキストを全エンコードで一度に並べます。漢字 1 文字は UTF-8 で 3 バイト、GBK では 2 バイト——VARCHAR(50) が切り詰めバグに変わるのは、まさにこの手の差です。

文字化けはなぜ起きるのか

バイトは残る、意味は残らない

エンコードは文字をバイトに写し、デコードはバイトを文字に戻します。文字化けとは、間違った対応表で行われたデコードです。バイトが壊れたことは一度もありません。だから間違ったデコードを逆向きに実行すれば原文が正確に戻ります——その間違ったデコードが何も捨てていなければ、という条件つきですが。

なぜ日本語・中国語・韓国語が最も被害を受けるのか

ASCII は 0x00–0x7F を占め、主要なエンコードはこの範囲について完全に一致しています。だから英語のテキストは無傷で通り抜けます。日本語・中国語・韓国語は多バイト列を必要とし、各エンコードは区切り方について食い違います。UTF-8 は漢字 1 文字に 3 バイト、GBK は 2 バイト。UTF-8 のバイト列を GBK のデコーダに与えると区切りがずれ、文字数も中身も違う列ができあがります。

往復テスト

各候補チェーンについて、ツールは復元したテキストを 1 つ目のエンコードで再エンコードし、2 つ目のエンコードで再デコードします。それが入力を一字一句再現すれば、そのチェーンはすべての文字を説明できているということで、候補は完全一致になります。テストに落ちた候補も表示は残します。完全な再現に至らなくても、部分的な復元だけで原文が判別できることが多いからです。

エンコード表はどこから来るのか

デコード方向はブラウザの TextDecoder がそのまま供給します。逆方向は厄介で、TextEncoder は UTF-8 しかサポートしません——そこでツールはバイト空間を走査し、各バイト列が何を意味するのかをデコーダに問い合わせて逆引き表を組み立てます。おかげで対応関係は常にブラウザ自身の挙動と一致し、変換表を端末に配信する必要もありません。

並べ替えのヒューリスティックと、その限界

往復テストの外側では、候補はテキストのうち常用漢字（GBK の先頭バイトが 0xB0–0xF7 に入るもの）がどれだけを占めるかで採点され、置換文字・半角カタカナ・制御文字は減点されます。半角カタカナは Shift_JIS 誤読の強いシグナルです。通常の日本語テキストではほとんど使われないからです。これはヒューリスティックであり、同点を崩すことはできても真偽を確定するものではありません。

二度と起こさないために

文字列ではなく発生源を直す

各候補の下に示されるエンコードチェーンが、どのコンポーネントの設定が誤っているかを教えてくれます。接続の charset、ファイルリーダー、書き出し設定を直さずにテキストだけ直しても、明日また新しいデータで同じ作業をすることになります。

ファイル全体を変換する前に方向を確定させる

まず代表的な 1 行を本ページに通してください。 逆方向に変換すると置換文字が生まれます。最初の誤読と違って、そのステップは可逆ではありません。

どこでもエンコードを明示的に指定する

データベース接続の charset、HTTP の Content-Type、ファイルオープンの呼び出し、CSV の書き出し。「システムのエンコード」に任せている箇所はすべて、コードが別のマシンに移った瞬間に同じバグが再発する箇所です。

MySQL では utf8 ではなく utf8mb4 を使う

MySQL の utf8 は 1 文字あたり最大 3 バイトしか格納しないため、絵文字や一部の稀な漢字が黙って切り捨てられます。utf8mb4 が本物の UTF-8 です。これは文字化けとは別種の故障で、本ツールでは救えません——バイトが本当に失われているからです。

修正を検証し終えるまで元のバイトを残す

変換の前にコピーを取ってください。元のバイトが残っている限り、どんな誤ったデコードも可逆です——置換文字で上書きしてしまえば、本ページも、他のどんなツールも取り戻せません。

よくある質問