CSV のクォート規則と、スプレッドシート互換のために守るべきルール

約8分
CSVデータExcel

CSV は「シンプルなデータ形式」と言われますが、データにカンマ・改行・ダブルクォートが含まれた瞬間に難易度が上がります。RFC 4180 には正規のルールがあり、これを守らないと Excel と Google Sheets で挙動が変わったり、パースエラーになったりします。本記事では CSV の正規ルールと、互換性のための実践的なポイントを整理します。

RFC 4180：事実上の標準

CSV は長らく明文化された標準が無かったのですが、2005 年に RFC 4180 で形式が定義されました。法的拘束力のある規格ではないものの、現在の多くのライブラリ・ツールはこの仕様に準拠しています。

ルールの要点：

  1. フィールドはカンマ区切り
  2. 行はCRLF（\r\n）で区切る
  3. データに , " \r\n を含む場合はフィールド全体をダブルクォートで囲む
  4. クォート内のダブルクォートは "" でエスケープする
  5. 先頭行はヘッダ（任意）
  6. エンコーディングは ASCII（実際は UTF-8 が事実上の標準）

クォートが必要なフィールドと不要なフィールド

名前,年齢,コメント
山田太郎,30,東京在住
"佐藤,花子",25,"カンマを含む名前"
"改行を
含むコメント",40,"ダブルクォート""を含む"

ルールに従ってクォートが必要なケース：

データクォートが必要
Hello world不要
Hello, world必要（カンマを含む）
Line1\nLine2必要（改行を含む）
He said "Hi"必要（ダブルクォートを含む）
123不要

ダブルクォート自身のエスケープ：""

データにダブルクォート " を含める場合、ダブルクォート2つ "" に置き換え、フィールド全体をクォートで囲みます。

入力データ: He said "Hi"
CSV 表記:   "He said ""Hi"""

バックスラッシュエスケープ（\"）ではない点に注意。CSV はバックスラッシュを特別扱いせず、バックスラッシュもただの文字として扱います。

改行コードの罠：CRLF vs LF

RFC 4180 は CRLF（\r\n）を要求しますが、現実の CSV ファイルは：

  • Windows：CRLF（\r\n）
  • macOS / Linux：LF（\n）
  • 古い Mac：CR（\r）

の3種類が混在します。多くのパーサーは3種類すべて受け入れますが、フィールド内に改行を含む場合だけは別で：

  • フィールド外の改行（行区切り）：パーサーがどれでも受け入れる
  • フィールド内の改行（クォート内のデータ）：そのまま保存される

つまり「改行を含むセルがあるファイル」を環境を跨いで運ぶと、フィールド内の改行コードと行区切りの改行コードが混ざる可能性があります。Excel で開いて再保存すると Windows の CRLF に正規化されますが、それで意図したデータが失われる場合もあります。

Excel 互換のための BOM 問題

UTF-8 でエンコードした CSV を Excel で開くと、日本語が文字化けすることがあります。これは Excel の挙動が：

  • BOM（Byte Order Mark）付きの UTF-8 → 正しく UTF-8 として認識
  • BOM なしの UTF-8 → 環境のロケールに従う（日本語 Windows なら Shift_JIS と誤認識）

という仕様によるものです。

UTF-8 BOM は3バイトのマーク：

0xEF 0xBB 0xBF

これをファイル先頭に付けると、Excel は UTF-8 として認識します。Google Sheets や Numbers は BOM なしでも UTF-8 として扱うので、BOM を付けても問題ありません。

// Excel 互換の UTF-8 CSV を出力する例
const bom = '';
const csv = bom + '名前,年齢\n山田,30\n';

ただし BOM 付き UTF-8 を BOM 不要な処理系に渡すと、最初のフィールドの先頭に余計な文字が見える場合があります。「Excel のためだけに BOM を付ける」のは、Excel 利用が確定している場合に限るのが安全です。

Excel が CSV を勝手に変換する罠

Excel で CSV を開くと、データを勝手に変換することがあります：

  • 数字の先頭ゼロが消える：000123 → 123（数値として解釈）
  • 長い数字が指数表記になる：1234567890123456 → 1.23457E+15
  • 日付っぽい文字列が日付に変換：1-2 → 1月2日
  • 電話番号のハイフンが解釈される：03-1234-5678 → 計算式と誤認

これを防ぐには：

  • データを ="..." でラップしてテキストとして強制する：="000123"
  • タブ区切り（TSV）にする：Excel はタブ区切りなら勝手な変換が控えめ
  • インポートウィザードを使って各列の型を「文字列」に指定する

CSV ファイルをダブルクリックでなく「データ → テキストから」でインポートすると、列ごとに型を指定できるので、変換問題を回避できます。

区切り文字の地域差

ヨーロッパでは小数点に , を使う国が多く、その地域では CSV の区切り文字が ;（セミコロン）になっています：

  • 日本・米国・英国：区切り文字 , 、小数点 .
  • ドイツ・フランス・イタリア：区切り文字 ; 、小数点 ,

国際展開のあるサービスで CSV ダウンロードを提供する場合、ロケールに応じて区切り文字を切り替える実装が必要になることがあります。RFC 4180 が「カンマ区切り」と明記しているのと矛盾しますが、実用上は地域差を受け入れざるを得ません。

CSV を JSON に変換するときの注意

CSV のすべてのフィールドは文字列です。JSON に変換するとき、数値や真偽値に自動変換するか、文字列のまま保つかは設計判断になります。

CSV:   name,age,active
       山田,30,true

そのまま文字列: { "name": "山田", "age": "30", "active": "true" }
型変換あり:    { "name": "山田", "age": 30, "active": true }

型推論を入れると便利ですが、"03-1234" を電話番号として扱いたいのに数値として -1231 に変換される、といった事故が起きます。安全側は「すべて文字列のまま」、利便性優先なら「明示的に型指定可能なオプション」を提供するのが望ましいです。

まとめ：CSV を扱うチェックリスト

  • フィールドにカンマ・改行・ダブルクォートが含まれる場合はクォートする
  • ダブルクォートのエスケープは ""（バックスラッシュではない）
  • Excel 互換が必要なら UTF-8 BOM を付ける
  • 改行コードは CRLF または LF（環境差を許容）
  • 数値・日付の自動変換に注意（特に Excel）
  • 区切り文字の地域差を意識（必要に応じて TSV / セミコロン区切り）

CSV と JSON を相互変換したいときは、本サイトの CSV → JSON 変換ツールで、クォートやエスケープが正しく扱われるか試せます。複雑なデータを含む CSV を扱う前にサンプルを通してみると、想定外の変換に気付けます。