CSVの文字化けを直すには？Excelで原本・文字コード・値を確かめる

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

CSVの文字化けは、未変更の原本を残し、Excelの取込画面で文字コードと区切りを合わせるところから調べます。まだ保存していないなら、崩れた表示を上書きせず閉じ、コピーを読み直してください。すでに文字が「?」などへ置き換わって保存されている場合は、設定の切替だけでは元に戻らず、原本や書き出し元への確認が必要です。

急いで確認するなら、空のExcelブックから「データ」タブの「テキストまたはCSVから」へ進みます。文字コードを生成元の指定に合わせ、日本語と列の区切りをプレビューで確認し、番号の列はテキスト型で取り込みます。読み方を合わせても原文と違う、元の文字が分からない、列数がそろわない場合は、追加の保存を止めましょう。

この記事では、架空の受注補助データを使った12個の診断例を紹介します。正解の文字、番号、数量、区切りを本文にも載せているので、教材ファイルやプログラムを用意しなくても判断の理由を追えます。「読めるようになった」と「元の情報が残っている」を、具体的な違いから確認していきましょう。

確認範囲：2026年10月7日に公式資料を確認しました。主な操作経路はWindowsデスクトップ版Excelです。教材のバイト列・文字・列数・計算結果はプログラムで検算していますが、Excel実機で12例を操作した結果ではありません。メニュー名や自動変換の動作は、利用する版・設定で確認してください。

CSVが文字化けしたら、保存する前に原本と症状を確かめる

説明用の図。Excelの実操作画面ではありません。

開く・読む・保存するを別の操作として扱う

受け取ったCSVは、文字を記録したバイト列です。Excelなどのソフトは、そのバイト列を文字コードの規則で読み、さらに区切り記号から表を作ります。表示が崩れた時点で、ファイル自体の文字が消えているとは限りません。読取条件が合わないだけなら、同じ原本を正しい条件で読み直せます。

一方、崩れた文字のまま保存すると、その表示をもとに別の内容が書き込まれることがあります。「開いたら変だったので、とりあえずUTF-8で保存した」という操作は、原因の確認を一つ飛ばしています。まず正しい文字として読み、その後に必要な形式へ書き出すという順番を守ります。

1. 受信・ダウンロード直後のファイルを、未変更の原本として別に保管する。
2. 原本を複製し、取込や編集には作業用コピーを使う。
3. すでに上書きした場合は、それ以上書き換えず、未変更の添付ファイルや再ダウンロード元が残っているか調べる。
4. どのファイルを、どの条件で読んだかを短く記録する。

同じ名前のファイルでも、中身が同じとは限りません。更新時刻は手掛かりですが、移動やコピーでも変わる場合があります。本記事の教材は保管したバイト列まで照合しています。普段の作業でハッシュ計算を必須にする必要はありませんが、「原本だと思っていたものが、修正後の上書き版だった」という取り違えは避けたいところです。

日本語・列・番号のどこが変わったかを見る

CSVのトラブルは、すべて文字コードの問題とは限りません。品名は読めるのに整理番号だけ短くなる、一行が一つのセルに入る、といった症状は別の設定を調べます。最初に下の表で、手元の症状に近いものを選んでください。

表は横にスクロールできます。

二つの症状が同時に起きることもあります。文字コードを合わせて品名が戻っても、すでに番号が数値に変わっていれば検査は終わりません。反対に、数量の合計が正しくても、備考の一部が欠けている可能性は残ります。見た目の改善を一つ確認するたびに、次の確認項目へ進む考え方です。

生成元の指定と、正しい値の基準を用意する

受取メールや出力画面の説明で、文字コード、BOMの有無、区切り記号、見出し行の有無、番号の桁数を探します。「CSV形式」という説明だけでは、これらを確定できません。特定サービスのCSV仕様を、別のサービスのファイルへそのまま当てはめるのも避けましょう。

