CSVが文字化けしたとき、「CSV形式が壊れている」と考えがちですが、CSVの構造と文字コードは別の問題です。同じ id,name というCSVでも、UTF-8、UTF-8 BOM付き、Shift_JISではバイト列が違います。
実務では文字コードの歴史を全部覚える必要はありません。重要なのは、受け渡し先が何を期待しているか、Excelでどう開くか、変換するときに値を変えないかです。
CSVと文字コードは別物
CSVは、フィールドを区切り文字で並べるデータ形式です。文字コードは、その文字をファイルのバイト列へどう対応させるかという別の仕組みです。
そのため、列数も引用符も正しいCSVなのに、日本語だけ文字化けすることがあります。逆に、文字コードが正しくても引用符が壊れていれば列はずれます。
UTF-8とShift_JISは何が違うか
現在はUTF-8を扱えるシステムが多い一方、日本の古い業務ソフトや一部の受け渡し仕様ではShift_JIS系の文字コードが指定されることがあります。
ここで「UTF-8のほうが新しいから全部UTF-8にする」と決めると、相手側の取込仕様で失敗する可能性があります。出力形式は、作成側の好みではなく受け手の仕様で決めます。
BOMとは何か
UTF-8の先頭に付くことがある3バイトの印がUTF-8 BOMです。Microsoftは、UTF-8 CSVがBOM付きで保存されている場合はExcelで通常どおり開けると案内しています。BOMなしの場合は、Power Queryなどの取り込み機能を使う方法が案内されています。
つまり「UTF-8」と「UTF-8 BOM付き」は、見た目のCSV内容が同じでも、Excelでの開き方に差が出る場合があります。
Excelで開くならダブルクリックだけに頼らない
文字化けしたCSVをダブルクリックで開き、そのまま保存し直すのは危険です。データ取り込みを使えば、プレビューしながらファイルの解釈を確認できます。
特にコード、郵便番号、会員番号などは、文字コード問題を直す過程で数値化されると先頭ゼロが失われます。文字が読めたかだけでなく、値が保持されているかまで確認します。
どれを選べばよいか
判断は単純です。
- 受け渡し先が文字コードを指定 → その仕様に合わせる
- Excel中心でUTF-8 CSVを渡す → BOM付きUTF-8が扱いやすい場合がある
- Web/API/新しいシステム → UTF-8が一般的だが、最終的には仕様確認
- 古い国内システム → Shift_JIS系指定が残っていることがある
自動判定ツールを使う場合も「100%判定できる」と考えないほうが安全です。ASCII文字だけの短いファイルなど、複数の文字コードとして矛盾なく読めるデータもあります。
文字コード変換で守るもの
文字コードを変える目的は文字の表現方法を変えることで、データの意味を変えることではありません。
00123 を 123 にする必要はありません。17桁の識別子を数値へ変換する必要もありません。日付の書式をExcel風に直す必要もありません。
変換前後で、レコード数・列数・文字列値が保持されていることを確認して初めて、安全な変換と言えます。
参考一次資料
- Microsoft Support: Excel で CSV UTF-8 ファイルを正しく開くには
https://support.microsoft.com/ja-jp/excel/opening-csv-utf-8-files-correctly-in-excel - Microsoft Support: Text Import Wizard
https://support.microsoft.com/en-us/excel/text-import-wizard
