CSV 格式标准：掌握用于数据便携性的 RFC 4180 标准
逗号分隔值 (CSV) 是最古老且最常用的数据交换格式之一。然而，几十年来，它一直缺乏正式的定义，导致了“CSV 地狱”：在一个应用程序中创建的文件在另一个应用程序中无法正确打开。RFC 4180 的出现改变了这一现状，它是我们目前拥有的最接近官方 CSV 标准的规范。
什么是 RFC 4180？
RFC 4180（CSV 文件的通用格式和 MIME 类型）发布于 2005 年，旨在提供正式规范以提高互操作性。它定义了 CSV 文件的结构以及 text/csv MIME 类型。
许多开发者认为 CSV 只是“带逗号的文本”，但 RFC 4180 明确了处理复杂情况的规则，例如：
- 包含逗号的字段。
- 包含换行符的字段。
- 包含双引号的字段。
RFC 4180 的核心原理
1. 记录分隔
每条记录（行）应位于单独的一行，以换行符 (CRLF) 结尾。
字段1,字段2,字段3[CRLF]
2. 标题行
可选的标题行可以作为文件的第一行出现，其结构与数据记录相同。
3. 特殊字符处理
这是大多数实现失败的地方。RFC 4180 规定：
- 逗号: 如果字段包含逗号，则该字段 必须 用双引号括起来。
- 双引号: 如果字段包含双引号，则该字段 必须 用双引号括起来，并且字段内部的字面双引号必须通过在前面多加一个双引号来转义。
- 换行符: 如果字段包含 CRLF，则该字段 必须 用双引号括起来。
示例:
要表示值 He said, "Hello"，CSV 字段变为 "He said, ""Hello"""。
实际应用场景
将数据导出到 Excel
Microsoft Excel 以使用区域设置（例如在某些欧洲国家使用分号而不是逗号）而闻名。遵循 RFC 4180 可确保最大的兼容性，尽管某些版本的 Excel 可能仍需要“字节顺序标记”(BOM) 才能正确检测 UTF-8 编码。
数据迁移
在数据库之间（例如从 PostgreSQL 到 MySQL）迁移数据时，使用符合 RFC 4180 的 CSV 解析器可以防止包含标点符号或多行描述的文本字段发生数据损坏。
构建 API 导入器
如果您的应用程序接受 CSV 上传，您的解析器应严格遵守 RFC 4180，以正确处理“带引号的”字段，避免简单地按找到的第一个逗号进行拆分的常见错误。
CSV vs. JSON 数据交换对比
| 特性 | CSV (RFC 4180) | JSON |
|---|---|---|
| 可读性 | 对人类友好（表格化） | 对机器友好（嵌套） |
| 文件大小 | 极小 | 中等（元数据开销） |
| 结构 | 扁平（行/列） | 层级化（对象/数组） |
| 流处理 | 非常容易 | 较复杂 |
常见问题 FAQ
Q: 我可以在 RFC 4180 中使用分号 (;) 作为分隔符吗？
A: 不可以。根据定义，RFC 4180 使用逗号 (,)。使用分号是常见的区域变体，但不符合 RFC 4180 标准。
Q: 我该如何处理不同的字符编码？
A: RFC 4180 没有严格强制规定编码，但 UTF-8 是现代事实上的标准。使用 UTF-8 时，在文件开头添加 BOM 可以帮助旧版应用程序（如 Excel）识别编码。
Q: 逗号周围允许有空格吗？
A: RFC 4180 规定空格被视为字段的一部分，不应被忽略。field1, field2 在第二个字段的开头包含一个空格。
相关工具
- JSON 转 CSV 转换器 - 将结构化的 JSON 数据转换为符合 RFC 4180 的 CSV 文件。
- JSON 格式化 - 检查并校验您计划转换的 JSON 数据。
- Base64 编解码 - 有时 CSV 数据会通过电子邮件使用 Base64 编码进行传输。