JSON 转 CSV

JSON 被设计用来表示任意嵌套的、树状的数据——对象里套着对象,数组里套着对象,类型截然不同的值并排放在一起——而 CSV 只能表示一张扁平的、统一的表:行和列,每一行的列集合都相同,每一个单元格都是一个单纯的值。从第一种形状转换到第二种,必然意味着要做出决定,如何展平一个本来就不天然符合行列结构的东西,这正是这类转换里大部分实际复杂性所在的地方——不在于读取 JSON 语法本身,那很直接——而在于要决定,对于一份从一开始就不是表格化的数据来说,一行电子表格到底应该意味着什么。

像 `{"user": {"name": "Ada", "id": 42}}` 这样的嵌套对象,在一张扁平的表里没有唯一明显该对应的列,所以它会展开成两个独立的列——`user.name` 和 `user.id`——用点号记法精确保留每个值在原始结构里的来源。这是一个被广泛认可的惯例,原因正是它是可逆的:一个名为 `user.name` 的列毫无歧义地描述了一条回到嵌套结构的路径,这一点在这个 CSV 需要被转换回 JSON、或者导入一个能理解带点号路径就是嵌套字段的系统时很重要。

嵌套数组的处理方式则不同,而且是刻意如此:与其把一个数组展开成额外的行——这会导致表格的行数,随着某一条记录里恰好嵌套了多少个项目而变化,这是一个真正令人意外、通常也不受欢迎的副作用——一个数组值会被序列化成 JSON 文本,放进单个单元格里。行数保持可预测,精确匹配输入记录的数量,这几乎总是把数据转换成电子表格的人真正想要的结果,代价是如果需要单独用到这个单元格里的内容,还需要再做一次解析。

真实的 API 响应和手工整理的 JSON,经常包含并非每个对象都有相同键的记录——一个在部分记录上存在、在其他记录上缺失的可选字段,或者一套随时间演变的模式,导致新旧记录略有差异。CSV 无法直接表示这种差异,因为每一行都需要对齐到同一套固定的列;一个读取 CSV 文件的程序,没有办法知道某一行"缺少"了某一列,除非每一行都明确为它留了一个单元格。解决办法是计算所有记录中出现过的每一个键的并集,按每个键首次出现的顺序排列,并为任何缺少某个字段的记录填一个空单元格——这样整个文件的结构保持一致,不会悄悄丢掉任何记录的列,也不会把值错位到错误的列里。