本記事の基本データは8列、データ6件です。品名は「ポストカード」「封筒」「台紙」「ケース」「ラベル」「メモ」。数量は順に2、3、1、4、0、2です。このような正解が一つでもあると、読めた文字が正しいかを確かめやすくなります。実務では元画面、出力仕様、担当者が確認した数件を照合の基準にします。

もし一部だけが崩れ、生成元の指定でも説明がつかないなら、別形式のデータが混ざっていないか確認が必要です。全部の文字コードを順番に選び、たまたま読めた表示を採用する方法では、正しい原文まで証明できません。取引先名や顧客情報を含むファイルを、原因不明のまま外部の変換サイトへ送ることも避け、まず生成元へ仕様と再出力の可否を問い合わせます。

Excelの取込で文字コードを指定し、UTF-8とCP932を読み分ける

説明用の図。Excelの実操作画面ではありません。

空のブックからコピーを取り込み、プレビューを確認する

ファイルをダブルクリックした結果だけで判断せず、Excel側から取込条件を選びます。Windowsデスクトップ版では、新しいブックの「データ」タブにある「テキストまたはCSVから」が基本の入口です。版によっては「データの取得」「ファイルから」などを経由します。

選ぶのは、先ほど分けた作業用コピーです。プレビューが出たら、最初に日本語の品名、次に見出しと列の区切りを確認します。生成元がUTF-8ならUTF-8を指定し、CP932ならコードページ932に対応する指定を使います。財務省のCSVの取込案内では、65001と932の表示例、データの変換、テキスト型の選択が示されています。

ここでは01をUTF-8、03をCP932として読みます。どちらも品名の先頭が「ポストカード」で、続く行が「封筒」になれば、教材の文字の基準と一致します。ただし冒頭の二行だけで完了せず、残りの品名、備考の記号、最後の行も確認します。先頭が英数字だけのファイルでは、誤った指定でも違いが表れにくいためです。

列型まで確認するため、プレビューから「データの変換」へ進みます。まだこの段階では、番号が数値に変わっていないかを見る必要があります。単に「読み込み」を押して表が表示されたという事実と、文字・列・値の確認が済んだことを分けてください。原本を書き直さずに取込条件を変えられる点が、この経路を使う利点です。

01・02・03は2文字コード、3保存条件の比較

最初の三つは同じ表を記録した対照ファイルです。01と02はどちらもUTF-8で、02だけ先頭にBOMを付けています。03がCP932です。BOMを三つ目の文字コードとして数えません。

表は横にスクロールできます。

02は01の先頭にEF BB BFという3バイトを加えたものです。BOMは読取側がUTF-8と識別する手掛かりになり、MicrosoftもBOM付きUTF-8のCSVを通常の方法で開く説明をしています。ただし、BOMは「整理番号を文字列にする」「備考のカンマを正しく区切る」といった指定を含みません。

CP932のファイルへUTF-8のBOMだけを付けても、本文のバイト列はUTF-8に変換されません。またUTF-8のBOMは、UTF-8内部のバイト順を切り替えるものではありません。この点はUnicodeのBOM解説でも整理されています。BOMの有無を直す作業と、文字そのものを別の符号化へ変換する作業は分けます。

同じ表でも保存物の大きさは違い、04と05のように大きさが同じでも区切りは違います。ファイルサイズだけで文字コードや内容の一致を判定することはできません。確認するのは「指定に合う読み方で、期待する表になるか」です。

英数字だけの06では、文字コードを一つに決められない

06_ascii_ambiguous.csvの中身は、見出しが「id,code,count」、データが「A01,00123,2」の2行だけです。ここで使っているASCIIの英数字と記号は、UTF-8でもCP932でも同じ文字として読めます。教材では、UTF-8として読んでCP932で保存しても、元と同じ28バイトになることを確認しました。

この例でUTF-8を選んで読めたとしても、「生成元は必ずUTF-8だった」とは言えません。CP932でも同じ結果だからです。自動判定の結果も、生成元の指定に優先する証拠とは扱わないでください。日本語を含まない部分しか確認していない段階では、文字コードの候補を十分に絞れない場合があります。

