CSV：没有人设计的格式
发布: (2026年4月2日 GMT+8 14:40)
4 分钟阅读
原文: Dev.to
Source: Dev.to
By Design — Episode 02
没有规范。没有模式。没有数据类型。没有标准编码。没有委员会。没有所有者。没有版本号。
1972 年，IBM 的 Fortran 编译器开始接受逗号分隔值作为输入。没有人写设计文档。没有人提出标准。有人需要把数据从一个地方搬到另一个地方，于是用逗号分隔，结果就能工作。这就是全部的规范。
三十三年后，Yakov Shafranovich 编写了 RFC 4180，将已经无处不在的东西形式化。格式的出现比标准化更快。
“CSV 不是一种真正的格式。没有类型，没有模式，没有校验。一个逗号放错位置，你的导入就会崩溃。一份来自德国的分号分隔文件就会让你的流水线炸掉。这就是文本文件里的业余时光。”
每个数据工程师都说过这句话。大多数人今天仍在这么说。
为什么没有设计
- 没有委员会 → 没有政治。
- 没有模式 → 没有版本冲突。
- 没有类型 → 地球上所有系统都能读取：数据库、电子表格、Shell、三十年前的主机。
grep 查找行。 awk 拆分列。 sort 排序。整个 Unix 工具链在不理解 CSV 是什么的情况下也能处理 CSV。
它只需要“在分隔符处拆分”这一解析器。它只需要“第一行可能是标题”这一共识。它不需要依赖、不需要库、不需要运行时。
痛点
- 编码混乱。
- 分隔符冲突。
- 没有统一的转义标准。
一个被引号包裹且内部包含逗号的字段，在以逗号分隔的文件中会导致不处理引号的系统崩溃。这些边缘情况是脆弱性的来源；每一次意外几乎都会在星期五下午出现。
采用情况
- 60 % 的企业在系统之间的数据交换中使用 CSV。
- 每个电子表格应用、数据库导出、CRM、ERP 和会计工具都能生成 CSV。
RFC 4180 于 2005 年发布，届时已有数十亿个 CSV 文件存在。
竞争者
- XML 试图取代它：太冗长。
- JSON 试图取代它：没有表格结构。
- Parquet 试图取代它：需要运行时。
- Avro 试图取代它：需要模式注册中心。
CSV 能够存活下来，因为它只需要一个文本编辑器和数逗号的能力。
治理的悖论
不需要达成一致的格式永远会胜过需要共识的格式。CSV 没有治理、没有权威、没有设计文档。这不是缺陷，而是它能够超越所有试图取代它的格式的原因。
没有人设计 CSV。五十三年后，所有人都在使用它。