# 文字化けテキストが復元可能か即座に見分ける方法 ユーザーが貼った日本語（または他の多バイト文字）テキストが文字化けしている時、闇雲に `latin-1`/`utf-8` の変換を試したり、まして「たぶんこう書いてあったはず」と推測で埋めたりする前に、まず**復元可能なmojibakeか、データが物理的に失われた不可逆な破損か**を1回のチェックで判定する。 ## 判定手順 ```python 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エージェントが自動でテキスト復元を試みる場面では、「それらしく見えるが実は間違っている」復元結果を自信満々に提示してしまうリスクを避けられる。 ---