CSV 与 JSON：区别、权衡以及何时使用每种格式

Scrapeless Scraping API可以以JSON或CSV格式返回结构化的网络数据，让每个工作流在嵌套应用数据和扁平表格交付之间进行选择。

CSV和JSON之间的主要区别是什么？

CSV 以行和列的形式表示数据。JSON 以值的形式表示，这些值排列在对象和数组中。CSV 文件本质上是一个表，而 JSON 文档可以建模一个表、一棵树、一组异构记录或一个深度嵌套的响应。

常见的CSV基线在 RFC 4180 定义记录、字段、可选头部、引号以及 text/csv 媒体类型。 RFC 8259 定义了 JSON 通过对象、数组和标量值。两个规范都未提供数据集的完整业务架构，但 JSON 在有效载荷中携带了更多的结构和类型信息。

订单列表说明了差异。在CSV中，每个订单需要相同的可见列，而重复的行项目通常需要另一个表或平展约定。在JSON中，每个订单都可以包含一个 customer 对象和一个 items 数组直接。

CSV和JSON示例

CSV版本

order_id,country,total,currency
O-701,US,84.50,USD
O-702,JP,9100,JPY

这个文件很容易以表格形式打开。它没有说明是否 total 是小数，无论 order_id 必须保持文本，或者一个空国是否未知或故意留空。这些规则存在于CSV语法之外。

JSON 版本

[
  {
    "order_id": "O-701",
    "country": "US",
    "total": { "amount": 84.50, "currency": "USD" },
    "items": [
      { "sku": "L-14", "quantity": 2 }
    ]
  }
]

JSON 负载将金额和货币分组，并将行项目附加到订单中。将其转换为一个 CSV 表格需要做出一个决定：对每个项目重复订单列、在单元格中放置序列化的 JSON、创建单独的订单和项目文件，或丢弃项目细节。这是一个建模选择，而不是格式细节。

CSV vs JSON 比较表

数据类型和空值

JSON 区分数字 42，字符串 "42"，布尔值 true、以及 null这种基本的类型减少了歧义性，但并没有定义领域类型，如日期、十进制货币、UUID或任意精度整数。仍然需要 JSON 架构或应用程序合同来定义这些。

CSV 解析器通常返回字段文本。接收模式决定是否 42 变成一个整数、十进制、标识符或字符串。自动推断可能会损害数据：一个长标识符可能会失去精度，一个邮政编码可能会丢失前导零，特定区域的日期可能会被错误解释。

空值处理需要特别注意。在 JSON 中，缺失的属性和设置为 null 的属性是不同的。在 CSV 中，空字段可能意味着 null、空字符串、不适用或不可用。一些生产者使用哨兵文本，但该值可能与真实内容冲突。CSV 合同应该明确定义 null。

文件大小和处理成本

CSV 通常需要更少的未压缩字节用于常规表格，因为标题只出现一次。JSON 对象数组在每条记录中重复属性名称。JSON 数组的数组可以减少这种开销，但它牺牲了自描述字段名称，并且在很大程度上依赖于位置意义，类似于 CSV。

压缩会改变比较。重复的 JSON 属性名称压缩效果良好，因此压缩后的大小可能比原始文件所示的更接近。解析成本也因库、语言、引用复杂性、数字转换、模式验证以及程序是否构建完整的内存表示而有所不同。

不要选择通用的速度声明。创建具有代表性的文件，包含真实的字符串和空模式，运行确切的解析器和验证逻辑，并测量重要的操作：上传时间、解析延迟、峰值内存、行吞吐量或分析扫描成本。

模式和合同管理

两种格式都受益于显式模式。 JSON Schema 核心规范 定义了一种用于描述和验证 JSON 实例的词汇。CSV 合同可以使用侧车模式、数据目录或声明列名、类型、约束和关系的表格元数据。

