CSVが文字化けする原因と直し方 ― 仕組みから理解する根本解決

更新日: 2026年2月26日 ・ 読了目安: 8分

業務でCSVファイルを触っていると、ほぼ必ずぶつかるのが文字化けです。Excelで開いたら「縺ｮ繧後※」とか「ﾃ・ﾃ・」みたいな文字列が並んでいて、思わず画面を閉じたくなった——そんな経験、ありませんか。

ネットで調べると「メモ帳で開いてUTF-8で保存し直しましょう」みたいな対処法がよく出てきます。もちろんそれで直ることはあるんですが、なぜそれで直るのかがわかっていないと、違うパターンの文字化けに出くわしたときにまた振り出しに戻ってしまいます。

この記事では、文字化けが起きるメカニズムをなるべく噛み砕きつつ、実際に使える直し方を紹介していきます。

そもそも「文字コード」って何？

コンピュータは、突き詰めると0と1しか理解できません。「あ」や「A」のような文字を扱うには、「この数値はこの文字」という対応表が必要です。この対応表のことを文字コード（エンコーディング）と呼びます。

試しに「あ」という1文字で比べてみましょう。

UTF-8     → E3 81 82（3バイト）
Shift-JIS → 82 A0（2バイト）
EUC-JP    → A4 A2（2バイト）

同じ「あ」なのに、文字コードが違うとバイト列がまるっきり変わります。CSVファイルの中身は結局バイト列の羅列なので、どの文字コードで書かれたかを正しく判別できなければ、文字として復元できません。これが文字化けの正体です。

文字化けが起きる典型パターン

日本語環境での文字化けは、ほぼ次の3つに絞られます。

パターン1: UTF-8のCSVをExcelで開いた

ダントツで多いのがこれ。WebサービスやクラウドシステムからエクスポートしたCSVは、ほぼ例外なくUTF-8で出力されます。ところがWindows版のExcelは、CSVを開くときにShift-JIS（正確にはCP932）で解釈しようとするんですね。

UTF-8のバイト列を「Shift-JISでしょ」と思い込んで読むわけですから、まともな文字になるはずがありません。「東京都」が「譚ア莠ｬ驛ｽ」になったりする、あの現象です。

パターン2: Shift-JISのCSVをMacやLinuxで開いた

パターン1の逆です。たとえば社内の基幹システムが吐き出すCSVがShift-JISで、それをMacのNumbers（UTF-8が前提）で開くと化けます。最近はMacを業務で使う会社も増えてきたので、このパターンも珍しくなくなりました。

パターン3: BOMが付いているかどうかで挙動が変わる

BOM（Byte Order Mark）は、ファイル先頭に付ける目印のようなもの。UTF-8の場合は EF BB BF という3バイトです。ExcelはこのBOMを手がかりに「あ、UTF-8だな」と判断してくれるんですが、BOMがないと問答無用でShift-JIS扱いにしてきます。

つまり、まったく同じ中身のUTF-8ファイルでも、BOMの有無でExcelの表示結果が変わる。ちょっとわかりにくい挙動ですよね。

なぜExcelはUTF-8をすんなり読んでくれないのか

「Excelが最初からUTF-8に対応してくれればいいのに」——そう思いますよね。これには歴史的な経緯があります。

Windows日本語版は1990年代からShift-JISを標準の文字コードとして使ってきました。ExcelのCSV読み込みもその前提で作られており、「CSVはOSデフォルトの文字コードで読む」という挙動がずっと維持されています。

最近のExcel（Microsoft 365）では文字コードを選べるダイアログが出ることもありますが、ダブルクリックで直接開いた場合は従来どおりShift-JIS前提。ファイル側で手を打っておくのがいちばん確実です。

文字化けの直し方

方法1: BOM付きUTF-8に変換する（いちばんおすすめ）

