CSV RFC 4180のルール

文法：レコード、フィールド、CRLF

RFC 4180の文法は1段落に収まります。ファイルはレコードから成り、各レコードはカンマで区切られたフィールドの列です。レコードはCRLF——Unixツールの裸のLFではなく、0x0D 0x0Aという2バイト——で区切られ、最後のレコードの末尾にCRLFが付くかどうかは任意です。フィールドはクォートされてもされなくても構いません。クォートは条件次第であり、スタイルではありません。ABNFの概要はfile = [header CRLF] record *(CRLF record); record = field *(comma field)で、括弧内のヘッダーが任意である点に注目してください。

id,name,score
1,Ada,99
2,Grace,98

レコード1: id=1, name=Ada,   score=99
レコード2: id=2, name=Grace, score=98

（各レコードは2バイトのCRLFで終わる。
最後のレコードでは省略してもよい）

クォート：二重引用符だけで出来ているエスケープ機構

フィールドは必要なときに二重引用符で囲まれます。そして、クォートされたフィールドの中に二重引用符を入れる唯一の方法が、それを2つ重ねることです。クォート内の""は、1個のリテラルな引用符を意味します。これがエスケープ機構のすべてです。バックスラッシュも、名前付きエンティティも、2つ目の引用文字もありません。シングルクォートはただのデータですし、カンマの後に迷い込んだスペースは次のフィールドの一部です。スペースは保存され、切り詰めてはならないと、仕様は明言しています。

year,quote,note
1962,"she said ""look, no hands""","multi-word, no problem"

year   → 1962
quote  → she said "look, no hands"
note   → multi-word, no problem

フィールド内の改行とカンマ

クォートされたフィールドは改行を含めてよいため、CSVの1行は1レコードとは限りません。\nでの素朴な分割は、複数行のフィールドを含むファイルを必ず壊します。住所ブロック、備考カラム、CSVに埋め込まれたJSONペイロードが素朴なインポーターを壊すのはこのためです。準拠したパーサは小さな状態機械です。クォートの中ではカンマも改行もデータ、外では区切り文字。split()だけでは正しく書けません。

同じ状態機械が、二重引用符のエッジケースも片付けます。値の途中で開く引用符、ファイル末尾で閉じられていない引用符、フィールドの一番最後にある重ねられた引用符。これらはまさに、RFC 4180のわずかなルールが解決するために書かれたケースであり、まさに手書きのパーサ同士が食い違う場所です。「Excelでは開けるのにインポーターで壊れる」報告のほとんどの発生源です。

name,address
"Ada","12 St James Square,
London"
"Grace","1 Loop Rd"

レコード1: Ada | 12 St James Square,
London
レコード2: Grace | 1 Loop Rd

（住所内のカンマはデータの一部。
引用符内のCRLFも同様）

CRLF、任意のヘッダー、そしてtext/csv

仕様で確定しているのに、日常では逆に決め込まれている細部が3つあります。レコードはCRLFで終わる——ただし最終レコードは省略できて、毎日使うパーサはどれも裸のLFを受け付ける。最初のレコードは列名を含めてもよいが、文法上は任意です。ヘッダーはフォーマットがサポートする慣行であって要求する構造ではないため、1行目がデータかどうかをツールに教えるか、あるいはツールが推測するしかありません。そして登録済みのMIMEタイプはtext/csvです。RFC 4180自身が登録したもので、charsetパラメータは送信者に委ねられています。

RFCが固く引く線がもう1つあります。区切り文字はカンマだということです。セミコロン区切りのファイルは、表計算ソフトのロケール慣行——小数点にカンマを使う地域では標準的——であって、規格が認めるバリアントではありません。準拠した書き手は決して推測せず、準拠したパーサは区切り文字を推測するか教えてもらうかします。しかしファイル自体は、どの慣行に従っているかの印を一切持ちません。

現実のファイルが規格からずれる箇所

現実のCSVはRFCより先にあるため、逸脱は例外ではなく常態です。「このCSVがパースできない」事案のほぼすべては、次の5つのずれに帰着します：

良いツールは、黙って推測するのではなく、こうした逸脱を表面化させます。ファイルが重要である場合——請求書、金融データの取り込み、監督機関が読むかもしれないあらゆるもの——は、上の文法と照らし合わせ、下流のパーサ全部に同じ例外を教え込む代わりに、源流でずれを直してください。

往復に耐えるCSVを書く

信頼できる書き手のチェックリストは、文法から直接導けます。クォートは均一に。全フィールドか、ルールが要求するフィールドだけか。どちらも準拠ですが、読み返すときの安全度は均一のほうが上です。CRLFを出力し、ヘッダー行を書き、UTF-8でエンコードする。表計算ソフトに認めてもらう代償としてBOMが付くことも、ある程度は受け入れる。そして重要なものは必ず往復テストします。書いたばかりのファイルをパースし、全フィールドが元データと一致することを確認してから出荷する。繰り返し起きる失敗モードはいつも同じです。書き手がクォートしなかった、区切り文字を含む値です。