CSVの文字化けを直す文字コード変換(UTF-8 BOM付き・Shift_JIS)

CSVやテキストファイルの文字コードを変換する無料ツールです。BOM無しUTF-8のCSVをExcelで開くと文字化けする問題を、BOM付きUTF-8またはShift_JISへ変換して解決します。元の文字コードは自動判定、改行コード(CRLF/LF)の変換にも対応。ファイルはブラウザ内だけで処理し送信しません。

用途別の推奨設定

「どの文字コードで保存すればいいか」は渡す相手によって決まります。迷ったときの目安です。

やりたいこと 推奨する設定
UTF-8のCSVをExcelでそのまま開きたい UTF-8 + BOMを付ける(Excelが文字コードを判別できるようになります)
古い業務システム・会計ソフトに取り込む Shift_JIS + CRLF(Windows向けの旧来の組み合わせ)
プログラム(Python・PHP等)で読み込む UTF-8(BOM無し)+ LF(BOMがあると先頭の項目名がずれる原因になります)
Mac版Excelで開きたい UTF-8 + BOMを付ける(Mac版もBOMがある方が安定して開けます)
Googleスプレッドシートにインポートする UTF-8(BOMはどちらでも可)(BOMは自動で無視されます)
メールの本文として貼る文章を用意する JIS(ISO-2022-JP)(古いメール環境向けの文字コード)

文字コードの特徴

このツールが対応している文字コードと、選ぶときの注意点です。

文字コード 特徴
UTF-8 世界中の文字を扱える現在の標準。絵文字も表現できます。
UTF-8(BOM付き) 先頭に3バイトの目印を付けた形式。Excelが文字コードを誤判定しなくなります。
Shift_JIS Windowsの日本語環境で長く使われた文字コード。絵文字や一部の異体字(髙・﨑など)は表現できません。
EUC-JP 主にUNIX系で使われた日本語の文字コード。現在は新規採用されることは稀です。
ISO-2022-JP(JIS) メールで使われてきた文字コード。半角カナを表現できません。

CSVの文字化けはなぜ起きるのか

CSVをExcelで開いたときに文字が崩れる原因のほとんどは、ファイルの文字コードとExcelが想定する文字コードの食い違いです。Windows版のExcelは、CSVファイルに何の目印もない場合、その中身をShift_JISだと仮定して読み込みます。ところが最近のWebサービスやプログラムが書き出すCSVはUTF-8であることが多く、UTF-8のバイト列をShift_JISとして解釈した結果、「譁�蟄怜喧縺�」のような崩れた文字列が表示されます。

解決策は2つあります。ひとつはファイルをShift_JISに変換すること、もうひとつはUTF-8のままファイル先頭にBOM(Byte Order Mark、3バイトの目印)を付けることです。BOMがあるとExcelは「これはUTF-8だ」と判断できるため、中身を変えずに文字化けを防げます。このツールはどちらの変換にも対応し、元のファイルの文字コードは自動で判定します。処理はすべてブラウザ内で行うため、ファイルがサーバーへ送信されることはありません。

文字コード変換の使い方

  1. ファイルを選ぶ CSVやテキストファイルをドラッグ&ドロップするか、クリックして選択します。読み込むと元の文字コードと改行コードを自動判定します。
  2. プレビューで判定を確かめる プレビューの文字が正しく読めていれば判定は成功しています。崩れて見える場合は、テキストファイル以外を選んでいる可能性があります。
  3. 変換先を選ぶ Excelで開くなら「UTF-8」+「BOMを付ける」、古い業務システムに取り込むなら「Shift_JIS」を選びます。
  4. ダウンロードする 「変換してダウンロード」を押すと、元のファイル名に文字コードの接尾辞(_utf8bom・_sjis など)を付けたファイルが保存されます。

使いこなすためのヒント

  • Excelで開くだけが目的ならUTF-8にBOMを付けるのが最も安全です。中身の文字はそのまま保たれるため、絵文字や特殊な記号が失われません。
  • Shift_JISへ変換すると表現できない文字が「?」に置き換わります。このツールは失われる文字を一覧で警告するので、変換前に影響を確認できます。
  • プログラムで読み込むファイルにはBOMを付けないでください。多くの言語ではBOMが最初の項目名の一部として読み込まれ、列名の一致に失敗する原因になります。
  • Excelで「データ」→「テキストまたはCSVから」を使えば文字コードを指定して開けますが、毎回操作が必要です。ファイル自体を変換しておけばダブルクリックで開けます。
  • 文字化けした文字列をその場で直したいだけなら、ファイル変換ではなく文字化け変換・自動修復ツールの方が手軽です。

こんなときに使えます

Webサービスから書き出したCSVがExcelで文字化けする

