CSV 转 JSON
最后更新：2026年10月1日
把一张 CSV 表读回 JSON 对象数组。表头行给出键，读取时能理解 RFC 4180 的引号规则，类型识别由你决定是否开启——全部在浏览器中完成，表格不会离开本机。
这个转换做了什么
CSV 把列名放在第一行，所以转换是直接的映射：表头单元格成为属性名，其后的每一行成为数组里的一个对象。表格
id,name
1,Ada
2,Grace会变成 [{"id":"1","name":"Ada"},{"id":"2","name":"Grace"}]。注意这些值都是字符串——这是默认行为，下一节会解释原因。
表头行就是结构定义
第一行被当作表头，而不是数据。有两种边界情况会被处理，而不是留给你去踩坑：
- 名字重复——重复的表头会被改成唯一，因此
a,a会变成a和a_2。没有这一步，第二列会悄悄覆盖第一列。 - 名字为空——空的表头单元格按位置命名，
column 1、column 2，依次类推，这样就不会有键是空字符串。
类型识别默认关闭——这是有意为之
CSV 没有类型。每个单元格都是文本，文件本身也无法区分一个数字和一个恰好是数字的编码。所以识别默认关闭：关掉时，所有值都保持字符串，这是对文件的忠实解读。
打开后，只转换没有歧义的值。当一个值能写成 JSON 数字时——可选的负号、数字、可选的小数部分和可选的指数——才当作数字；true、false、null 会被识别为它们本身。关键在于，带前导零的值不会被转换，因为 007 和 02139 几乎总是标识符：邮编、电话号码、账号、商品 SKU。笼统地“变成一个数字”会把 007 悄悄变成 7 并损坏数据，而这条规则不会。
带引号的字段、内嵌逗号与换行
读取遵循 RFC 4180，也就是 JSON 转 CSV 页面写出时所遵循的同一套规则。用双引号包起来的字段可以包含分隔符、换行，或成对的双引号（读回时变成一个）。所以 "Ada, Countess" 是一个含逗号的单值，跨两行的值仍是一个单元格。CRLF 和 LF 两种行尾都接受；开头的 UTF-8 字节顺序标记——Excel 和某些导出工具添加的不可见 U+FEFF——会被去掉，因此第一个列名不会变成 id。
不规则的行
手工编辑的文件很少是整齐的矩形。字段比表头少的行会用空值补齐，字段比表头多的行会被截断，因此每个对象的键都相同。另一种做法——拒绝整个文件——不如返回那些格式良好的行有用，但这确实意味着缺失的值真的不在其中。
常见问题
CSV 是如何映射到 JSON 对象的？
第一行被读作表头，它的单元格成为属性名；其后的每一行成为数组里的一个对象，以这些名字为键。表头为 id,name、只有一行 1,Ada 的 CSV，会生成 [{ "id": "1", "name": "Ada" }]。
为什么我的数字和布尔值都变成了字符串？
类型识别默认关闭，这是有意为之。CSV 没有类型，所以转换器无法知道 007 是数字七还是编码零零七；猜错会悄悄损坏邮编、电话号码、账号这类标识符。当你确定某列是数值时再打开识别，而且即使打开，带前导零的值仍会保持为字符串。
开启识别后，什么才算数字？
只有能写成 JSON 数字的文本：可选的负号、不带前导零的数字（除非值正好是 0）、可选的小数部分，以及可选的指数。true、false、null 也会被识别。除此之外，包括 007 和 1,234 在内，都保持为字符串。
带引号的字段、内嵌逗号和换行如何读取？
解析遵循 RFC 4180：用双引号包起来的字段可以包含分隔符、换行，或成对的双引号（读回时变成一个）。所以内容为 Ada, Countess 的单元格写作 "Ada, Countess"，跨两行的值仍是一个字段。CRLF 和 LF 两种行尾都接受。
我的文件带 UTF-8 BOM，第一个列名会出问题吗？
不会。开头的字节顺序标记——某些工具（包括 Excel）会放在 CSV 开头的不可见 U+FEFF——会在解析前去掉，否则第一个表头会读成 id。这里会正确地读成 id。
与表头不匹配的行会怎样？
字段比表头少的行会用空值补齐，字段比表头多的行会被截断，因此每个对象的键都相同。手工编辑的文件里不规则的行很常见，这里选择容忍而不是报错，但缺失的数据确实不在输出中。
想要相反方向？JSON 转 CSV 可以把对象数组写成一张表。发现错误？联系我们。