结构化数据格式对照速查

1总览对照

先看四列：能不能写注释、是否显式声明类型、是否天然支持层级、以及典型用途。

2CSV：规范很少，坑很多

CSV 看起来最简单，实际上「简单」正是它的问题来源——很多细节没有唯一答案，各家工具的默认行为并不一致。RFC 4180 给出了一个参考定义。

分隔符与换行

标准用逗号分隔、CRLF 换行；但很多工具接受分号（欧洲区域）或制表符（即 TSV），解析时需先确认

引号规则

字段里含分隔符、引号或换行时必须用双引号包裹；字段内的双引号用两个双引号表示（""）

编码与 BOM

给 Excel 打开的中文 CSV 建议带 UTF-8 BOM，否则 Excel 会按本地编码解释而乱码

前导零与长数字

0755、13800138000 这类内容可能被 Excel 自动转成数字，前导零丢失、长数字变科学计数法。导出时应明确说明字段类型，或改用带引号的形式

首行表头

惯例是第一行为列名，但规范并未强制；对接时要确认

不要手工拼接

用字符串拼 CSV 几乎必然出错（引号、换行、分隔符）。使用标准的 CSV 库写入与解析

3JSON 与它的三条硬规则

JSON 的严格性正是它在接口场景胜出的原因。它的三条硬规则经常把从 JavaScript 对象字面量复制过来的内容判为非法。

不允许注释

JSON 里写 // 或 /* */ 都是非法语法。需要注释的场景应改用 JSON5、JSONC 或 YAML

不允许尾随逗号

{"a":1,} 非法。这在手写配置时是最高频的错误

不允许特殊数值

NaN、Infinity 在标准 JSON 中不合法，需要改成字符串或 null

键名必须双引号

{a: 1} 非法，必须是 {"a": 1}

数字类型不分家

JSON 只有一种数字类型，1 与 1.0 在解析后可能都变成同一个值；需要区分时用字符串

大整数精度

超过 2 的 53 次方的整数在 JavaScript 里会丢失精度，长 ID 建议用字符串传输

4YAML 与 TOML：给人类读的两种思路

两者都常用于配置，但取向完全不同：YAML 追求紧凑与表达力，TOML 追求无歧义。这一点决定了它们的风险差异。

YAML 的「挪威问题」很有名：因为挪威的国家代码在 YAML 1.1 的类型规则里与布尔值 `false` 冲突，一个本意是国家代码的 `NO` 会被解析成假值。写 YAML 时凡是不确定的字符串，加引号最保险。

5XML 与 JSONL 各自的位置

这两个格式常被误认为「过时」或「冷门」，实际上在特定场景里它们仍是首选。

XML 的优势在约束

配合 XSD 可以做严格的结构校验，命名空间能避免字段冲突，还有成熟的签名与加密规范。政务、金融、出版行业仍大量使用

XML 的代价在体积

标签成对出现，同样数据量下体积通常是 JSON 的数倍，且解析开销更大

JSONL 的优势在流式

每行一个独立完整的 JSON 对象，可以逐行读取、逐行处理，不需要把整个文件载入内存

JSONL 的典型场景

日志文件、大数据批量导入（许多数据库与分析工具支持直接读 JSONL）、模型训练数据

JSONL 的注意事项

文件整体不是合法 JSON，不能用 JSON.parse 直接解析；每行之间不能有半个对象；换行符必须规范

JSON 与 JSONL 的取舍

数据要整体交给一个接口就用 JSON 数组；要按行追加、按行处理就用 JSONL

6怎么选：三个判断问题

这份数据是给程序还是给人读的？

给程序读优先 JSON（通用、库最多）；给人读优先 YAML 或 TOML

需要注释吗？

需要持久保存的解释性说明 → YAML / TOML / INI；JSON 无法做到，只能另存文档

是表格还是树？

行列表格用 CSV / TSV；含嵌套结构用 JSON / YAML / TOML；需要严格校验的旧系统对接用 XML