売上データや会員リストをUTF-8で書き出すサービスは多く、そのままExcelで開くと文字化けします。BOMを付けるだけで解決します。

会計ソフト・給与システムに取り込めない

古い業務システムはShift_JISのCSVしか受け付けないことがあります。UTF-8のファイルをShift_JISへ変換して取り込めるようにします。

BOM付きCSVをプログラムで読むと先頭列がおかしい

BOMは見えない3バイトのため、そのまま読むと最初の項目名に紛れ込みます。BOMを外したUTF-8へ変換すれば解決します。

改行コードの違いで1行として扱われてしまう

Macで作ったLFのファイルを古いWindowsアプリで開くと改行が無視されることがあります。CRLFへ変換して渡せます。

文字化けしたファイルの中身を確認したい

文字コードを自動判定して正しく読み直すため、開いても読めなかったファイルの内容をプレビューで確認できます。

文字コードに関する用語

文字コード(エンコーディング)
文字とコンピューター内部のバイト列を対応づける規則です。書き出したときと読み込むときで規則が違うと文字化けが起きます。
BOM
Byte Order Mark の略で、ファイル先頭に置く3バイト(EF BB BF)の目印です。UTF-8であることをアプリに伝える役割を持ちますが、プログラムで読む場合は不要な文字として扱われることがあります。
改行コード
行の終わりを表すバイトです。Windowsは CRLF(2バイト)、Mac・Linuxは LF(1バイト)を使うため、環境をまたぐと1行に見えたり余分な行が増えたりします。
Shift_JIS
Windowsの日本語環境で広く使われてきた文字コードです。収録文字数がUTF-8より少なく、絵文字や一部の異体字を表現できません。
文字化け(もじばけ)
本来とは違う文字コードで読み込んだ結果、意味をなさない文字が並ぶ状態です。「譁�蟄怜喧」のような並びはUTF-8をShift_JISとして読んだときの典型例です。

よくある質問

相手がExcelだけならBOM付きUTF-8を選んでください。中身の文字を一切失わずに文字化けを防げます。Shift_JISが必要なのは、取り込み先の業務システムがShift_JIS固定で指定している場合だけです。Shift_JISでは絵文字や「髙」「﨑」などの異体字が失われます。

ファイル先頭に置く3バイト(EF BB BF)の目印です。文字としては表示されませんが、Excelなどのアプリはこれを見て「UTF-8だ」と判断します。付けても本文の文字は変わらないため、Excelで開く用途では安全です。一方、プログラムで読む場合は最初の1項目に紛れ込むことがあるため付けない方が無難です。

いいえ。文字コードの判定・変換・ダウンロードのすべてをブラウザ内のJavaScriptで行っており、ファイルの内容が外部へ送信されることはありません。個人情報や社内データを含むCSVでも安心してお使いいただけます。

「文字コードを確定できませんでした」と表示された場合、テキストファイル以外(Excelの.xlsxやZIPなど)を選んでいる可能性があります。.xlsx は内部が圧縮された別形式のため、このツールでは扱えません。Excelから「CSV UTF-8」または「CSV」形式で保存し直してからお試しください。

いいえ。このツールはファイルのバイト列を文字コードだけ変換するため、内容は一切変わりません。先頭のゼロが消えるのはExcelがCSVを開くときに数値として解釈するためで、文字コードとは別の問題です。
ツールくん

余談ですが ― 「譁�蟄怜喧」はなぜ生まれるのか

文字化けした文字列には、原因ごとにおおよその見た目のパターンがあります。「譁�蟄怜喧」のように漢字が並ぶのは、UTF-8のバイト列をShift_JISとして読んだ場合です。UTF-8では日本語1文字が3バイトなので、それを2バイトずつ区切って読み直すと、まったく別の漢字が現れます。逆にShift_JISのファイルをUTF-8として読むと、対応する文字が存在しないため「文字化け」のように置換文字(U+FFFD)が並びます。見た目から原因を推測できるわけです。

BOMという仕組みは、もともとUTF-16でバイトの並び順(ビッグエンディアンかリトルエンディアンか)を示すために作られました。UTF-8には並び順の問題がないため本来BOMは不要で、Unicodeの規格でも「推奨しない」とされています。それにもかかわらずWindowsの世界で広く使われているのは、文字コードを自動判定するしかないアプリにとって、明示的な目印がどうしても必要だったからです。規格上は不要とされたものが実務では欠かせないという、興味深い逆転が起きています。

「CSV」という形式に公式な仕様が定まったのは、実は2005年のRFC 4180と比較的最近のことです。それ以前から各社が独自にカンマ区切りのファイルを扱っていたため、文字コードだけでなく引用符の扱い・改行の扱いも実装ごとに揺れていました。今でもCSVの取り込みでトラブルが起きやすいのは、この「先に普及して後から仕様が来た」歴史のためです。