CP932はWindows-31Jとも呼ばれ、Shift_JISと関連する形式ですが、完全に同じものとして扱うと対応文字の違いを見落とします。画面が「932：日本語（シフトJIS）」と表示する場合は、そのコード番号と生成元の仕様を対応付けます。「ANSI」とだけ書かれた説明も、常に一つの日本語文字コードを意味すると決め付けず、出力環境を確認しましょう。

Macやメニューの異なる版では、対応する公式手順を見る

Macなどで入口が見つからないときは、Windowsの画面名を無理に探し続けず、MicrosoftのCSV・テキストファイルの取込案内から利用環境に合う説明を確認します。版を記録しておくと、相談相手も同じ機能があるか判断しやすくなります。OS全体の地域設定を変更する前に、対象ファイルの取込条件で解決できる範囲を調べてください。

文字コードを変える前に、消えた文字が戻る状態か確認する

説明用の図。Excelの実操作画面ではありません。

読み違いなら原本を読み直し、保存済みの欠落なら元へ戻る

文字コード変換は、「元のバイト列から正しい文字を読む」「その文字を別の文字コードで書く」という二段階です。03をCP932として正しく読めば、01と同じ品名・番号・備考になります。その文字をUTF-8で出力することはできますが、最初に読んだ文字が間違っていれば、UTF-8に保存しても誤った文字を記録するだけです。

ここで知っておきたいのは、変換先の文字コードで表せない文字があることです。読取側の選択を直せば済む問題と、保存で文字を別の記号へ置き換えた問題は、戻り方が違います。ファイルを閉じて開き直すことを何度繰り返しても、置換後の記号に元の文字の情報が必ず残っているわけではありません。

次の07と08は、その違いを意図的に作った教材です。通常業務で試す変換手順として勧めるものではなく、失われた情報を判断するための対照例として読んでください。

07の「ラベル🌱」を08の「ラベル?」と比べる

07_extended_utf8.csvは、基本データのR005の品名だけを「ラベル」から「ラベル🌱」に変えたUTF-8ファイルです。他の47個のデータセルと8個の見出しは基本データと同じです。この文字列をCP932へ厳密に変換する教材の検算では、🌱を表せず、そこで失敗しました。

08_lossy_cp932_question.csvは、07をCP932へ保存する際に、表せない文字を「?」へ置き換えた不良例です。R005の品名は「ラベル?」になりました。07と08をそれぞれ正しい文字コードで読むと、異なるのはこの1セルです。数量0や単価50など、周囲の値は変わっていません。

表は横にスクロールできます。

08を正しく読み、その文字をUTF-8へ保存し直しても、品名は「ラベル?」のままでした。変換先をUTF-8へ戻すことは、🌱を復元する処理にはなりません。別の表せない絵文字を同じ方法で置き換えても「?」になり得るので、08だけから元の一文字を一意に特定できないからです。

本記事で🌱が消えたと分かるのは、比較用の07が残っているためです。実務で元が残っていない場合に、「ラベルだから植物の絵文字だったはず」と補うのは推測です。生成元の画面や未変更原本で確かめられるまでは、元どおり直ったと報告しないでください。

また、R006の「確認?」は最初から正しい値です。「?がある行を削除する」「?を全部空欄にする」という処理は、正常な備考まで壊します。記号の有無だけで不良を決めず、どの行のどの列が原文と違うのかを調べる必要があります。

この置換例は、Pythonの厳密変換と置換処理で作成・検算したものです。エンコード時の「?」とデコード時の置換文字の扱いはPythonの文字コード処理の公式説明に対応します。Excelで同じ警告や同じ保存結果が必ず出るという実機の証拠にはしていません。

09の読取エラーと、10の読める置換文字を区別する

09_invalid_utf8.csvは、見出し「id,name」、記録ID「A01」に続くnameの位置に、UTF-8として不正な1バイトFFを入れた短い例です。厳密なUTF-8読取りは失敗します。この教材には、FFが本来どの文字を意味したかという正解はありません。別の文字コードで表示できたとしても、それだけで本当の原文を確定したことにはなりません。

