Excel が CSV を壊す理由と、その止め方

最初に消えるのは先頭のゼロ

007 という値は、Excel には余計な文字が二つ前に付いた数値の 7 に見えます。だから本当に 7 になります。郵便番号、支店コード、部品番号など、桁数そのものに意味がある識別子はすべて同じ目に遭います。

これはまだ気づきやすいほうです。列が目に見えて右寄せになり、ゼロが消えるからです。そのため値の前にアポストロフィを付けて手で直す人が多いのですが、それは次の書き出しまでしかもちません。

Excel が保つのは有効数字 15 桁まで

実害が大きいのはこちらです。見た目におかしなところが何もないからです。Excel で数値として保存された値は、有効数字 15 桁までしか保たれません。16 桁の注文参照番号、長い取引 ID、カード番号のような値を貼り付けると、最後の桁がゼロに変わります。

セルには相変わらず長い数字が並びます。強調もされず、警告も出ません。ただ値が元の値ではなくなっているだけで、その値を使う照合はすべて失敗するようになります。原因を突き止めるのに半日かかる種類の問題です。15 桁を超える値は文字列として保存する必要があり、保存後に表示形式をいくら変えても復元できません。ディスクに書かれた値から、すでに桁が失われているからです。

日付に似たコードは日付になる

3-1 と入力すれば 3 月 1 日が返ってきます。SEPT1 と入力すれば 9 月 1 日になります。作り話ではなく、遺伝学の分野で大規模に起きたことです。SEPT1、MARCH1、DEC1 といった遺伝子記号が、日付解釈器の探している形とちょうど一致したからです。

問題があまりに広範だったため、2020 年にヒト遺伝子の命名を担う委員会は、表計算ソフトとの言い争いを続ける代わりに該当する記号の名前を変更しました。遺伝子の改名のほうが楽な道だったのなら、自社の商品コードが特別である理由もありません。

文字コードの問題は別件で、同じくらい厄介

バイト順マークなしで UTF-8 保存した CSV は、Excel ではシステムの旧来の文字コードとして解釈され、日本語やアクセント付きの文字がすべて文字化けします。同じファイルにバイト順マークを付けるだけで、きれいに開きます。

同じ書き出しなのに、ある同僚には整った表が見え、別の同僚には文字化けが見える理由がこれです。二人の間でファイルが変わったのではなく、二台が別々の文字コードを推測しただけです。

区切り文字さえ固定ではない

Excel は常にカンマで区切るわけではありません。小数点の区切りがカンマである地域、つまりヨーロッパの多くでは、Excel はフィールドの間にセミコロンを期待し、カンマ区切りのファイルは縦に長い一列のテキストとして入ってきます。

ファイルが壊れているのではありません。書かれたときとは違う地域設定で読まれているだけで、文字コードの問題と同じ種類であり、同じ苦情を生みます。私の環境では動くのに、というやつです。

実際にこれを防ぐ方法

CSV をダブルクリックで開く習慣をやめましょう。代わりにデータタブの取り込み経路を使い、データがシートに入る前に、危ういフィールドをすべて文字列に設定します。その取り込みダイアログこそ、判断が Excel ではなく自分のものになる唯一の瞬間です。

最近のバージョンは推測そのものを設定として公開しています。オプションからデータへ進むと、日付・長い数値・先頭のゼロの自動変換を個別に切ることができます。書き出したデータを日常的に扱う機械なら、三つとも切っておく価値があります。

より確実な解決は、Excel で開く相手に CSV を送るのをやめることです。本物の .xlsx ブックではセルごとに型が一緒に保存されるので、文字列として書いた列は、誰がどの機械のどの地域設定で開いても文字列のままです。

すでに Excel を通ったファイルを点検する

Excel から保存されたファイルなら、損傷は表示ではなく保存された値の側にあります。ですから列幅を広げても何も証明できません。本来より短くなった識別子、末尾が不自然に丸いゼロで終わる長い数値、コード列に静かに紛れ込んだ日付を探してください。

いちばん早い確認は、元のファイルを表計算ではなく素のテキストとして開き、既知の値をいくつか表計算の表示と突き合わせることです。食い違えば、その表計算はデータを映す窓ではありません。別のデータセットであり、残す価値があるのはテキストファイルのほうです。