无论你是在配置Web应用程序、在服务之间交换数据、分析电子表格导出,还是读取API响应,你都会遇到以结构化文本格式存储的数据。最常见的四种是JSON、YAML、CSV和XML。
每种格式都是针对不同的目标设计的,选择正确的格式取决于你的使用场景。本文解释每种格式是什么、长什么样、何时使用,以及它们之间的比较。
JSON——JavaScript Object Notation
JSON已成为Web上主导的数据交换格式。尽管名字中有JavaScript,但它与语言无关,到处都在使用。
语法示例:
{
"name": "Alice Martin",
"age": 34,
"skills": ["Python", "SQL", "Docker"],
"address": {
"city": "Lyon",
"country": "France"
}
}
主要特点:
- 键值对,语法清晰易读
- 支持字符串、数字、布尔值、数组、对象和null
- 标准JSON不允许注释
- 严格语法——尾随逗号和单引号是错误
常见使用场景: REST API、配置文件(package.json、tsconfig.json)、NoSQL数据库(MongoDB)、前后端之间的数据交换。
小知识。 JSON的严格语法既是优势也是劣势。它使解析可靠且无歧义,但也意味着一个缺少的逗号或多余的尾随逗号就会破坏整个文件。
YAML——YAML Ain't Markup Language
YAML的设计目标是成为最易于人类阅读的数据序列化格式。它使用缩进代替括号,在配置文件中特别受欢迎。
语法示例:
name: Alice Martin
age: 34
skills:
- Python
- SQL
- Docker
address:
city: Lyon
country: France
主要特点:
- 基于缩进的结构(无括号或花括号)
- 用
#支持注释 - 支持JSON的所有数据类型以及更多(日期、多行字符串)
- 对空白敏感——缩进错误会破坏文件
常见使用场景: Docker Compose文件、Kubernetes清单、CI/CD流水线(GitHub Actions、GitLab CI)、Ansible剧本、Hugo/Jekyll配置。
YAML是JSON的超集,这意味着任何有效的JSON文档也是有效的YAML。但YAML的灵活性也是一把双刃剑——其隐式类型转换(例如yes被解释为布尔值true,或3.10变成3.1)已经导致了许多微妙的bug。
CSV——Comma-Separated Values
CSV是最简单的结构化数据格式。它将表格数据存储为纯文本,每行是一条记录,值之间用逗号(有时是分号、制表符或其他分隔符)分隔。
语法示例:
name,age,city,country
Alice Martin,34,Lyon,France
Bob Dupont,28,Paris,France
Carol Smith,41,London,UK
主要特点:
- 极其简单——只是带分隔符的文本
- 没有数据类型——所有东西都是字符串
- 没有标准方法来表示嵌套数据
- 没有官方通用标准(RFC 4180存在但未被普遍遵循)
- 文件大小非常小
常见使用场景: 电子表格导出、数据库导入/导出、数据分析(pandas、R)、简单数据交换、日志文件。
CSV的简单性是它最大的优势也是最大的局限。它非常适合平面表格数据,但无法表示层次结构。边缘情况(值中的逗号、多行字段、编码问题)使解析比最初看起来要复杂得多。
XML——Extensible Markup Language
XML在JSON接管之前是主导的数据交换格式。它使用类似HTML的标签语法,支持模式、命名空间和转换等复杂功能。
语法示例:
<?xml version="1.0" encoding="UTF-8"?>
<person>
<name>Alice Martin</name>
<age>34</age>
<skills>
<skill>Python</skill>
<skill>SQL</skill>
<skill>Docker</skill>
</skills>
<address>
<city>Lyon</city>
<country>France</country>
</address>
</person>
主要特点:
- 使用开始和结束标签的标签结构
- 支持属性、命名空间、模式(XSD)和转换(XSLT)
- 支持注释
- 与其他格式相比非常冗长
- 具有严格验证的非常完善的标准
常见使用场景: SOAP Web服务、企业集成、文档格式(DOCX、SVG、RSS)、Java/.NET生态系统中的配置文件、政府和金融数据交换。
XML比JSON或YAML更冗长,但其模式验证能力使其在数据完整性和系统间正式契约至关重要的场景中不可或缺。
并排比较
| 特性 | JSON | YAML | CSV | XML |
|---|---|---|---|---|
| 可读性 | 良好 | 优秀 | 良好(表格型) | 一般 |
| 冗长性 | 低 | 低 | 非常低 | 高 |
| 注释 | 不支持 | 支持 | 不支持 | 支持 |
| 嵌套数据 | 支持 | 支持 | 不支持 | 支持 |
| 数据类型 | 基础 | 丰富 | 无(全是字符串) | 通过模式 |
| 模式验证 | JSON Schema | 无标准 | 无 | XSD |
| 文件大小 | 小 | 小 | 最小 | 大 |
| 解析速度 | 快 | 中等 | 快 | 中等 |
| 主要领域 | Web API | DevOps配置 | 数据/电子表格 | 企业级 |
何时使用哪个
- 选择JSON:构建Web API、存储JavaScript/TypeScript项目的配置、或在服务间交换数据时。它是大多数现代应用的默认选择。
- 选择YAML:编写人类频繁阅读和编辑的配置文件时。它的可读性和注释支持使其非常适合DevOps和基础设施即代码。
- 选择CSV:处理表格数据、从电子表格或数据库导入/导出、或文件大小需要最小化时。不要用于层次化数据。
- 选择XML:在企业系统、SOAP API或需要正式模式验证的场景中。当你需要文档导向的标记(如SVG或RSS)时也适用。
格式间转换
这些格式之间的转换是常见任务。需要注意以下几点:
- JSON转YAML(及反向)通常是无损的,因为YAML是JSON的超集。
- CSV转JSON/YAML对平面数据效果好,但需要对嵌套输出的结构做出决策。
- XML转JSON可能会丢失信息(属性、命名空间、顺序),因为JSON没有对应的概念。
- 任何格式转CSV仅在数据是平面的或可以有意义地扁平化时才可行。
提示。 在格式间转换时,务必验证输出结果。自动转换可能会静默丢失数据,特别是在XML属性、YAML类型转换或CSV编码边缘情况方面。
深入了解
ToolK.io提供免费工具来在JSON、YAML、CSV和XML之间转换,格式化和验证你的数据,以及探索在项目中处理结构化数据的相关教程。