架构演化看起来不同。JSON 消费者通常可以忽略新添加的属性，只要他们的验证器允许。CSV 消费者可能会按位置映射，当插入一列时可能会中断。通过稳定的标题名称映射 CSV 更安全，但重命名或重复的标题依然是破坏性变化。

生产者应发布兼容性规则。说明新字段是否可以出现，字段顺序是否重要，未知字段如何处理，以及消费者是否必须保留他们不理解的信息。当语义发生变化时对合同进行版本控制，而不仅仅是当语法发生变化时。

当CSV是更好的选择

• 数据是一个常规表格。 每条记录都有相同的列，并且关系不需要嵌套。
• 收件人在电子表格工作。 CSV 可以直接在熟悉的商业和分析工具中打开。
• 边界是一个关系批量加载。 数据库导入工具通常对分隔文件有成熟的支持。
• 紧凑型平面交换事项。 一个稳定的表可以避免重复的属性名称。
• 简单的命令行处理是有用的。 成熟的CSV-aware工具可以选择、过滤和转换行，而无需自定义API客户端。

CSV 仍然需要方言元数据、模式和安全的电子表格处理。仅仅因为文件看起来更简单，并不意味着它是一个好的选择。

当 JSON 是更好的选择

• 数据是层次性的。 嵌套对象和数组保留域结构而不扁平化。
• 消费者是应用程序代码。 大多数 web 框架将 JSON 解析为本地结构，几乎不需要翻译。
• 记录各异。 可选属性比移动 CSV 列或长串空字段更容易表示。
• 基本值类型很重要。 布尔值、数字、字符串和 null 在有效载荷中仍然是独特的。
• 接口是一个 HTTP API 或事件。 JSON 媒体类型和工具在客户端、网关、日志和模式系统中很常见。

将 JSON 转换为 CSV

首先选择表的粒度：一行代表什么？如果一个订单有很多项，决定这一行是代表一个订单还是一个项目。项粒度的表可以重复订单级别的值；订单粒度的表需要一个单独的项目表或必须省略项目细节。

接下来，定义嵌套路径如何成为列名，数组如何处理，以及缺失、null 和空值如何不同。固定模式中的列顺序和类型。不要仅从第一条记录中发现列，因为后面的记录可能包含可选属性。

最后，使用专用库应用 CSV 引号，并使用代表性的标点符号、Unicode、换行符和对电子表格敏感的值测试输出。如果扁平化失去了以后可能需要的层次结构，则保留原始 JSON。

将 CSV 转换为 JSON

CSV 到 JSON 转换需要类型规则。一个天真的转换器为每个字段生成字符串。一个更有用的转换器可以解析整数、小数、布尔值和 null，但推断绝不应更改标识符或货币精度。应用声明的模式，而不是从小样本中猜测。

标题名称通常会成为对象属性。重复或空白头必须被拒绝或按照文档化规则进行映射。如果多个 CSV 文件代表相关表，JSON 组合还需要连接键、基数规则和缺失相关记录的行为。

数据管道模式

安全性和可靠性检查

对文件大小、嵌套深度、记录长度、字段计数和字符串长度设置限制。拒绝格式不正确的 JSON 和格式不正确的 CSV 引号，并提供可操作的错误位置。保护日志不受控制字符影响，并避免将整个被拒绝的记录放入日志中，以免其中包含敏感数据。

导出到电子表格软件的 CSV 需要公式注入控制。呈现为 HTML 的 JSON 需要上下文输出编码。两种格式都不能使不受信任的内容安全。验证确认结构；授权和输出处理保护值的使用方式。

结论

CSV 和 JSON 解决数据交换的不同部分。CSV 是一个紧凑、易于接近的平面表格表示。JSON 直接表示应用程序值和嵌套关系。最强大的工作流并不强迫一种格式到处使用：它在软件需要时保持结构，在人们或关系工具需要时创建表，并记录可以改变意义的每个转换规则。