朋友不会让朋友导出成 CSV

原文 ↗ Hacker News 讨论 ↗

为什么 CSV 仍然占主导地位

  • 几乎通用支持：几乎所有商业工具、数据库和语言都可以导入/导出 CSV，而且通常不需要额外库。
  • 对非技术用户友好：人们都知道“导出/导入 CSV”和“用 Excel/Sheets 打开”；许多工作流、FOIA 回复和遗留系统都围绕它构建。
  • 对于小型或中型文件，便于肉眼查看和手工编辑。这对于调试集成和处理“单个损坏文件”事件至关重要。
  • 对于适度的数据规模（MB 到低 GB），性能通常已经足够好，尤其是压缩后。

CSV 的实际问题

  • 规范不足的“格式家族”：不同的分隔符（,、;、\t、|）、引用规则、是否包含表头、编码（UTF‑8 与旧编码）、小数分隔符、日期格式以及空值表示。
  • 现实中的文件经常违反 RFC 4180：引用不一致、转义错误、注释、行错位、字段内嵌套 CSV。对于“所有 CSV”的单一稳健解析器实际上是不可能的。
  • 区域设置和 Excel 问题：Excel 会根据区域设置更改分隔符，猜测类型，把 ID 转成数字/日期/科学计数法，去掉前导零，并且在保存时可能静默破坏数据。LibreOffice 常被认为更正常。
  • 编码和模式都在带外；使用者必须猜测类型和格式，导致微妙的错误。

关于“人类可读”的争论

  • 优点：人类可读性被视为一大优点。你可以在不写代码的情况下检查、对比并有针对性地修复数据。CSV 被认为是持久且面向未来的。
  • 缺点：人类可读性会鼓励临时、容易出错的生产者（“直接用逗号拼起来就行”），让互操作性变得更差。有些人认为二进制 + 好工具胜过文本 + 误用。

Parquet 和其他替代方案

  • Parquet 因数据流水线而受到赞赏：列式、类型化、感知模式、适合大数据集和部分读取；压缩效果好（与 csv.gz 相当）。
  • 批评点：规范更复杂，在某些语言/环境中的库支持零散或令人痛苦，版本差异多，不能直接在 Excel 中使用，也不适合逐行流式使用场景。
  • 其他建议格式：SQLite 文件、Arrow、Avro、Protobuf/Cap’n Proto、JSON/NDJSON、TSV、带模式的 XML、CSVY（CSV + YAML 元数据），以及使用专用分隔字符的“Unicode/ASCII 分隔值”。

CSV 何时合适，何时不合适

  • 普遍共识：
    • 面向外部利益相关方以及电子表格中的临时分析时，保留 CSV（或 XLSX）。
    • 对于内部、大规模或性能敏感、且你控制两端的流水线，考虑 Parquet/SQLite/Arrow 等。
  • 核心张力：CSV 在技术上脆弱，但在社会层面根深蒂固。许多人认为在大规模上替换它并不现实；也有人主张，至少不该再把它作为“严肃”的系统对系统集成默认格式。