10_saved_replacement_utf8.csvは、その不正部分を「�」という置換文字にしてUTF-8で保存した例です。「�」自体はU+FFFDという有効な文字なので、10は厳密なUTF-8として読み取れます。読取りが成功したのに、元の不正バイトはそのまま残っていないという状態です。

09の保存物は16バイト、10は18バイトでした。不正な1バイトが、置換文字を表すUTF-8の3バイトへ変わったためです。ここでも、文字の見た目だけでなく、いつ保存が起きたかが重要になります。09を保存せずに確認しているなら元のバイトは残っていますが、10しかなければ、置換前の内容を10だけから確実に戻すことはできません。

「�」を消すと表面上は記号がなくなります。しかしnameが空欄になるだけで、正しい名前が復元されるわけではありません。エラーを出さない状態にすることを目的にせず、情報の出どころを確認しましょう。

追加変換を止める条件を決めておく

07のように正しい原本があるなら、それを使って受取側と両立する形式を相談できます。受取側がCP932必須で、元の文字にはCP932で表せないものがある場合は、許可なく文字を削らず、UTF-8にできるか、どの代替表記を正式に使うかを確認します。代替表記の合意は、元の文字を復元したこととは別の判断です。

• 置換後のファイルしかなく、元の文字を確認できない。
• 生成元の指定で読んでも、一部の文字が原文と一致しない。
• どの段階で上書きしたか不明で、手元の原本の状態を確定できない。
• 出力先の文字コードでは必要な文字を保持できない。

これらに当てはまったら、再保存を重ねる前に生成元へ戻ります。必要なのは、未変更の再出力、出力仕様の確認、または受取条件の変更です。分からない文字を見た目で補い、件数や合計が合うから納品する、という終わらせ方は避けてください。

日本語が読めたら、先頭ゼロ・長い番号・日付風コードを守る

説明用の図。Excelの実操作画面ではありません。

計算する値と、文字として保つ番号を分ける

日本語が正しく読めても、数字の見た目をした文字列が変わることがあります。今回の整理番号は商品の計算には使わず、記録を照合するための5桁の文字列です。「00123」と「123」を同じものとして渡すことはできません。連携番号も16桁全部が識別に必要なので、数値ではなく文字列で保持します。

区分コードの「3-4」「1E10」「4/5」も、その文字列が正解です。日付や指数の形に似ているからといって、日付・数値へ変換する理由にはなりません。数量と単価だけは、この教材では整数として計算します。実ファイルに小数や通貨の指定があれば、生成元の仕様に合わせて判断してください。

表は横にスクロールできます。

R004の備考は空欄ですが、R005の数量は明示的な0です。前者を0で埋めたり、後者を「何もない行」として削ったりすると、元のデータとは違うものになります。文字列を守る作業には、書かれていない場所を勝手に補わないことも含まれます。

自動の型変換より前に戻り、元の値へテキスト型を適用する

Power Queryでは、自動で型が付く場合があります。プレビューや変換画面で整理番号が123になっていたら、その結果へ後からテキスト型を足すだけでは不十分です。まず適用済みの手順を見て、数値化する前の元の文字が残る段階へ戻れるか確認します。

番号の列をテキストへ変更する際、現在の型変換を置き換える選択肢が出る場合は、追加の数値化を残さない形で扱います。重要なのはボタン名の暗記より、「00123を読む段階からテキストとして扱う」ことです。すでに123という値だけを読み込んだファイルなら、型を変更しても失われたゼロは再現できません。

確認は、整理番号を順に00123、00007、01200、10000、00000、00001と照合します。連携番号は先頭が同じなので、末尾だけ見て済ませず、全桁が元の行と対応するかも見ます。R001の番号をR002へ誤って貼り付けても、文字列としての桁数は合うためです。

