カテゴリー: システム開発

会計ソフトから落とした CSV を Excel で開いたら、商品名 のはずの列が 蝠刀蜷 になっていた。逆に、自分が Excel で作って送った CSV を「文字化けしてます」と返された。どちらも経験があるのではないでしょうか。

この 2 つ、立場は正反対ですが、詰まっているところは同じです。CSV というファイルには、中身が何の文字コードで書かれているかを記録する欄がありません。

検体は macOS 26.6.2（ビルド 25G83）と Microsoft Excel for Mac 16.107.2 で、自分で作って実際に開いたり保存したりしたものです。

先に結論

よく見かける「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 のダブルクリックと同じ経路で開いた結果です。

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 が一番楽でした。

1. Excel を開く
2. データタブ → 左端の「データ ファイル指定 (Power Query)」→「テキスト/CSV」
3. 参照からファイルを選ぶ
4. プレビューを確認して「読み込む」

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 sequence

2 か所おかしいところがあります。

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 に変換できない文字を並べてみます。

人名や店名を含む 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 のファイル名が化ける話は別に書いたので、そちらで困っている方はどうぞ