文字化け変換・復元

概要

文字化けは破損ではありません。正しいバイトを誤った表で読んだ状態です。日本語 を UTF-8 で符号化すると 9 バイトになり、その同じ 9 バイトを Windows-1252 として 読むと 日本語 になります。失われたものは何もなく、解釈が誤っていただけで、 逆をたどれば元が正確に戻ります。

このツールは、貼られたテキストを「誤読されたと思われる符号化」でバイトへ戻し、 そのバイトを「実際にはそうだったかもしれない符号化」で復号し、結果に順位を 付けます。最上位の候補は、置換文字なしで妥当な UTF-8 になったものです。

使い方

1. 文字化けしたテキストを貼ります。
2. 星の付いた最上位の候補を読みます。
3. それが正しくなければ他も確認します。各候補には生成した組み合わせが書いてあります。

最上位の候補が通常正しい理由

順位付けは言語についての推測ではありません。UTF-8 の構造的な性質を利用しています。 UTF-8 は自分の列の長さを自分で申告します。先頭バイトが後続バイトの数を述べ、 後続バイトはすべて後続バイトとして識別できます。したがって任意のバイト列は ほぼ即座に UTF-8 としての復号に失敗し、ブラウザの復号器はその失敗を置換文字として 報告します。

ある候補が置換文字なしで UTF-8 として復号できたなら、それは好みではなく強い 証拠です。バイトは最初から妥当な UTF-8 だったということで、それは何かが Latin-1 として読む前は UTF-8 だったテキストにまさに期待される性質です。候補はさらに、 文字化けの痕跡が残っているかで順位を付け、痕跡を減らす候補だけを提示します。

正しいテキストに手を出さない理由

候補を作る前に、入力に文字化けの痕跡があるかを検査します。Latin-1 の誤読が生む 特定のバイト対（à /  / †/ ã とその仲間）、U+0080〜U+009F の C1 制御文字、 そして U+FFFD 置換文字です。

これらが 1 つも無いテキストは「きれい」と報告し、候補を出しません。正しい テキストに適用したとき、この変換は破壊的だからです。Grüße と señor は 普通のドイツ語とスペイン語で、文字化けだと仮定した復元をかければ意味のない 文字列になります。常に候補を出すツールは、まさにその誤りを誘います。

復元できないもの

テキストに ? や �、空の四角が含まれている場合、元のバイトは失われています。

区別を正確に述べる価値があります。文字化けはバイトを保ち解釈を失うので可逆です。 置換はバイトを失います。変換器が変換先の符号化で表現できない文字に出会うと、 代替を書き込んで元を捨てます。どのツールもそれを復元しません。解釈し直す対象が 残っていないからです。元のファイルがまだ手に入るなら、それが唯一の道です。

二重の文字化け（文字化けし、保存し、また文字化けした）は復元を 2 回適用すれば 戻ることもありますが、各回で損失が積み重なるので結果は劣化します。

文字化けの発生源

型はほぼ必ず「宣言されなかった既定値」です。

• 表計算ソフトで開いた CSV。 Windows の Excel は歴史的に、UTF-8 の BOM が 無い .csv をシステムのコードページと仮定していました。アクセントに満ちた 書き出しファイルが文字化けして開くのはこれが理由です。例として café は café になります。
• 文字セットを指定しなかったデータベース接続。 データは正しく格納されており、 接続が誤って変換します。そのため同じ行が、あるクライアントでは読めて別の クライアントでは文字化けします。
• メールの件名。 ヘッダーは ASCII のみなので、非 ASCII は自分の文字セットを 申告する RFC 2047 の encoded-word として運ばれます。日本語の件名は今も ISO-2022-JP が日常的に使われ、UTF-8 と決めつける復号器はそのすべてを文字化けさせます。
• Content-Type に charset が無い応答。 ブラウザが推測し、その推測はロケールに 依存します。
• 書庫の中の古いファイル名。 ZIP には信頼できる文字セットの欄が無いので、 あるコードページで作られたファイル名が別のコードページで読まれます。

使用例

• 取り込んだ CSV の修復 — 影響を受けた項目を 1 つ貼って組み合わせを特定し、 行を 1 つずつ直すのではなく正しい符号化で取り込み直します。
• 文字化けしたメール件名を読む — メッセージ全体なら .eml ビューアがヘッダーの申告する文字セットで encoded-word を 復号します。ISO-2022-JP も含むので、復元なしで件名が正しく読めます。
• 経路の切り分け — 修復を生んだ組み合わせが、どこで変換が誤っているかを示します。 「UTF-8 として書かれ、Windows-1252 として読まれた」なら、読み手側で文字セットの 宣言が欠けているということで、データ側の問題ではありません。
• ログの確認 — ある符号化で出力するサービスと別の符号化で読む集約基盤の 組み合わせは、非 ASCII の行だけを文字化けさせます。だから翻訳されたシステムの 人名やエラーメッセージが現れるまで気づかれません。

注意事項

候補はブラウザ自身の TextDecoder で復号するので、表はプラットフォームが使う ものです。このプージは符号化の表を一切同梱していません。旧来のマルチバイト 符号化への対応は Encoding Standard が要求しており、現行のすべてのブラウザに あります。

対応する符号化は、誤読側が windows-1252・iso-8859-1・windows-1251・ macintosh、元の側が utf-8・shift_jis・euc-jp・iso-2022-jp・gbk・ big5・euc-kr です。候補は最大 8 件表示します。

候補は使う前に必ず読んでください。短い断片では複数の組み合わせがもっともらしい 出力を生み得ますし、構造の検査はテキストがどの言語であるべきかを教えてくれません。 すべてブラウザ内で完結します。詳細はプライバシープリシーに 書いてあります。