JSON与CSV的区别：为表格与嵌套数据选择合适格式

导出文件时，经常会遇到要求在CSV和JSON之间选择的界面。如果只理解为CSV可以用Excel打开，而JSON是开发者使用的格式，就可能忽略导出后订单商品丢失，或会员编号前导0消失的原因。选择时不仅要考虑谁会打开文件，还要考虑数据具有怎样的结构。本文创建一份用于说明的小型订单数据，介绍从选择格式到转换后检查的完整方法。

1. 先看表格的一行与嵌套结构有何区别

CSV适合表达由行和字段组成的表格。例如，每行代表一名会员，各列分别为会员编号、姓名和注册日期，结构就比较简单。而如果一笔订单包含配送地址对象和多个商品项，则可以用JSON的对象与数组表达这些关系。JSON对象是一组名称与值的集合，数组则是按顺序排列的值列表。最好不要把数组的顺序与对象成员的显示顺序视为同一回事。

JSON包含字符串、数字、真与假、null、对象和数组。整个文档不一定必须以花括号开头。单个值或数组也可以构成JSON文档，但实际读取的程序是否只接受特定结构，需要另行核实。格式本身允许的语法与特定服务要求的输入规范并不相同。文件扩展名正确，并不能保证上传兼容性。

比较问题	CSV	JSON
基本结构	以行和字段为中心的表格	用对象与数组表达嵌套关系
值的类型	由读取工具和另外约定的规则解释	区分字符串、数字、布尔值、null等
包含多个商品的订单	展开为商品项行，或拆分成独立表格	以订单内部的商品项数组表示
人工检查时	便于在表格编辑工具中比较行与列	便于检查层次与值的类型
必须约定的内容	分隔符、编码、空值、列的含义	字段含义、必填值、重名处理方式

2. 用两种格式表示同一笔订单

以下数据是说明用示例，并非真实客户资料。订单编号是需要保留字符形式的标识符，而不是用于数字计算的数值，因此写成字符串。订单包含两个商品，所以商品项数组中有两个对象。未加入金额和支付信息。减少与说明格式差异无关的字段，有助于看清转换过程中哪些信息丢失了。

{
  "order_id": "0012",
  "customer": "김예시",
  "items": [
    {"sku": "A01", "quantity": 2},
    {"sku": "B02", "quantity": 1}
  ],
  "memo": null
}

将这一结构展开为一个CSV时，可以为每个商品项创建一行。订单编号和客户姓名虽然重复，但这种重复不等于订单重复，而是将一行的含义从“订单”改为“订单内的商品项”。如果统计订单数量时直接使用行数，就会将一笔订单算成两笔。转换前后，首先要规定什么算一条记录。

order_id,customer,sku,quantity
0012,김예시,A01,2
0012,김예시,B02,1

上面的CSV示例为了展示商品项结构，省略了memo，因此并非对整个JSON进行无损转换的结果。如果希望同时保留订单级备注和商品级信息，可以将订单表与商品项表分开。订单表中订单编号出现一次，商品项表中相同订单编号可出现多次。连接两张表的键就是订单编号。这只是本文提出的设计示例，并不意味着CSV会自动管理关系。如果交付两个文件，还应同时说明连接规则与缺失键的处理方式。

3. 正确处理CSV中的逗号与引号

RFC 4180是说明常见CSV表示方式的信息性文档，并不保证所有工具都会按完全相同的规则读取。文档介绍的方式是：对包含逗号、换行或双引号的字段使用双引号包围，字段内部的双引号则写两次。如果不了解该规则，只是用逗号简单拆分字符串，一格备注就可能被拆成两列。

id,memo
01,"회의, 자료 확인"
02,"그는 ""확인""이라고 적었다"

第一条备注中的逗号是备注内容，而非列分隔符。第二条备注中的连续双引号，在读入时表示内容中的一个双引号。被引号包围的字段还可以包含换行，因此文本文件的物理行数并不总等于数据记录数。请用CSV专用读取功能统计记录，将简单的行数统计作为辅助检查。

以分号或制表符分隔的文件也会作为表格数据传递，但需要在接收程序的选项界面中选择实际分隔符。如果全部内容都挤在第一列，可能不是数据缺失，而是分隔符解释不匹配。列数突然增加时，应检查引号处理或内容中的逗号。手动删除逗号之前，先复制并保存原始文件，能够使恢复更加容易。

4. 不要将看起来像数字的标识符改成数字

