CSV 转 JSON

读取 CSV 比看上去难，而 CSV 转 JSON 的所有困难都来自 CSV 这一侧。JSON 有一份规范和一种含义。CSV 有一套宽松的惯例和大量地区性差异，所以第一件工作是弄清眼前这个文件究竟是什么。

分隔符是第一个问题。逗号是这个格式的名字，而分号在欧洲的导出中极其常见，因为把逗号用作小数点的区域设置不可能同时用它来分隔字段。制表符分隔的文件在数据工作中很普遍。会猜测的转换器多半猜得对，而在猜错时能够覆盖它就很有价值，这种情况一眼可辨：每一行都变成了单独一个字段。

正确性存在于引号之中。含有分隔符的字段必须加引号，而加了引号的字段可以包含分隔符、换行和转义的引号。这正是为什么对任何含有地址或自由文本备注的文件来说，按逗号切分都是错的：朴素的切分会在字段中途断开，其后每一列都会错位。真正的解析器会跟踪引号状态，而这就是「在您的样本上能用」与「在这个文件上能用」之间的差别。

表头行决定了您的 JSON 键，所以它的质量就是输出的质量。重复的列名、空的表头单元格、前后带空格的名称，都会产生日后必须在代码里绕开的键。在转换之前把表头修好，比之后再修更值得。

类型是最能改变结果的决定。CSV 里一切都是文本，所以转换器必须决定「123」是变成数字 123 还是保持字符串，以及「true」是否变成布尔值。推断类型很方便，而标识正是这样丢掉前导零的，邮政编码正是这样变成整数的，一列大多是数字却偶尔含有一个短横的数据也正是这样带着混合类型到达的。全部保持为字符串不会丢失任何东西，并把决定权还给您，而对标识来说，这通常正是它该在的地方。

编码是最后一个陷阱。从电子表格导出的 CSV 可能是 UTF-8、带字节顺序标记的 UTF-8，或某种传统的地区编码，而弄错的症状就是带重音的字符变成一对毫不相干的符号。如果人名看起来乱掉了，问题出在编码而不是转换。

这一切都在您的浏览器中发生。文件在本地读取、在本地解析、JSON 在本地产出，而这很要紧，因为 CSV 常常就是一份客户名单、一份订单导出或一份薪资明细。