CSV 轉 JSON

CSV 把表格用「逗號分隔的文字列」來表示：第一列通常是欄位名稱，之後每一列都是一筆紀錄。JSON 用「物件陣列」來表示同一份表格：每個物件的鍵來自欄位名稱，每個物件的值來自當前這一列對應欄位上的單元格。把 CSV 轉 JSON，本質是同一份資料換了一種排佈方式——不增加資訊、不丟失資訊，只是從「行列」改成了「鍵值」。理解這一點之後，轉換中遇到的問題就更容易歸位：要麼是來源 CSV 的結構不穩，要麼是欄位語意需要在轉 JSON 之後再額外處理一次。

為什麼這個方向的轉換需求格外多

CSV 是电子表格、数据导出和老系统报表通用的语言；JSON 是 HTTP 接口、配置文件和 JavaScript 运行时通用的语言。两者之间最自然的桥梁，就是把人手里编辑出来的 CSV 翻译成程序更愿意消费的 JSON：设计师交付的商品清单、分析师从 BI 工具里导出来的问卷、邮件里收到的一次性批量改动，这些场景几乎都会落到“先 CSV，再 JSON”的链路上。

決定 JSON 輸出是否可信的幾條規則

转换后的 JSON 可不可信，更多取决于源 CSV 在“结构层面”是否稳定，而不是某个具体值对不对。下面这几条是最关键的几个判断点。

• 第一列確實是欄位名稱：不能有空白單元格、不能有重複欄位名稱、也不能是「看起來像資料的字串」被當成了表頭。
• 每一行的列数都与表头一致：多写一个逗号、漏掉一个尾部单元格，都会让后续列的值整体错位，而 JSON 看起来仍然“正常”。
• 分隔符明確且全域一致：逗號、分號、定位字元任選其一，但不能這一段用逗號、那一段用分號。
• 包含分隔符、引号或换行的值需要用引号包起来；引号内的引号要用两个引号转义。这两件事任何一件没做对，下游解析都会偏。
• 编码已知且统一：UTF-8（含或不含 BOM）是跨系统交付时最稳妥的默认；混用 GBK/Big5/Latin-1 时往往是“乱码爆雷”的源头。

上面這幾條只要有一條出問題，轉換工具仍然會產出「合法的 JSON」，但這份 JSON 不會是你期望的那份。所以在批量信任之前，一定要看一眼開頭幾筆和結尾幾筆，比對原始行列。

如何使用這個工具

1. 先在 CSV 轉 JSON 中准备一份有代表性的需要转成 JSON 供接口或工具使用的 CSV 行資料，不要一开始就處理最大或最敏感的真实内容。
2. 执行處理流程并產生保留原始行列結構的 JSON 数组结果后，優先檢查表头、分隔符、引号、空儲存格、列宽不一致，以及文字是保持字元串还是稍后再做類型處理，再判断结果是否真的可用。
3. 只有当结果已经適合用于接口 payload 草稿、配置匯入、表格清理和支持排查，并且不再触发這条风险提醒时，才複製或下载輸出：如果 CSV 源内容很乱，應该先做规范化，否则异常分隔符和带引号逗号会扭曲最終 JSON 結構。

CSV 轉 JSON 範例

這個 CSV 轉 JSON 示例使用有代表性的需要转成 JSON 供接口或工具使用的 CSV 行資料，展示產生后的保留原始行列結構的 JSON 数组结果，便于你先確認表头、分隔符、引号、空儲存格、列宽不一致，以及文字是保持字元串还是稍后再做類型處理，再把同样設定用于真实輸入。

範例輸入

name,email
Ada,ada@example.com

預期輸出

[
  {
    "name": "Ada",
    "email": "ada@example.com"
  }
]

一份小型 CSV 與對應的 JSON

# CSV
id,name,price,inStock
1,"Notebook, A5",4.50,true
2,"Pen ""Classic""",1.20,false
3,Mug,7.00,true