ExcelでUTF-8のCSVを正しく開きたいなら、ファイル先頭にBOMを付けてあげるのが手っ取り早いです。BOMさえ付いていれば、ExcelはちゃんとUTF-8として認識してくれます。

Windowsのメモ帳でCSVを開いて「名前を付けて保存」→ 文字コードで「UTF-8（BOM付き）」を選ぶ、という方法でも一応できます。ただ、メモ帳でCSVを触るとデータの構造が壊れるリスクがあるので、行数が多いファイルには専用ツールを使ったほうが安心です。

方法2: Shift-JISに変換してしまう

社内でExcelしか使わない環境なら、いっそShift-JISに変換するのもアリです。BOMの有無を気にしなくて済みますし、古い環境でも問題なく開けます。

ただし、Shift-JISが扱えるのは日本語・英語と一部の記号だけ。中国語やベトナム語の人名が入ったデータだと、変換した瞬間にそれらの文字が消えてしまいます。グローバルなデータを扱うならUTF-8一択です。

方法3: Excelの「データの取得」機能で読み込む

CSVファイル自体は触らずに、Excel側の読み込み設定を変える方法もあります。「データ」タブ →「テキストまたはCSVから」で読み込めば、文字コードを指定できるダイアログが出ます。ここで「65001: Unicode (UTF-8)」を選べばOK。

ただ、毎回この手順を踏むのはけっこう面倒です。定常業務でCSVを扱うなら、ファイル側をBOM付きUTF-8にしてダブルクリック一発で開けるようにしておくほうが、チーム全体で見ると楽になります。

Googleスプレッドシートの場合

GoogleスプレッドシートはUTF-8が標準なので、UTF-8のCSVなら基本的にそのまま開けます。文字化けするのは、Shift-JISやEUC-JPのCSVをインポートしたとき。

対処はシンプルで、事前にUTF-8に変換するだけです。BOMの有無は気にしなくて大丈夫。

プログラムからCSVを出力するときの注意

ここからは開発者向けの話です。CSVを生成するコードを書くときは「誰がどの環境で開くか」を意識しておくと、あとあとのトラブルが減ります。

日本の業務ユーザーがExcelで開くなら、UTF-8 + BOM付きが無難です。Pythonなら encoding='utf-8-sig' を指定するだけでBOMが付きます。

# Python での BOM付きUTF-8出力
with open('output.csv', 'w', encoding='utf-8-sig', newline='') as f:
    writer = csv.writer(f)
    writer.writerow(['名前', '部署', 'メール'])
    writer.writerow(['田中太郎', '営業部', '[email protected]'])

改行コードも地味に大事です。Windows向けならCRLF（\r\n）にしておくと無難。ExcelはLF（\n）でも読めますが、古い業務システムがCRLF前提というケースはあるので、出力先がわかっているなら合わせておくと安心です。

文字コードの自動判定はどこまで信用できる？

エディタやツールの中には「文字コードを自動検出」してくれるものがあります。便利ですが、万能ではありません。

自動検出は、バイト列の出現パターンから「UTF-8っぽい」「Shift-JISっぽい」と統計的に推定するしくみです。日本語がそれなりに含まれていれば精度は高いんですが、英数字だけのCSVや、日本語がほんの数文字しかないCSVだと誤判定が起きることもあります。

確実に判定したいなら、CSVを出力した側の仕様書を確認するのがいちばんです。自動検出は「たぶんこれだろう」という推定だと割り切っておきましょう。

まとめ

文字化けの原因は、ファイル側の文字コードと、読む側が期待する文字コードのミスマッチ。それ以上でもそれ以下でもありません。

日本語環境でのCSVトラブルは大半がUTF-8とShift-JISの食い違いで起きていて、BOM付きUTF-8にしておけばExcelでもGoogleスプレッドシートでも問題なく開けます。仕組みがわかっていれば、どんなパターンの文字化けにもわりと冷静に対処できるはずです。

「理屈はわかったけど手作業は面倒……」という方は、ツールに任せてしまうのが早いです。