会計ソフトから落とした CSV を Excel で開いたら、商品名 のはずの列が 蝠刀蜷 になっていた。逆に、自分が Excel で作って送った CSV を「文字化けしてます」と返された。どちらも経験があるのではないでしょうか。
この 2 つ、立場は正反対ですが、詰まっているところは同じです。CSV というファイルには、中身が何の文字コードで書かれているかを記録する欄がありません。
検体は macOS 26.6.2（ビルド 25G83）と Microsoft Excel for Mac 16.107.2 で、自分で作って実際に開いたり保存したりしたものです。
先に結論
| 困っている場面 | やること |
|---|---|
| もらった CSV を開いたら化けている | ダブルクリックをやめる。データ → データ ファイル指定 (Power Query) → テキスト/CSV から開く |
| 自分が渡す CSV を作る | 保存形式で「CSV UTF-8」を選ぶ。ただの「CSV（コンマ区切り）」は選ばない |
| プログラムに読ませる CSV を作る | BOM 付きのままでかまいません。読む側で utf-8-sig を指定してもらいます |
よく見かける「Shift_JIS で保存し直す」は入れていません。動くことは動くのですが、戻せない代償があります。
CSV には文字コードを書く欄が無い
商品名,数量,金額 から始まる CSV を UTF-8 で保存して、先頭を覗いてみます。
$ xxd -l 12 utf8_nobom.csv
00000000: e595 86e5 9381 e590 8d2c e695 .........,..e59586 e59381 e5908d が「商品名」を UTF-8 で符号化したバイト列、2c がカンマです。データがいきなり始まっています。ZIP や画像なら先頭にヘッダがあって「これは何か」を名乗るのですが、CSV にはそれがありません。テキストがそのまま置いてあるだけです。
つまり開く側は、書いていないものを推測するしかない。日本語環境の Excel が最初に疑うのは Shift_JIS 系です。UTF-8 のバイト列を Shift_JIS 系として読むと、こうなります。
$ printf '請求書' | iconv -f CP932 -t UTF-8
隲区ｱよ嶌実際に Excel for Mac で開いた画面がこれでした。
| セルに入るはずの値 | 表示された値 |
|---|---|
| 商品名 / 数量 / 金額 | 蝠刀蜷 / 謨ｰ驥 / 驥鷹｡ |
| 請求書 | 隲区ｱよ嶌 |
| 髙橋商店 | 鬮呎ｩ句膚蠎 |
| ①番テーブル | 竭逡ｪ繝ｼ繝悶Ν |
先頭が 蝠・隲・繝・縺・謨・鬮 あたりで始まっていたら、UTF-8 を Shift_JIS 系として読んだ化け方です。ひらがなの多い言葉は 縺、カタカナは 繝 がよく顔を出します。
BOM が付いていると化けない
ところが、同じ内容でも化けない場合があります。先頭に 3 バイトだけ足したものです。
$ xxd -l 12 utf8_bom.csv
00000000: efbb bfe5 9586 e593 81e5 908d ............この ef bb bf が BOM（Byte Order Mark）で、「以下は UTF-8 です」という目印になります。Excel はこれを見て判断を変えます。4 通りの検体を、Finder のダブルクリックと同じ経路で開いた結果です。
| 検体 | 結果 |
|---|---|
| UTF-8（BOM なし） | 化ける |
| UTF-8（BOM 付き） | 正しく開く |
| Shift_JIS（CP932） | 正しく開く |
| UTF-16LE（BOM 付き・カンマ区切り） | 文字は正しいが、全部 A 列の 1 セルに入る |
Microsoft も公式のサポートページで「BOM 付きで保存されていれば UTF-8 の CSV は普通に開ける」と書いています。BOM が唯一の手がかりだ、というのが CSV の文字化けの正体です。
なお file -I は BOM の有無を区別してくれません。BOM あり・なしのどちらも charset=utf-8 と答えます。確かめたいときは上のように xxd -l 3 で先頭 3 バイトを直接見るのが確実です。
もらった CSV が化けているとき
配布元に「BOM 付きで出してください」と言えれば一番早いのですが、たいていそうもいきません。ダブルクリックで開くのをやめて、Excel 側で読み方を指定します。
Mac だと データ → データ ファイル指定 (Power Query) → テキスト/CSV が一番楽でした。
- Excel を開く
- データタブ → 左端の「データ ファイル指定 (Power Query)」→「テキスト/CSV」
- 参照からファイルを選ぶ
- プレビューを確認して「読み込む」
BOM なしの UTF-8 を食わせたところ、プレビューの「元のファイル」は 65001: Unicode (UTF-8)、「区切り記号」は コンマ と、どちらも自動で当たっていました。髙橋商店 も ①番テーブル も化けていません。こちらから指定するものが何もない。
同じドロップダウンに テキストから (レガシ) もあって、こちらは「テキスト ファイル ウィザード」が開きます。ファイル → インポート → CSV ファイルと辿っても同じウィザードでした。入口が 2 つあるだけで中身は同じです。ただ、こちらは自動判定してくれません。
- 1/3 の画面の「元のファイル:」の既定が
Japanese (Mac OS)。これが化ける直接の理由です。Unicode (UTF-8)に変えます - 2/3 の画面の区切り文字の既定がタブ。ここを「コンマ」にしないと、文字は読めるのに全部が 1 列に入ります
私は最初この 2 つ目を飛ばして、せっかく綺麗に読めた文字列が丸ごと A 列に詰まったのを見ました。Power Query のほうが確実なのは、この 2 か所を自分で当てにいかなくて済むからです。
Power Query が使えるのは、Microsoft の案内ではバージョン 16.69 以降かつ Microsoft 365 のサブスクリプションという条件付きです。手元の 16.107.2 では問題なく出ました。条件を満たさない環境ではレガシ側が受け皿になります。
Excel にこだわらないなら、LibreOffice は BOM なしの UTF-8 をそのまま読めます。文字コードを何も指定せずに開いて正しく表示されたので、中身を確認したいだけならこれが早いです。
自分が渡す CSV を作るとき
こちらのほうが厄介でした。Excel for Mac で「CSV（コンマ区切り）」を選んで保存すると、UTF-8 では書かれません。保存されたファイルの先頭はこうです。
$ xxd -l 12 out_csv.csv
00000000: 8fa4 9569 96bc 2c90 9497 ca2c ...i..,....,BOM はなく、8fa4 9569 96bc が「商品名」。Shift_JIS 系のバイト列です。ではこれを CP932 として読めるかというと、読めません。
$ iconv -f CP932 -t UTF-8 out_csv.csv
商品名,数量,金額
請求書,1,1200
_橋商店,3,4500
iconv: iconv(): Illegal byte sequence2 か所おかしいところがあります。
1 つは 3 行目の _橋商店。元は 髙橋商店 でした。髙（はしごだか）が消えて、アンダースコアになっています。
もう 1 つは最後で止まっていること。① のところで不正なバイト列だと言われています。Excel が書いた ① は 8540 でしたが、CP932 の ① は 8740 です。別のバイトが入っている。
正体は Mac OS Japanese でした。Foundation の kCFStringEncodingMacJapanese で復号すると、①番テーブル まで含めて最後まで素直に読めます。同じ「Shift_JIS 系」と呼ばれていても、Windows の CP932 とは持っている文字が違うのです。
表現できない文字がどうなるかを、もう少し意地悪な検体で確かめました。
| 元の値 | 保存後 |
|---|---|
| 𠮷野家 | __野家 |
| 絵文字😀 | 絵文字__ |
| 森鷗外 | 森_外 |
置き換わっているのはファイルの中身だけです。画面上のセルには元の文字が残っているので、保存した本人の目には何も起きていないように見えます。
警告が出ないわけではありません。CSV を開いている間、Excel は本文の上に「データ損失の可能性 このブックをコンマ区切り (.csv) 形式で保存すると、一部の機能が失われる可能性があります」というバーを出しています。ただしこれが言っているのは、書式や複数シートを CSV では持てないという形式一般の話で、髙 が _ になることは何も告げません。読み流してしまう種類の警告です。渡した先で初めて「名前が _ になってます」と言われることになります。
Excel for Mac で人に渡す CSV を作るなら、保存形式は「CSV UTF-8」を選んでください。こちらは先頭に efbbbf が付いた UTF-8 で保存されます。
BOM は誰のために付いているのか
その BOM が、渡す先によっては邪魔になります。人ではなくプログラムに読ませたとき。Python で普通に読むとこうです。
$ python3 -c "
import csv, io
raw = open('utf8_bom.csv', encoding='utf-8').read()
row = next(csv.DictReader(io.StringIO(raw)))
print(list(row.keys()))
print(row['商品名'])
"
['\ufeff商品名', '数量', '金額']
Traceback (most recent call last):
File "<string>", line 6, in <module>
KeyError: '商品名'先頭の列名が 商品名 ではなく \ufeff商品名 になっています。\ufeff が BOM で、1 文字目として列名に食い込んだ形です。厄介なのは、この文字が幅を持たないこと。Python は repr で見せてくれますが、print() でそのまま画面に出すと見た目は 商品名 のままです。KeyError を見て「列名は合っているのに」としばらく悩むことになります。
これは読む側の設定ひとつで消えます。encoding='utf-8' を encoding='utf-8-sig' に変えるだけ。sig 付きのほうは BOM があれば読み飛ばし、無ければそのまま読むので、BOM 付きと BOM なしを同じコードで扱えます。手元で両方通したところ、どちらも 商品名 が取れました。
つまり「Excel を取るかプログラムを取るか」という板挟みではないのですね。BOM が働いているのはダブルクリックで開いたときの一瞬だけで、Excel の推測に手がかりを渡している。前の節の Power Query 経路も、ウィザードで文字コードを指定する経路も、BOM があろうとなかろうと同じように開きます。
なので、出す側は BOM を付けておく。受け取る側はそれぞれの流儀で読む。それで両方立ちます。本当に困るのは、受け取り先のコードが utf-8 決め打ちで、しかもそこを直せないときだけです。
おまけ:よく見かけるけれど勧めない対処
まず、Shift_JIS で保存し直すという手。上位に出てくる記事の多くがこれを勧めていて、Excel が Shift_JIS 系を素直に読むのは事実なので、動くことは動きます。ただし片道切符です。CP932 に変換できない文字を並べてみます。
| 文字 | CP932 |
|---|---|
| 髙 ① ㈱ Ⅲ 斎 | 変換できる |
| 鷗（鷗外の鷗） | 変換できない |
| 𠮷（つちよし） | 変換できない |
| 𩸽（ほっけ） | 変換できない |
| 😀 | 変換できない |
人名や店名を含む CSV でこれをやると、変換できなかった文字がその場で失われます。あとから UTF-8 に戻しても帰ってきません。しかも Mac 経由だと 髙 まで落ちる（前の節のとおり）ので、Windows の記事に書いてある「Shift_JIS なら大丈夫」がそのまま通用しない。
もう一つ、UTF-16 で保存し直すという手もよく見ます。試したところ、文字化けは確かに直りました。ただし 商品名,数量,金額 が丸ごと A1 セルに入ります。文字は読めるのに表になっていない、という中途半端なところに着地しました。カンマが区切りとして扱われていないわけですが、なぜそうなるのかまでは確かめていません（タブ区切りの UTF-16 で試していないので、そこは断定を避けておきます）。表として使いたいなら、この手は回り道です。
ついでに、化けているように見えて実は別物のこともあります。引用符の中にカンマや改行が入っている CSV は、Excel はきちんと解釈しました。"カンマ, あり" は 1 セルに収まり、セル内改行も改行のまま残ります。列がずれているだけなら文字コードの問題ではないので、先に区切り文字を疑うほうが早道です。
さいごに
開くときはダブルクリックをやめて Power Query から、渡すときは「CSV UTF-8」で保存。実務で必要なのはこの 2 つだけです。
それにしても、と思うのです。ZIP がファイル名の文字コードを宣言する 1 ビットを後から継ぎ足したように、CSV も BOM という後付けの目印で何とかしのいでいる。どちらも、文字コードが 1 つに決まっていなかった時代に生まれた形式で、後から世界が広がった分のつじつまを端っこで合わせている。髙 が _ に変わったときも、Excel は「一部の機能が失われる可能性があります」としか言いません。嘘はついていないのですが、いま消えたのがその 1 文字だとは教えてくれない。警告の粒度というのは難しいものだな、と思いながら見ていました。
余談ですが、同じ原因でこの記事を書いていて WordPressで 「公開に失敗しました。 データベース内の投稿を更新できませんでした。」とでてハマ りました…
ZIP のファイル名が化ける話は別に書いたので、そちらで困っている方はどうぞ