CSV文字化けはどこで起きる？Excel・文字コード・改行の確認ポイント

CSVを開いたとき、名前や住所が読めない形で表示されることがあります。 最初に疑いたくなるのは、出力されたファイルそのものです。

ただ、CSVの文字化けは、ファイルだけで起きるとは限りません。 Excelでの開き方、文字コード、BOM、改行コード、区切り文字の判定がずれるだけでも、同じように崩れて見えます。

同じCSVでも、取込先システムでは正常に読めるのに、Excelでは崩れることがあります。 反対に、Excelではきれいに見えても、相手先システムでは読み込めないことがあります。

この記事では、CSVが崩れて見えたときに、文字コード、Excelでの開き方、改行コード、区切り文字をどう切り分けるかを整理します。 CSV文字化けは、変換する前に「ファイル」「開き方」「取込先仕様」を分けて確認するのが先です。

CSV文字化けは「ファイルが壊れた」とは限らない

Excelで開いたときだけ崩れることがある

CSVはテキストファイルです。 中身が同じでも、開くアプリや指定した文字コードによって見え方が変わります。

ExcelでCSVをダブルクリックして開くと、文字コードや区切り文字の判定をExcelに任せることになります。 この判定が期待とずれると、ファイル自体は正しくても、画面上では文字化けして見えます。

たとえば、次のような顧客CSVがあります。

customer_id,customer_name,address
1001,山田商事,東京都千代田区
1002,鈴木工業,大阪府大阪市

customer_id,customer_name,address
1001,山田商事,東京都千代田区
1002,鈴木工業,大阪府大阪市

このファイルを違う文字コードとして開くと、次のように見えることがあります。

customer_id,customer_name,address
1001,螻ｱ逕ｰ蝣ょ,譚ｱ莠ｬ驛ｽ蜊倩ｻ
1002,驥取惠蟾･讌ｭ,螟ｧ髦ｪ蠎懷､ｧ髦ｪ蟶

customer_id,customer_name,address
1001,螻ｱ逕ｰ蝣ょ,譚ｱ莠ｬ驛ｽ蜊倩ｻ
1002,驥取惠蟾･讌ｭ,螟ｧ髦ｪ蠎懷､ｧ髦ｪ蟶

この状態だけを見て、出力処理を直し始めると判断を誤ります。 最初に確認するのは、同じCSVをエディタで開いたときに読めるか、Excelのデータ取り込みで文字コードを指定したら読めるかです。

Excelで崩れていることと、CSVが壊れていることは同じではありません この切り分けを飛ばすと、正しいCSVを別の文字コードへ変換して、別の場所で壊すことがあります。

取込先システムでは読めるのに人間が見ると崩れる

業務システム間のCSV連携では、取込先が期待する文字コードが決まっていることがあります。 古い連携先ではShift_JIS指定、Web系の出力ではUTF-8指定、Excel確認用にはUTF-8 BOM付き、というように用途ごとに前提が違います。

そのため、取込先システムでは問題なく処理されるCSVを、人がExcelで開いたら文字化けすることがあります。 この場合、Excelで見やすい形式へ変換することが正解とは限りません。

人が見るCSVと、システムが読むCSVでは、優先する条件が違います。 人が確認するためのCSVならExcelで読めることが大事です。 システム連携用のCSVなら、相手先の仕様どおりに読めることが大事です。

tomo

「Excelで読めないから文字コードを変える」は、連携用CSVでは危険な対応になることがあります。まず、そのCSVを誰が何に使うのかを確認します。

CSVの正解は、開いた画面の見た目だけではなく、使う相手の仕様で決まります。 この前提を置くと、Excel表示の問題と連携エラーを分けて扱えます。

まず確認するのは文字コード・BOM・開き方

UTF-8でもBOMありとBOMなしでExcelの反応が変わる

UTF-8のCSVであれば、必ずExcelできれいに開けるとは限りません。 Microsoftの案内では、UTF-8のCSVはBOM付きで保存されていれば通常どおり開ける一方、うまく開けない場合はテキストまたはCSVから取り込む流れが案内されています。

