文字化けテキストが復元可能か即座に見分ける方法

ユーザーが貼った日本語（または他の多バイト文字）テキストが文字化けしている時、闇雲に latin-1/utf-8 の変換を試したり、まして「たぶんこう書いてあったはず」と推測で埋めたりする前に、まず復元可能なmojibakeか、データが物理的に失われた不可逆な破損かを1回のチェックで判定する。

判定手順

s = "文字化けした文字列"
try:
    fixed = s.encode('latin-1').decode('utf-8')
    print("復元成功:", fixed)
except UnicodeDecodeError as e:
    print("単純なmojibakeではない:", e)

• 成功する場合: 典型的な「UTF-8のバイト列をLatin-1（ISO-8859-1）として誤読した」パターン。encode('latin-1')で元のUTF-8バイト列に戻し、decode('utf-8')で正しい文字列が復元できる。安全に機械的な復元を提案してよい。
• invalid continuation byte等で失敗する場合: 単純な文字コードの取り違えではない。多くの場合、UTF-8の継続バイト（2バイト目以降）のうち 0x80〜0x9F の範囲（C1制御文字域）に該当するバイトだけが失われている。これは、パイプラインのどこか（JSON文字列を\uXXXXエスケープから復元する際に誤ってdecode("unicode_escape")のような1バイト系コーデックを使った、あるいは「制御文字を除去する」サニタイズ処理を通した等）でバイトそのものが破棄された、不可逆なデータ損失であることが多い。

見分け方の直感: 3バイトUTF-8文字（例えば多くのCJK文字）の最初のバイトだけが生き残り、2〜3バイト目が消えている箇所が混在していれば、この「特定バイト域だけ欠落」パターンをまず疑う。

対応方針

1. 成功パターンなら、変換して復元した内容をそのまま使ってよい（機械的・可逆なので安全）。
2. 失敗パターンなら、推測で埋めて「復元しました」と報告しない。特に手順書・設定値・数値など正確性が重要な文書では、誤った内容を混入させるリスクが実害に直結する。
3. ユーザーには「バイトレベルでデータが欠けていて復元できない」ことと、具体的にどう壊れているかの例（1行だけ実際の変換結果を見せる）を伝え、別の取得経路（例: ブラウザで直接開いて全選択コピーする、別のエクスポート方法を試す）で貼り直してもらう。
4. 余裕があれば、元のエクスポート/取得スクリプトのどこで1バイト系コーデックによる誤ったデコードが起きていないか一緒に確認する（同じ原因が別の場所でも再発する可能性があるため）。

なぜこれが有効か

このチェックは1回のtry/exceptで「直せる／直せない」を確定的に判定できるため、後者のケースで無駄な試行錯誤（別のエンコーディングを何通りも試す、部分的に推測で埋める等）に時間を使わずに済む。特にAIエージェントが自動でテキスト復元を試みる場面では、「それらしく見えるが実は間違っている」復元結果を自信満々に提示してしまうリスクを避けられる。