CSV 转 JSON

表格是怎么被读出来的，以及直觉式解析会在哪里出错

读取器把文本看成由分隔符隔开的字段，以及由换行分隔的记录，字段可以用双引号包起来。在引号内部，两个连续的双引号表示一个引号，分隔符只是一个普通字符，换行结束的是字段而不是记录——所以一条两行的备注仍然是一个单元格，而先按换行切分的读法会把整个文件撕成两半。引号也只能包住整个字段，不能只包住字段的一部分；字段末尾的空格属于值本身，规范并不会替你裁掉。

分隔符之所以是一个设置项，是因为它并不总是逗号：使用小数逗号的国家习惯用分号，Excel 复制出来的是制表符分隔的文本。自动检测会找出在前几行里出现次数都相同的那个字符，这是真实表格留下的特征，而不是巧合；结果面板会明确说明最终用了哪一个分隔符。

在数据到达之前还有两件事要处理。Excel 在“CSV UTF-8”导出文件开头写入的字节顺序标记会被移除，否则它会悄悄成为第一个列名的一部分，之后按列名查找的代码全都找不到它。另外，以等号、加号、减号或 @ 开头的单元格，可能被表格软件当作公式执行，也就是 CSV 注入，所以这类单元格会保持为纯文本，并单独计数上报。行尾的 CRLF 与 LF、以及未闭合的引号，也都在读取阶段处理：前者按规范接受，后者不会让整页解析悄悄吞掉后面的内容。

表头、长度不齐的行，以及那些不该变成数字的值

有表头行时，第一行成为对象的键，后面每一行成为一个对象；没有表头时，每一行成为数组，结果按位置读取。与表头不一致的行不会消失：短行用空单元格补齐，长行被截断，表格因此保持矩形，同时报告这些行的数量和前几个行号，因为丢掉字段的行，正是导入之前最需要知道的事。

默认情况下每个单元格都输出为文本，这是安全的设置：一列电话号码、邮政编码、账号或版本号里，充满了看起来像数字、其实不是数字的值，把它们转成数字只会悄悄破坏数据。类型识别可以打开，即便如此仍有两类值保持文本——带前导零的值，以及超过十五位的值，后者无法在浏览器的固定精度数字里保持精度。

这也是 CSV 与 JSON 之间最本质的差别：CSV 不携带类型信息，数字、日期和长得像它们的一段文字，一旦写进文件就无法再区分；转到 JSON 时只能靠推断，而推断就意味着可能出错。同理，空单元格无法区分“缺失”“空字符串”和 null，往返一次之后这个区别就永久消失。表头重复时，后面同名的列会覆盖前面的键，这也是需要提前检查的地方。

表格没有说出口的那些事，以及它们的代价

格式本身不携带类型，所以日期、版本号和邮政编码进来时是文本，出去时还是文本——除非打开类型识别；即便打开，带前导零的值和超过十五位的值也原样保留。空单元格是更尖锐的例子：识别关闭时它输出为空字符串，识别打开时输出为 null，而文件从来没有说过你想要哪一个，所以往返一次也补不回一个从未被写下的区别。

两列同名是另一个不声不响的陷阱：后面的列占住这个键，前面的值就此消失，所以不唯一的表头会在没有报错的情况下丢数据。表头单元格还会被截到 120 个字符，因为它要变成 JSON 的键；没有名字的列则得到一个像 column_3 这样的位置名。字段末尾的空格属于值本身——格式不会替你裁掉——所以看起来是数字的一列，可能因为末尾多一个空格而保持文本。