つまり、UTF-8という名前だけでは足りません。 BOMの有無と、Excelでどう開いたかを一緒に確認します。

UTF-8 BOM付きは、ファイルの先頭に見えない目印が付いている状態です。 Excelで人が確認するためのCSVでは、このBOMが効くことがあります。

ただし、すべての取込先がBOMを前提にしているわけではありません。 BOMを文字として扱い、1列目のヘッダー名がずれるシステムもあります。

Shift_JIS指定の取込先にUTF-8を渡すと崩れる

古い基幹系や外部取込では、仕様書にShift_JIS指定が残っていることがあります。 この相手にUTF-8のCSVを渡すと、取込時に日本語が崩れたり、処理自体がエラーになったりします。

逆も同じです。 UTF-8指定の相手にShift_JISのCSVを渡すと、取込結果が崩れる可能性があります。

ここで避けたいのは、手元のExcelで読めるようにしたCSVを、そのまま連携ファイルとして渡すことです。 Excelで読める状態は確認作業としては便利ですが、連携仕様より優先されるものではありません。

確認用CSVと連携用CSVを同じものとして扱うと、どちらかの用途で事故ります 連携用では、担当者のExcel表示より、取込先の仕様を優先します。

ダブルクリックではなくデータ取り込みで開いて確認する

ExcelでCSVを見るときは、ダブルクリックだけで判断しないほうが安全です。 ダブルクリックは速い一方で、文字コードや区切り文字の判定をExcelに任せます。

文字化け調査では、Excelのデータ取り込みから文字コードを指定して開きます。 UTF-8、UTF-8 BOM付き、Shift_JISとして開いた結果を比べると、原因がかなり絞れます。

文字化け調査では、ファイルだけでなく開いた方法も証跡に残します。 あとからレビューするとき、「UTF-8のCSVです」とだけ残っていても、Excelでどう開いたのかが分からなければ再現できません。

改行コードと区切り文字も文字化けのように見える

改行コードが合わないと1行に詰まって見える

CSVの見た目が崩れていると、文字コードだけを疑いがちです。 ただ、改行コードの違いで、1行に全部詰まって見えることがあります。

RFC 4180では、CSVのレコードはCRLFで区切る形が示されています。 一方で、実際の業務ファイルではLFだけのCSVもあります。

id,name,amount
1,山田商事,12000
2,鈴木工業,8000

id,name,amount
1,山田商事,12000
2,鈴木工業,8000

このファイルが取込先で1行として扱われる場合、日本語の文字そのものは崩れていないかもしれません。 崩れているのは、どこで1レコードを区切るかという読み取りです。

Windowsで作ったCSV、Linuxサーバーで出力したCSV、外部サービスから落としたCSVが混ざると、改行コードの前提がずれやすくなります。 文字が読めているのに行数だけがおかしい場合は、改行コードを先に見ます。

カンマ区切りとは限らないCSVがある

CSVという名前でも、実際にはタブ区切りやセミコロン区切りのファイルが渡されることがあります。 拡張子が.csvでも、中身が必ずカンマ区切りとは限りません。

次のようなファイルは、見た目はCSVに近いですが、区切り文字はタブです。

id	name	amount
1	山田商事	12000
2	鈴木工業	8000

id	name	amount
1	山田商事	12000
2	鈴木工業	8000

このファイルをカンマ区切りとして開くと、1行が1列に入ります。 反対に、カンマ区切りのCSVをタブ区切りとして開いても列が分かれません。

この状態を文字化けと呼んでしまうと、調査の方向がずれます。 文字が読めないのか、列に分かれないのかを分けて見ます。

文字化けではなく列ズレだった、という切り分け

CSVでは、項目の中にカンマや改行が入ることがあります。 その場合、フィールドをダブルクォートで囲む必要があります。

RFC 4180でも、改行、ダブルクォート、カンマを含むフィールドはダブルクォートで囲む形が示されています。

id,customer_name,memo
1,山田商事,"初回見積, 急ぎ"
2,鈴木工業,"住所確認済み"

id,customer_name,memo
1,山田商事,"初回見積, 急ぎ"
2,鈴木工業,"住所確認済み"