在订单编号示例中，0012是四位标识符。如果表格程序将它推断为数字12，显示或导出时前导0就可能消失。在JSON示例中，可以写成"0012"这样的字符串，明确其类型；而在CSV中，需要通过导入设置或另外提供的列规范，使该列按文本读取。不要以为CSV中的双引号就能阻止所有程序自动推断数字。

电话号码、邮政编码和商品代码也需要做同样判断。请区分这是用于求和、求平均的值，还是必须保持原样的标识符。如果看起来像日期的代码被自动转换为日期，应将该列指定为文本，并与原始值比较。如果前导0已经丢失，需要知道原始数据或长度规则才能恢复。随意补0，会导致难以区分原本长度不同的代码。

5. 区分空字符串、null与缺失字段

在JSON中，"memo": ""表示存在一个空字符串值，"memo": null表示存在null这个值。如果对象中根本没有memo成员，则是另一种状态。业务上可以将这三种状态用于相同含义，但格式不会自动规定它们含义相同。如果希望区分“没有内容”“尚未收集”和“不支持该字段”，应明确输入规则。

把CSV空白格转换为JSON时，如果全部填入null，原本希望表达空字符串的值就可能无法区分。反过来，将JSON的null改成字符串"null"，又会改变值的类型。转换前，请为每一列制定空值处理表。例如，备注空白按空字符串处理，尚未确定的数量作为错误处理，未选择的配送日期按null处理。这些规则需要由数据编写者与读取方共同约定。

6. 区分语法与结构，查找JSON错误

普通JSON语法使用双引号包围属性名称与字符串，不在最后一个成员后添加逗号。如果把带有注释的配置文件，或其他语言中使用单引号的对象表示直接称为JSON，可能导致读取错误。应先通过语法检查核实括号、引号和逗号，再检查必填字段与值的类型。即使语法正确，数量为负数或缺少订单编号的数据，也可能不符合业务规范。

请避免在对象中重复使用相同名称。 RFC 8259建议使用唯一名称，不同实现对重复名称的处理可能不同。如果数据中quantity出现两次，并依赖读取工具决定保留哪个值，转换结果就难以信赖。对于同类的多个值，应考虑数组或独立的商品项结构，而不是勉强创建不同名称。

7. 分步骤检查编码与转换结果

对于可互操作的JSON交换，使用UTF-8很重要。CSV还需核实打开文件的工具如何解释编码。韩文出现乱码时，不要急着重新输入数据，应先在导入界面核实原始编码。JSON语法错误与字符乱码可能是不同的问题。以正常读入的原始数据作为转换依据，不仅要比较人们能阅读的姓名，也要对照标识符中的字符。

如果将说明用订单展开为两行CSV，检查值应为“唯一订单编号数1、商品项数2、数量合计3”。重新合并为JSON时，应检查其中是否包含两个商品项。如果只凭行数相同就判断成功，可能会漏掉某个商品项被复制成另一个的错误。共同比较商品代码集合、标识符、合计与空值状态，更容易发现转换中丢失的信息。

交付文件时，请同时留下一个小示例以及列或字段说明。可以先记录字段名称、含义、值的类型、空值规则和每行的含义。即使改变数据格式，这些说明也应保留。在选择CSV转JSON工具之前，先规定哪些含义必须保留，就有了审查转换工具自动推断结果的标准。

8. 选择格式的最终检查清单

• 是否规定了每行代表什么单位？
• 一个项目中是否包含多个子项目？
• 是否区分了数字与标识符？
• 是否规定了空字符串、null和缺失字段的含义？
• 是否核实了CSV分隔符与引号规则？
• 是否核实了韩文编码？
• 是否比较了转换前后的项目数与唯一键？
• 是否核实了实际接收程序的输入规范？

如果由人检查和交换简单表格，CSV可能更方便；如果需要在交换中保留层次与值的类型，JSON可能更合适。没有哪种格式始终优越。共同确定数据关系、使用工具与交付规则，并确认转换后保留了相同含义，才是实际的选择标准。

官方来源与撰写依据

• IETF RFC 8259：JSON格式
• IETF RFC 4180：CSV格式与MIME类型

资料核查日期：2026-10-10。本说明由AI根据实际打开查阅的官方资料撰写。另行标注的计算、代码与检查案例仅用于说明，并非对用户环境直接进行测试或实际测量所得的结果。发布时会再次核实功能与资料是否发生变化。