この区別は、元のCSVに値が残っているのか、Excelへの取込時に変わったのかを切り分ける助けになります。元のコピーには00123があるのに表では123なら、取込の型指定からやり直します。受け取ったファイル自体が123しか持たないなら、送信前のデータを確認してもらう必要があります。

表示のゼロ埋めや列幅の調整を、復元と取り違えない

数値123に5桁の表示形式を当てれば、画面上で00123と見せられる場合があります。ただし、元が5桁だったという情報は123自体にはありません。元が00123だったのか000123だったのかは、別の仕様がなければ決められません。既知の5桁ルールに沿った整形と、原文の復元は分けて説明します。

長い番号が指数表示されている場合も、表示だけの問題なのか、数値として扱われた時点で精度を失ったのかを分けます。Excelの数値精度は15桁なので、16桁以上の識別番号は取込時からテキストにする必要があります。列幅を広げたり、表示形式を変えたりするだけで、失われた末尾を復元できるとは限りません。詳細はMicrosoftの先頭ゼロと大きい数値の保持で確認できます。

今回の16桁の番号は、R001から順に1234567890123456〜1234567890123461です。数値に変換された結果を予想で書き換えず、本文の正解表や原本の番号へ戻ります。複数の番号が同じ値に変わると、件数も合計も変わらないまま、別の記録を区別できなくなる可能性があるためです。

自動データ変換の設定は、対応版を確かめて使う

Microsoft 365とExcel 2024のWindows・Mac版には、自動データ変換を調整する機能があります。ただし、この設定がすべての旧版にあるとは限りません。設定の有無にかかわらず、今回のファイルについて、文字列の列が元の値で取り込まれているかを確かめることが必要です。

普段の既定設定を変更する場合は、他の作業への影響も考えます。一つのCSVのために全部のデータを文字列へ変え、その後の計算で別の問題を作るより、番号列と数量列を仕様に沿って選び分けるほうが、何を守ったのかを説明しやすくなります。

列ずれと行数の違いは、区切り・引用符・セル内改行で調べる

説明用の図。Excelの実操作画面ではありません。

一列に入る04・05は、区切りを合わせて確かめる

04_core_semicolon.csvはセミコロン、05_core_tab.tsvはタブを区切りにしたファイルです。正しい文字コードと区切りで読めば、01と同じ6件8列になります。カンマだけを区切りとして選んでいると、この構造を正しく取り出せません。日本語の見出しが読めているのに列が分かれない場合は、文字コードより区切りの指定を先に確認します。

この教材全体で扱う区切りは、カンマ・セミコロン・タブの3種類です。セミコロンとタブは、基本のカンマに追加した二つの例です。拡張子が.csvであることだけを根拠に、必ずカンマ区切りだと判断しないでください。仕様が分かる場合は、それに合わせた結果が8列になるかを確認します。

なお、この8列という正解は基本データ01〜05についてのものです。後で扱う06や09〜12は、別の短い反例なので、無理に8列へそろえません。対象ファイルに対応する見出しと期待する列数を持つことが大切です。

備考のカンマと引用符を、列の境界と区別する

R001の備考は「青,小」という1セルです。カンマ区切りの01では、この値を二重引用符で囲んだ「"青,小"」という形で記録します。値の中のカンマを、そのまま列の区切りと読まないためです。画面に取り込んだ正解は、引用符で囲む記法を除いた「青,小」になります。

R002の備考は「定型 "白"」です。引用符を含む値を記録するため、CSV内では「"定型 ""白"""」のように値全体を囲み、内側の引用符を二つ重ねます。表示した備考には、白の前後に一つずつの引用符が残ります。外側の囲みと、値として残す引用符の役割を分けて見ます。

このため、テキスト全体をカンマだけで機械的に分けたり、引用符をすべて削ったりすると、備考が余計な列に分かれます。カンマ・引用符・改行を含むフィールドの扱いはRFC 4180のCSV記述でも説明されています。ただしこれはカンマ区切りの形式を扱うInformational RFCで、すべての.csvファイルやタブ区切りの挙動を一律に保証するものではありません。