メモ欄のカンマを囲わずに出力すると、列が1つ増えたように見えます。 日本語が崩れていなくても、列がずれて画面が汚く見えるため、文字化けと混同されます。

文字が読めないのか、列の位置がずれているのかを先に分けると、調査時間を減らせます。 文字コード変換で直らない場合は、引用符、区切り文字、項目内改行を確認します。

現場で最初に見る確認表

出力されたCSVをメモ帳やエディタで開く

最初に確認するのは、出力されたCSVそのものです。 Excelではなく、メモ帳やコードエディタで開きます。

目的は、Excelの自動判定を一度外して、ファイルの中身をそのまま見ることです。 エディタで日本語が読めるか、ヘッダー行があるか、1行目に余計な文字がないか、改行が自然かを確認します。

この確認で、出力側の問題か、Excel表示の問題か、CSV構造の問題かを分けられます。 最初の5分でここを分けると、変換ツールを何度も試す流れを避けやすくなります。

Excelでの開き方を変えて再現する

次に、Excelで開き方を変えて再現します。 ダブルクリックで文字化けした場合は、Excelのデータ取り込みから文字コードを指定して開きます。

ここで見るのは、画面で直ったかどうかだけではありません。 どの文字コードを指定したら読めたのか、区切り文字は何を指定したのか、ヘッダー行は正しく認識されたのかを確認します。

tomo

確認メモには「Excelで開いた」とだけ書かず、ダブルクリックなのか、データ取り込みなのかを書きます。ここが抜けると、同じCSVでも再現結果が変わります。

Excelで読める状態を作れたら、次はそれが本来の用途に合っているかを確認します。 人間確認用なら、その開き方を手順にできます。 連携用なら、取込先仕様との一致を見ます。

取込先の仕様書で期待文字コードを確認する

最後に、取込先の仕様書を見ます。 CSVを人が見るだけなら、Excelで読める形を優先してよい場面があります。

別システムへ渡すCSVなら、取込先の期待文字コード、改行コード、区切り文字、ヘッダー有無を優先します。 仕様書がない場合は、過去に正常に取り込めていたCSVを探します。

過去ファイルの文字コード、BOM、改行コード、区切り文字を確認し、新しく出力したCSVと並べます。 仕様書がないときは、正常に取り込めた過去ファイルが強い比較材料になります。

よくある原因別の対処

Excelで見るためのCSVならUTF-8 BOM付きを検討する

人がExcelで開いて確認するCSVなら、UTF-8 BOM付きで出す選択肢があります。 Excelで日本語が崩れにくくなり、確認担当者が毎回データ取り込みを使わなくても済む場合があります。

ただし、これはExcel閲覧用として割り切る場合の話です。 連携先がBOMなしを期待しているなら、BOM付きに変えることで取込側の不具合を作ることがあります。

確認用CSVと連携用CSVを分けられるなら、確認用はExcelで読みやすい形にします。 連携用は相手先仕様に合わせます。

システム連携用なら相手先仕様を優先する

システム連携用CSVでは、相手先仕様を優先します。 Shift_JIS指定ならShift_JIS、UTF-8指定ならUTF-8、ヘッダーなし指定ならヘッダーなしです。

担当者のExcelで見やすいかどうかは、確認作業としては大事です。 しかし、連携仕様より上には置きません。

この注意は、文字化けだけの話ではありません。 商品コードの先頭ゼロが消える、日付が勝手に変換される、長いIDが指数表記になる、という問題もExcel確認で起きます。

Excelで見えるようにした修正が、CSV連携の別の不具合を作ることがあります 表示確認と連携ファイルの保存は、別の作業として分けます。

文字コード変換だけで直らない場合は列ズレを疑う

文字コードを変えても直らない場合は、列ズレを疑います。 特に、住所、備考、コメント、商品名のように自由入力に近い列があるCSVでは、カンマや改行が混ざることがあります。

この表で切り分けると、文字コードの問題とCSV構造の問題を分けられます。 文字コードの問題なら文字コードを直します。 列ズレなら、CSV出力時の引用符、区切り文字、改行の扱いを直します。

修正前に残しておきたい確認証跡

元ファイルと開いた方法をセットで残す

