CSVフォーマットへのラブレター

• CSVを置き換える「より優れた」形式がしばしば紹介されるが、その多くは偏った比較に基づいており、CSVの本当の強みを見落としている
• この記事はCSVが完璧だと主張するものではなく、過小評価されている利点に光を当てることを目的としている
• CSVを嫌うのが格好いいかのような空気に逆らい、CSVの真価を改めて見つめ直す

1. CSVは極めてシンプル

• CSVの定義は題名のとおり、「カンマ区切りの値」
• 行は改行で、列はカンマで区切られる
• 値にカンマや改行が含まれる場合は引用符で囲み、引用符そのものは二重引用符で表す
• 複雑な仕様がなく、誰でも直感的に理解して使える
• ただし、正確にパースするためには専用のCSVパーサーを使う必要がある

2. CSVは集合知のアイデア

• 所有者がおらず、私有化もされていない
• RFC 4180は存在するが、ほとんどの人は参考程度にしか見ていない
• 世界中の開発者が暗黙に共有する共通ルールに基づく自由な形式

3. CSVはテキスト

• JSON、YAML、XMLのように人が読めるプレーンテキスト形式
• どんなテキストエディタでも開けて、専用ツールなしでも内容を確認できる
• エンコーディング方式も自由に選べる

4. CSVはストリーミングに最適化されている

• 1行ずつ読む構造なので、メモリ消費が非常に少ない
• シンプルなコードだけで、数GBのデータを数KBのメモリで処理できる
• Parquetのような列指向フォーマットはストリーミング処理が難しく、複雑なバッファリングが必要になる
• 欠点は、特定の列だけ見たい場合でも行全体を読まなければならないこと

5. CSVは簡単に追記できる

• ファイルをappendモード(a+)で開いて新しい行を末尾に追加するのがとても簡単
• 一方でParquetなどの列指向フォーマットは、行の追加が非効率で複雑

6. CSVは動的型付けを許容する

• 固定型がないため、柔軟にデータを解釈できる
• 例: JavaScriptは64ビット整数を正確に表現できないが、CSVならこうした制約なしに使える
• 言語間の互換性と柔軟性の面で利点がある
• ただし、誤って解釈するとエラーが起こりうるため、利用時には注意が必要
• 高性能が求められる場合は、テキストをデコードせずにバイナリレベルで直接処理することも可能

7. CSVは簡潔

• ヘッダーはファイルの先頭にしか存在しないため、形式の繰り返しがほとんどない
• JSONやXMLはキーの繰り返しによるオーバーヘッドが大きい
• 文字列表現自体もすでに簡潔で、フォーマット固有のオーバーヘッド（カンマ、引用符など）も非常に少ない

8. 反転したCSVも依然として有効

• CSVはバイト単位で反転しても、なお有効なCSVである
• これは二重引用符によるエスケープ方式のおかげで、回文のようなエスケープ方式になっているため
• この特性により、CSVファイルの末尾部分を非常に効率よく読める
• 例: 中断したプロセスを再開するとき、ファイルの最後の数行だけを読んで再スタートできる

9. ExcelはCSVを嫌う

• Excelが扱いづらいと感じる形式なら、むしろ正しい道を進んでいるサインかもしれない

[ng0301]

シンプル・イズ・ベスト！

[ethanhur]

もっと悪いほど、より良い！

[GN⁺]

Hacker Newsの意見

• CSVやINIファイルが好きな理由は、シンプルでテキストベースであり、形式に型がエンコードされておらず、文字列だけで構成されているから

  • 公式標準がないという欠点はあるが、役目は十分に果たしている
  • TOMLに対するINI批判をブックマークしてある
  • TOML批判の最初の一文はCSVにも当てはまると思う: さまざまな方言の寄せ集めである

• CSVはエレガントだが致命的な欠点がある - 引用符が「非局所的」な効果を持つ

  • たとえば、バイト1にある1つの引用符が、バイト1000000にあるカンマの意味を変えうる
  • このため2つの厄介な結果が生じる
    • CSV処理の並列化が難しい
    • データ破損がファイルの可読性に大きく影響する（引用符1つの欠落や追加で全体が壊れうる）
  • そのため最近では、単純な表形式データのシリアライズにはCSVより単純なエスケープを好んでいる

• CSVの最高の点は、誰でも30分でパーサーを書けること

  • 90年代初頭のデータを現代のWebサービスへ簡単に取り込める
  • 最悪な点も、誰でも30分でパーサーを書けること
  • 不完全な実装、不正なデータ、奇妙な未定義動作が発生しやすい
  • JSONやYAMLにも似た問題がある
  • XMLはやや見た目が悪いが、最も堅牢なように思える

• CSVが好きな人は、企業環境でCSVインジェクション対策を求められたことがないのだろう

  • Web上には良い資料が少ない
  • 最高の資料は <a href="https://georgemauer.net/2017/10/07/csv-injection.html" rel="nofollow">これ</a>

• CSVが好きな理由はいろいろある

  • Cでプログラムを書いて、さまざまなものをCSVとして直接出力できる
  • ほぼあらゆるデータベースや一般的な「何か」からCSVへ簡単に変換できる単純なミドルウェアを書ける
  • CSVをExcelに入れて好きなことを何でもできる
  • iniファイルも好きだ。メモ帳で直接編集できる
  • ただし、一般的な概要/構造があればよいのにと思う

• 最近、Raspberry Piベースのソリューションを開発している

  • 最初の実装ではSQLiteデータベースを使ったが、電源サイクルの数日後に破損した
  • Parquetファイルも調べたが、append-onlyな作業には向いていない
  • IPCファイルにイベントを記録し、定期的にParquetファイルへ「フラッシュ」する方法を実装した
  • 動作して効率的ではあるが、きちんと実装するのは容易ではない
  • 一般的な開発者にとっては、CSV（またはJSONL）が依然として最良だ

• CSVのつまらない点は、急いで書かれたパーサーやシリアライザーが引用符の扱いで同じありきたりなミスを繰り返すこと

  • 長いあいだCSVを警戒していたが、Pythonを学び、優れたcsv標準ライブラリモジュールを使うようになって考えが変わった

• もしこれが本当にラブレターなら、CSV形式で書かれていただろう

• JSONへの反論はそれほど説得力がない

  • すべてのフィールドに名前を付け足す必要はない
  • CSVとJSONを比べると、JSONは少し大きいが、括弧は単純なものにも複雑なものにもなりうる能力を表している
  • CSVは単純なので、パース/エンコードライブラリを使わないことが多い
  • JSONパーサーは常に期待どおりの値を出力し、言語側ではおそらく非常に効率的なSIMDベースのパーサーを使っている
  • 標準化の問題もある。CSVファイルがカンマ、空白、セミコロン、パイプなどのどれを使うのか、CR、LF、CRLFのどれを使うのか、引用符をエスケープできるのかといった問題がある
  • JSONにはこうした問題がない
  • JSONには型がある。6つの型があるのは、ないより良い
  • JSONは完璧ではないが、一般的にはCSVより良い

• 現代的な形式が好きな者として、迷ったときはCSVやJSONLを使う

  • 主にプレーンテキストなので、grepで簡単に検索でき、ストリーミングも可能
  • 文書に挙げられている機能の多くはJSONLにも当てはまる
  • gzipやzstdでよく圧縮できる
  • 圧縮するとプレーンテキストの利点は一部失われるが、ripgrepは圧縮ファイルも検索できる
  • JSONLのもう1つの利点は、より小さなファイルへ簡単に分割できること