物理8行でも、データは6件になる

R003の備考は「折れ注意」と「平らに保管」の間にセル内改行があります。CSVでは、この改行を含む備考全体が引用符で囲まれています。ファイルをテキストの物理行で数えると、その備考が二行分になるため、01〜05はヘッダーを含めて8行です。

しかし、記録の単位で見ると、R003は一つのデータです。ヘッダーが1件、R001〜R006が6件なので、論理レコードはヘッダー込み7件、データだけなら6件になります。「改行が7個あるからデータは7件」といった数え方では、セル内改行や末尾の改行を取り違えます。

Excelでは備考を折り返して表示すると確認しやすくなりますが、画面の折り返しと、値の中に実際に入っている改行も別です。列幅が狭いため二行に見えているだけなのか、原本に改行があるのかを分けてください。本例では、備考の二つの文が同じR003のセルに残ることが正解です。

11・12の不正な構造を、文字コード変更で修理しない

11_bad_unquoted_comma.csvの見出しは「記録ID,品名,備考」の3列です。データは「X001,カード,青,小」となっており、カンマで解析すると4列になります。備考が「青,小」の1セルである想定に対して、囲みの引用符が欠けています。日本語も読め、CSVの読取り処理が成功しても、見出しとデータの列数が合いません。

12_bad_unclosed_quote.csvは、同じ見出しの下で備考を始める引用符だけがあり、閉じていません。データ部分は「X001,カード,"青,小」の後で行が終わる形です。今回の厳密な解析では失敗しました。ただし、アプリによっては補完や別の解釈をする可能性があり、「開けたから正しい構造」とは言えません。

二つとも、UTF-8から別の文字コードへ変えることでは、意図した列の境界を決められません。教材では備考の正解が示されているので誤りを説明できますが、実データでどのカンマを値として残すのか不明なら、推測で引用符を足さず生成元へ戻します。修正が必要な行と、期待する列数を伝えるほうが、ファイル全体の一括置換より安全です。

一方、CSVファイルの取込ではなく、すでにセルに入った文字列を用途別に分けたい場合は、Excelで文字列を分割する方法を参照してください。外部ファイルの引用符規則を扱う場面と、セル内文字の加工を行う場面では、選ぶ手順が変わります。

直したCSVを再確認し、受け取る相手の条件に合わせて渡す

説明用の図。Excelの実操作画面ではありません。

正解表で、文字・列・件数・値を照合する

ここまで確認した内容を、基本データの正解表でまとめます。01〜05は、正しい文字コード・BOMの扱い・区切りで読むと、下の8列になります。表内の「空欄」は説明用の表記で、実ファイルにその二文字が入っているわけではありません。R003の備考の改行は、同じセル内の改行です。

8列の正解表は横にスクロールできます。右端の備考まで確認してください。

確認の順番は、まず見出し8列と記録ID6件、次に文字列の全セル、最後に数量と金額です。数量は2＋3＋1＋4＋0＋2＝12。各行の数量×単価は240、240、350、360、0、150で、合計は1,340になります。合計金額は検算用に計算したもので、元のCSVに9列目があるわけではありません。

ここで、数量0のR005を削ってみた場合を考えてください。数量合計12と金額合計1,340は変わりませんが、データは5件になり、ラベルの記録が消えます。同様に、整理番号の先頭ゼロが落ちても、金額合計は変わりません。合計・件数・文字列の照合は、それぞれ違う誤りを見つけるために必要です。

6件の教材なら、各行の8セルを最後まで比べられます。実務で件数が多い場合も、数件の目視だけを全件一致と報告せず、確認した範囲を明示します。受取側に必要な精度が分からないときは、納品条件として全件照合が必要かを確認しておきましょう。

作業用のExcelブックと、受け渡すCSVを分ける

