01
ファイルが残っていれば先に開く
ファイルとHexでは実際のバイトを保持し、UTF-8の不正位置をゼロ起点で示します。文字列の貼り付けから元ファイルのバイト位置は計算できません。
Unicodeと国際化
文字化け修復誤読された経路をたどる
元データを残したまま、読み方ごとの候補を比較します。
文字化け修復
文字化けした文または元バイト
修復候補
文章、Hex、ファイルを入力してください。
文章とファイルのバイトはこのブラウザー内だけで処理し、送信しません。
入力か設定が変わりました。再診断を待っています。
候補は推測です。往復できても元の文章だとは限りません。
文字化け修復が必要になるのは、昔の文書を開いたら人名や地名が「café」のように崩れたときです。まず正しい表記を知っている短い箇所を探し、候補と照らしてください。
元ファイルがあれば、そのバイトを直接読み込むほうが確実です。貼り付けた文字列だけの文字化け復元では、すでに置換されたバイトを取り戻せません。
文字化け修復で何を確かめられる？
推測した結果と、変更していない元の証拠を分けて表示します。
元バイトを残して読み比べる
文字化け修復はファイルまたはHexのバイト列を保持し、UTF-8やShift_JISなどで読んだ候補を別々に示します。候補を切り替えても入力は変わりません。
誤読の向きを明示する
貼り付けた文字は、誤って読まれた文字コードでいったんバイトに戻し、本来のコードで読み直します。どちらを仮定したか表示するので、偶然読めた結果と区別できます。
元ファイルの有無で入口を選ぶ
02
手動指定は過去の順序で考える
「元の書き込み」は最初の文字コード、「誤って読んだ」は後から使われたコードです。文字コード変換の出力先を指定する欄ではありません。
03
候補を文脈で照合する
自動診断は短い待機後に更新され、変更中の古い結果はコピーできません。名前、句読点、固有名詞を確認してから保存してください。
壊れ方を追うための三つの手掛かり
不正なUTF-8バイトの位置
元バイトがある場合、先頭バイト、継続バイト、途中で切れた列を厳密に調べます。UTF-8文字化けの原因を、文字の見た目だけで推測しません。
東アジアと欧文の候補
Shift_JIS文字化けを含む日本語の誤読、欧文のWindows-1252、韓国語や中国語の候補を比較します。どれも正解と断定せず、経路を表示します。
原本と結果を別々に保存
選んだ候補はUTF-8の新しいテキストとして保存します。ファイルの元バイトも別に保存でき、誤った候補を選んでも原本は書き換わりません。
修復候補を読む前の注意
- 可逆性は正しさの証明ではない
- 往復できる文字コードの組でも、歴史的に使われた組とは限りません。短い文字列は複数の候補が自然に見えることがあります。
- 置換済みの文字は元に戻せない
- 別のソフトが�や?に置き換えた時点で元バイトが消えた可能性があります。貼り付け文字だけから完全な復元を約束しません。
- バイト位置は元データが必要
- UTF-8の不正位置はファイルまたはHex入力にのみ示します。ブラウザーが受け取ったUnicode文字列から過去の不正バイト位置は分かりません。
- 旧文字コードへの書き出しはしない
- 元ファイルへの上書きやShift_JISなどへの再保存は行いません。候補は新しいUTF-8ファイルとして出力し、元バイトは別に残します。
文字化け修復についてよくある質問
文字コードの自動判定は必ず当たりますか？
いいえ。候補の並びは読みやすさと指定したコードを手掛かりにしています。短い文字ほど曖昧なので、固有名詞などで確認してください。
すべての文字化けを直せますか？
直せません。別のソフトが元バイトを�や?に置き換えた場合、その値は貼り付け文字に残っていません。元ファイルを探してください。
候補が複数出るのはなぜですか？
同じバイト列を複数の文字コードで読めるためです。可逆な候補がいくつあっても、正しい文脈を持つ候補を選ぶ必要があります。
どれが正しい復元結果かわかりません。
知っている人名、商品名、句読点を含む箇所で比較してください。判断できなければ結果を上書きせず、元バイトを保管しておいてください。
「UTF-8→Shift_JIS」のようなパターンとは何ですか？
元はUTF-8のバイトだったのにShift_JISとして読まれた、という過去の誤読経路です。手動欄では「元の書き込み」と「誤って読んだ」を分けます。
判断しにくい例がありますか？