結論：見た目だけで原因や復元できるかは決められない
4作例を比べると、元のバイト列を正しい文字コードで読めば「日本語」になる例と、読み方を選び直しても戻らない例がありました。同じような文字化けでも、元のファイルが残っている場合と、化けた文字を保存し直した場合は違います。
「�」や「?」があるという見た目だけでは、原因を一つに決められません。もともと入力された文字か、読めなかった部分が置き換わったものかも、表示だけからは確定できません。本稿では作り方が分かっている架空データで、この違いを確かめます。
CSV文字化け修正元ファイルの読み取り方とプレビューを見比べる登録なしで使えます開く
判定：元のファイルと、変換後のファイルを分ける
n=4の作例を現行のCSV文字化け修正の計算関数で読みました。2026年10月1日に、UTF-8・Shift_JISの指定と自動選択を比較しています。元ファイル2例の文章は「日本語」で、どちらにもBOMは付けていません。
| 作例 | 元データの作り方 | 自動選択の結果 | 表示 |
|---|---|---|---|
| A | 「日本語」をUTF-8で保存 | UTF-8 | 日本語 |
| B | 「日本語」をShift_JISで保存 | Shift_JIS | 日本語 |
| C | AをShift_JISとして誤読し、その文字をUTF-8で保存 | UTF-8 | 譌･譛ｬ隱� |
| D | 「確認😀」をShift_JISへ変換 | Shift_JIS | 確認? |
Aは9バイト、Bは6バイトでも、正しく読んだ文章は同じです。AをShift_JISと指定すると「譌･譛ｬ隱�」になりましたが、保存されている元の9バイトをUTF-8として読み直すと「日本語」になりました。
一方のCは、その化けた文字を新しく保存したものです。UTF-8として読めるデータになっていても、内容が元の文章に戻ったわけではありません。現行ツールのUTF-8・Shift_JISの指定では、Cから「日本語」には戻りませんでした。暗号のように見た目から元文を推測する機能ではありません。
一次資料：読めない部分を置換する処理がある
UnicodeのFAQは、不正なUTF-8に対する処理例として置換文字を挙げています。次は説明の一部です。
representing the byte with a marker such as U+FFFD REPLACEMENT CHARACTER
— Unicode「UTF-8, UTF-16, UTF-32 & BOM」FAQ https://www.unicode.org/faq/utf_bom.html（2026-10-01 到達）
文字を表すはずのデータを読めなかった場合に、U+FFFDという置換文字で示すことがある、という説明です。元の文字そのものが保存されるという意味ではありません。
WHATWGのEncoding Standardも、置換モードの出力を定めています。処理結果がエラーだったときのreplacement分岐は次のとおりです。
Push U+FFFD (�) to output .
— WHATWG「Encoding Standard」§4.1 Processing https://encoding.spec.whatwg.org/#concept-encoding-process（2026-10-01 到達）
厳密に読む設定では、置換せずエラーで止める扱いもあります。TextDecoderのdecode手順には、次の分岐があります。
Otherwise, if result is error , throw a TypeError .
— WHATWG「Encoding Standard」§7.2 TextDecoder https://encoding.spec.whatwg.org/#dom-textdecoder-decode（2026-10-01 到達）
これらは読み取りの処理を定める資料です。個別ファイルが壊れた原因や、元文を復元できるかを診断する表ではありません。
間違えやすい点：同じ「?」に変わると元の違いが消える
異なる絵文字2つを使った追加n=2の入力は、どちらも同じ5バイトになりました。現行ツールでShift_JISへ変換した結果です。
| 変換前 | 変換後の表示 | ツールが報告する置換数 |
|---|---|---|
| 確認😀 | 確認? | 1 |
| 確認😁 | 確認? | 1 |
出力は両方とも16進数で「8A 6D 94 46 3F」でした。この出力だけでは、元がどちらの絵文字だったかを区別できません。本来の「?」を入力した場合とも、出力の見た目だけでは区別できません。
| 取り違え | 今回の比較で分けられること |
|---|---|
| 自動でUTF-8と判定されたから内容も正しい | CはUTF-8でも化けた文字のまま |
| 別の文字コードを選べば必ず直る | 元の違いが置換で失われた出力もある |
| 見慣れた文字化けの形なら原因を断定できる | 今回分かるのは、作り方を管理した作例の経路だけ |
測っていないこと・ここから先は推論
実際のメール、Excel（エクセル）、Webページで起きた文字化けは測っていません。本稿の4作例の自動選択結果と、追加2入力の変換結果はPythonでも独立照合しました。ただし、Cをさらに誤ったShift_JISで読む出力は、PythonのCP932とブラウザ系の読み取りで末尾が一致しませんでした。全方式の出力が同じという検証にはしていません。
他の文字コード、フォントの欠け、壊れた通信、二重変換の全パターンは対象外です。現行ツールの自動選択もUTF-8として読めるかを使う推定であり、元文の正しさを確認する機能ではありません。Cの元ファイルが残っているかといった履歴も、出力からは判断していません。
次の１手：元のファイルのプレビューを比べる
次の1手は、CSV文字化け修正で元のファイルの読み取り方を変え、プレビューを比べることです。文字化けした文を保存したファイルと、保存前の元ファイルは区別して扱えます。置き換わった文字を自動で推測する処理ではありません。