取込設定や計算の途中経過を残したい場合は、作業用のExcelブックを別に保存します。受渡し用CSVには、相手が求める列だけを、指定された順番で出力します。検算用の合計列やメモ欄を追加したまま渡さないよう、元の8列と区別してください。

CSVはExcelブック全体を保存する形式ではありません。複数のシート、書式、すべてのExcel機能がそのまま残るとは考えず、書き出すシートを確認します。保存時の形式や保持されない機能については、Microsoftのテキストファイルのインポート・エクスポート案内を参照してください。

「Excelで見るためのファイル」と「システムに取り込むファイル」で、求められる条件が違うこともあります。相手の指定がUTF-8 BOMなしなら、BOM付きのほうが開きやすいという理由だけで変えません。文字コードだけでなく、区切り、改行、見出し、列順、空欄の扱いを確認し、Excelの保存メニューで指定できる範囲も利用環境で確かめます。

保存した出力を読み直し、SHAだけで合否を決めない

保存前のシートが正しく見えても、書き出したファイルが同じ内容とは限りません。受渡しCSVを別の取込として開き、指定の文字コードと区切りで読み直します。日本語、コード、空欄、引用符、セル内改行が残っていることを確認し、件数と数量・金額も再計算します。

原本を変更していないことの確認と、形式を変えた出力が正しいことの確認は、目的が違います。前者は保管したファイルと同一バイトかを調べ、後者は指定の読み方で得られる文字と値を比べます。文字コードを変換するとバイト列が変わる場合がありますが、必ず変わるわけではありません。

実際、01・02・03はそれぞれ保存バイトとSHA-256が異なる一方、正しく読んだ全セルは一致します。逆に06は、UTF-8で読みCP932で保存しても同じバイトです。同じ入力バイトから計算したSHAは同じになるので、06のSHAが一致しても元の文字コードを一つに決められません。

SHA-256はファイルの変化を調べる照合情報として役立ちますが、文字コード判定器でも、内容の意味が正しいことの保証でもありません。最初から欠落を含む08をそのまま複製すれば、複製同士のSHAは一致します。それでも07の絵文字が戻ったことにはなりません。「一致した対象は何か」まで含めて結果を読みます。

12例から、続けてよい確認と中断する場面を振り返る

最後に、各ファイルの役割を振り返ります。ここでいう成功・失敗は教材の読取りと照合の結果であり、Excelの画面表示や保存操作を実測した表ではありません。実務のファイルでは、対応する生成元の仕様と原文が必要です。

表は横にスクロールできます。

直らないときは、試した条件と戻りたい原本を具体的に伝える

生成元への問い合わせでは、「文字化けします」だけでなく、受信した版、保存前後の状態、試した文字コードと区切り、原文と違う列を伝えます。不要な実データは添付せず、必要なら架空値に置き換えた最小例を使います。ただし、置き換えによって症状が消える場合は、その例だけで原因を再現できたとはしません。

問い合わせ例：「受信したCSVの作業用コピーを、指定のCP932・カンマ区切りで取り込みました。品名の一部が?になっています。未変更の元ファイルは手元にありません。出力時に置換が起きていないか、元画面の該当品名と、UTF-8での再出力可否を確認いただけますか。」

原本が手元に残っているなら、その事実に合わせて文面を変えます。「こちらでは保存していない」「保存後のファイルしか残っていない」は、原因を調べるうえで違う情報です。分からない点は分からないまま伝え、変換済みのものを未変更原本と呼ばないことが、やり取りの手戻りを減らします。

単一ファイルを正しく読める状態になった後、毎月のCSVをまとめたい場合は、Excel Power Queryで月次CSVを結合する方法へ進めます。繰り返す確認をプログラムにしたい場合は、PythonでCSVを読み書きする方法が次の入口です。

CSVの文字化けを直すときは、まず原本から正しい文字を読み、その後に列と値を確かめます。保存で失われた文字は、読取設定を変えるだけでは戻らない場合があります。読めた見た目で終わらせず、原文と照合できる範囲を明らかにし、確認できない欠落は生成元へ戻してから受け渡しましょう。