CSV文字化けの調査で困るのは、あとから同じ状態を再現できないことです。 「このファイルが文字化けした」とだけ残っていても、何で開いたのかが分からなければ判断できません。

Excelのダブルクリック、Excelのデータ取り込み、メモ帳、コードエディタ、取込先システムのログでは、見える結果が違います。 そのため、元ファイル、確認したアプリ、開いた方法、指定した文字コードをセットにします。

ファイル名だけでは足りません。 同じCSVでも、UTF-8として開いたのか、Shift_JISとして開いたのかで結果が変わります。

期待する文字コードと実際の文字コードを並べる

次に、期待する文字コードと実際の文字コードを並べます。 取込先仕様がShift_JISなのに、出力ファイルがUTF-8なら、原因はかなり明確です。

反対に、仕様もファイルもUTF-8なのにExcelだけ崩れるなら、BOMやExcelの開き方を見ます。 確認メモは、長い文章よりも、事実を並べた表のほうが使いやすくなります。

この形で残しておくと、修正後の確認にも使えます。 原因が文字コードなのか、Excel表示なのか、連携仕様なのかを説明しやすくなります。

修正後も同じ手順で再確認する

修正後は、同じ手順で再確認します。 修正前はExcelのダブルクリックで見て、修正後はエディタだけで見る、という確認では比較になりません。

同じファイル種別、同じ開き方、同じ取込先で確認して初めて、直ったと言えます。 確認条件が変わると、直ったのか、別の見え方をしているだけなのかが分からなくなります。

tomo

文字化け対応では、変換後のファイルを1回開いて終わりにしません。修正前と同じ手順で見直すと、直したつもりの別問題に気づけます。

調査メモは、今回の障害対応だけでなく、次回の出力仕様を決める材料になります。 属人的な記憶に頼らず、確認条件と結果を残します。

CSV文字化けを再発させない決め方

人が見るCSVとシステム連携CSVを分ける

CSVを作るときに、最初に決めたいのは用途です。 人がExcelで見るCSVなのか、別システムへ渡すCSVなのか、夜間バッチに読ませるCSVなのかを分けます。

用途が違えば、優先する条件も変わります。 確認用はExcelで開きやすいことが重要です。 連携用は相手先仕様どおりに読めることが重要です。

1つのCSVで両方を兼ねようとすると、Excelでは読めるが連携で落ちる、連携では成功するが人が確認しづらい、という状態になりやすくなります。 可能なら、確認用と連携用を分けます。

仕様に文字コード・改行・区切り文字を書く

再発防止で効くのは、仕様に書くことです。 「CSVで出力する」だけでは足りません。

文字コード、BOMの有無、改行コード、区切り文字、ヘッダー有無、引用符の扱いまで書きます。 ここが曖昧だと、担当者や実装者によって出力形式が変わります。

この表を仕様書やREADMEに入れておくだけでも、調査の出発点が変わります。 次に文字化けが起きたとき、「何となくUTF-8にしてみる」ではなく、「仕様はUTF-8 BOMなし、実ファイルはどうか」と確認できます。

迷ったら開く側ではなく使う側を基準にする

最後に、判断基準を決めます。 迷ったら、開く側ではなく使う側を基準にします。

Excelで見るためのCSVなら、Excelで確認しやすいことを重視します。 外部システムへ渡すCSVなら、その外部システムが読めることを重視します。 夜間バッチに読ませるCSVなら、バッチ処理が期待する形式を重視します。

この基準がないと、CSVは簡単に迷子になります。 営業担当者のExcelでは読める。 でも取込先では落ちる。 開発環境では読める。 でも本番バッチでは落ちる。

CSV文字化けを見たときは、まず変換ではなく切り分けです。 ファイルそのものを見る。 Excelでの開き方を変える。 取込先仕様を見る。 改行と区切り文字を見る。 そのうえで、確認用なのか連携用なのかを決めます。

CSV文字化けの対応は、文字コードだけの話ではなく、業務でそのCSVをどう使うかを決める話です。 ここまで決めておくと、次に同じ相談が来ても、勘ではなく、確認手順と仕様で返せます。