# JSON
[
  { "id": "1", "name": "Notebook, A5", "price": "4.50", "inStock": "true" },
  { "id": "2", "name": "Pen \"Classic\"", "price": "1.20", "inStock": "false" },
  { "id": "3", "name": "Mug", "price": "7.00", "inStock": "true" }
]

注意 JSON 輸出裡所有值都是字串。是否要把 "4.50" 轉成數字、把 "true" 轉成布林，是另一個獨立的決定——CSV 本身沒有型別系統，所以這件事必須由消費方按業務規則明確定義，而不是預設推斷。

什麼時候 CSV 轉 JSON 是正確選擇

这一步转换最划算的场景，是“数据的下一站”是程序而不是表格，并且 CSV 本身只是一次性的中转格式。

• 用產品/QA 維護的電子表格生成單元測試或整合測試的固定資料。
• 通过一个只接受 JSON 数组的接口做一次性数据导入，省去单独写 CSV 解析器的成本。
• 用导出报表给前端 mock 服务或静态配置文件做初始化数据。
• 更仔细地检查一份 CSV：在浏览器 DevTools 里浏览 JSON，比直接读一面墙的逗号分隔文本要顺手。
• 为前端原型准备数据文件：相比再引入一个 CSV 解析依赖，直接 `fetch().then(r => r.json())` 更轻量。

容易讓「順手轉一下」出事的邊界

“CSV 转 JSON 翻车”的现场，通常不是工具报错，而是“JSON 完全合法、但内容已经悄悄错了”。下面这些是最常见的起爆点。

• 帶換行符的欄位：標準 CSV 允許引號裡出現換行，但許多臨時寫的解析器只看 `\n`，結果一筆紀錄會被拆成多行 JSON。
• Excel 为了强制文本而加的前导单引号（例如 `'007123`）：它们会原样进入 JSON 字符串，下游代码再去做相等比较时会突然不命中。
• 用逗号作小数点的区域（例如 `3,14`）：在逗号分隔的 CSV 里会被错切成两列。从源头切到分号分隔，比让转换工具去猜要可靠得多。
• 没有约定格式的日期字符串（例如 `03/04/2024`）：在不同地区表示完全不同的日子。转 JSON 时不要在工具里“顺手归一化”，应该先转过来、再按业务约定显式解析。
• 表头里出现了分隔符或引号：会变成无法用普通点号访问的 JSON 键名，例如 `data['price, USD']`。最好在源头先重命名表头。
• 巨型 CSV：一次性塞进内存会爆掉浏览器或脚本进程，需要走流式或分块处理，否则“整段 JSON 数组都在内存里”这件事本身就是瓶颈。

CSV 與 JSON 在表達力上的差別

使用注意

• 複用保留原始行列結構的 JSON 数组结果前，先檢查表头、分隔符、引号、空儲存格、列宽不一致，以及文字是保持字元串还是稍后再做類型處理。
• 如果 CSV 源内容很乱，應该先做规范化，否则异常分隔符和带引号逗号会扭曲最終 JSON 結構。
• 当结果会影响生产工作或客户可见内容时，應保留原始需要转成 JSON 供接口或工具使用的 CSV 行資料以便回退和核对。

CSV 轉 JSON 參考說明

CSV 轉 JSON 的参考說明應始终围绕需要转成 JSON 供接口或工具使用的 CSV 行資料、產生的保留原始行列結構的 JSON 数组结果，以及用于接口 payload 草稿、配置匯入、表格清理和支持排查前必须確認的檢查点。

• 輸入重点：需要转成 JSON 供接口或工具使用的 CSV 行資料。
• 輸出重点：保留原始行列結構的 JSON 数组结果。
• 複核重点：表头、分隔符、引号、空儲存格、列宽不一致，以及文字是保持字元串还是稍后再做類型處理。

參考資料

• RFC 4180: Common Format and MIME Type for CSV Files
• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• ECMA-404: The JSON Data Interchange Syntax