CSV 转 JSON

CSV 看起来解析起来很简单——按逗号切分每一行,把第一行当作表头——直到实际数据里某个值本身就包含一个逗号,而这在真实的电子表格导出中屡见不鲜:一个像 "123 Main St, Apt 4" 这样的地址,一个像 "Smith, Jones & Co" 这样的公司名,或者一段包含列表的产品描述。CSV 规范,也就是 RFC 4180,通过允许一个字段被双引号包裹来处理这种情况,在引号内部,逗号、换行符,甚至字面意义上的引号字符(通过重复来转义)都只是数据,而不是结构。一个天真地对每个逗号都做切分、完全忽略引号的解析器,恰恰会破坏这些行——把 "Smith, Jones & Co" 切分成两个独立的列——而且它通常会悄无声息地这样做,没有任何错误提示能标记出问题,这正是这个 bug 危险、而不只是烦人的原因所在。

正确的、能感知引号的解析方式,会追踪读取过程当前是否处于一个带引号的字段内部,并在遇到闭合引号之前忽略分隔符和换行符,这是正确还原那些本来就合法包含了容易被误认为结构字符的字段的唯一方式。

一份原始 CSV 文件里的每一个值都是文本,因为 CSV 本身没有数字、布尔值或 null 的原生概念——一个包含 `42` 的单元格和一个包含 `hello` 的单元格,存储方式完全一样,都是字符。类型推断就是猜测哪些字符串"本来"是想表示数字、真/假值或 null,并相应地转换它们,让最终的 JSON 拥有真正带类型的值,而不是把所有内容都当作字符串裹在引号里。

不过这种猜测必须保持保守,因为很多看起来像数字的值根本不该被当作数字处理。一个带前导零的值——`007`、`042`——通常表示的是一个标识符或者一个位数固定的代码,这里的前导零本身就有意义,一旦转换成数字就会被悄悄抹掉,因为 `7` 和 `007` 是同一个数字,却是截然不同的标识符。一个像 `+44 20 7946 0958` 这样的电话号码看起来部分像数字,但并不是用来做算术的数据。超出 JavaScript 安全整数范围的值,一旦转换成数字就会丢失精度。这个工具刻意把所有这些都保留为字符串,正是因为在这里猜错了,就意味着以一种直到很久以后才容易被发现的方式,悄悄破坏了数据。

一个 JSON 对象不能有两个同名的键——后遇到的那个会直接覆盖前一个,悄无声息地丢弃掉整整一列的数据,不会在任何地方报错。电子表格导出文件产出重复表头的概率比想象中要高得多:一份报表里有两个统计范围不同的"合计"列,或者一份从两个来源合并的导出文件,恰好都用了"名称"这个表头。检测到重复并把第二次出现的表头重命名为 `name_2`,能保留每一列的数据,而不是悄悄丢失行对象里恰好先出现的那一个。空白表头出于同样的原因得到同样的处理,因为 JSON 没有办法把一个纯粹是空字符串的键,表示成一个有意义、可寻址的字段。