除了json还有什么数据传输格式

除了JSON，还有这些主流数据传输格式！

在互联网技术飞速发展的今天,数据传输是连接前后端、服务与服务的“生命线”，提到数据传输格式，绝大多数开发者首先会想到JSON——它轻量、易读、与JavaScript无缝衔接，几乎成了现代Web开发的“默认选项”，但JSON并非“唯一解”，在不同的应用场景中，XML、Protocol Buffers、MessagePack、YAML、TOML等格式各显神通，有的追求极致性能，有的兼顾可读性与扩展性，有的则为特定领域优化，本文将带你全面了解这些“非JSON”数据传输格式，看看它们如何在不同场景中发挥作用。

XML：结构化数据的“老牌强者”

全称：eXtensible Markup Language（可扩展标记语言）
核心特点：标签化、树形结构、可扩展性强

XML是互联网早期的“数据传输霸主”，至今仍在金融、政务、企业级系统中广泛使用，它通过自定义标签描述数据，例如一个用户信息可能表示为：

<?xml version="1.0" encoding="UTF-8"?>
<user>
    <id>1001</id>
    <name>张三</name>
    <email>zhangsan@example.com</email>
    <orders>
        <order>
            <orderId>2024001</orderId>
            <amount>99.99</amount>
        </order>
    </orders>
</user>

优势：

• 可读性好：标签语义明确，人类可直接阅读理解；
• 扩展性强：支持自定义标签和属性，适合复杂层级结构；
• 跨平台兼容：不受编程语言限制，几乎所有系统都能解析。

劣势：

• 冗余度高（标签、闭合标签占用大量空间）；
• 解析复杂（需DOM/SAX等解析器，性能较差）；
• 数据体积大,不适合高并发、低带宽场景。

典型应用：

• Web服务（如早期的SOAP协议）；
• 配置文件（如Java的Spring框架XML配置）；
• 金融/政务系统（需严格数据结构定义的场景）。

Protocol Buffers（Protobuf）：高性能的“二进制利器”

全称：Protocol Buffers（Google开发）
核心特点：二进制格式、高效序列化、强类型定义

Protobuf是Google为解决数据传输性能问题设计的开源序列化框架,它通过.proto文件定义数据结构，再编译为多种语言的代码，最终生成紧凑的二进制数据，例如定义一个用户消息：

syntax = "proto3";
message User {
    int32 id = 1;
    string name = 2;
    string email = 3;
    repeated Order orders = 4; // repeated表示数组
}
message Order {
    int32 orderId = 1;
    double amount = 2;
}

序列化后的二进制数据比JSON节省60%-80%的空间，解析速度也快5-10倍。

优势：

• 极致性能：二进制格式体积小、解析快，适合高并发、低带宽场景；
• 强类型支持：通过.proto文件严格定义数据类型，避免运行时类型错误；
• 跨语言支持：支持Java、Python、Go、C++等多种语言。

劣势：

• 可读性差（二进制数据无法直接阅读，需工具解析）；
• 需预定义 schema（修改数据结构需重新编译代码）；
• 适合机器间通信,不适合人类直接编辑。

典型应用：

• 微服务间通信（如gRPC默认使用Protobuf）；
• 移动端数据传输（减少网络流量和电量消耗）；
• 大数据处理（如Hadoop、Spark的二进制数据交换）。

MessagePack：JSON的“极速二进制版”

核心特点：二进制格式、兼容JSON语法、即插即用

MessagePack被称为“MessagePack JSON”，它将JSON数据转换为紧凑的二进制格式，同时保持与JSON几乎相同的语法结构，例如JSON对象{"name": "李四", "age": 25}会被编码为二进制数据，但体积更小。

优势：

• 兼容JSON：可直接解析为JSON对象，无需额外学习成本；
• 高性能：二进制序列化/反序列化速度远快于JSON；
• 无需预定义schema：动态类型，适合灵活场景。

劣势：

• 可读性差（二进制数据无法直接查看）；
• 不适合复杂嵌套结构（二进制格式调试困难）；
• 生态不如JSON/Protobuf完善。

典型应用：

• Web实时通信（如WebSocket传输二进制数据）；
• 缓存系统（如Redis存储MessagePack编码的数据）；
• 嵌入式设备（资源受限场景下的高效数据交换）。

YAML：人类友好的“配置数据格式”

全称：YAML Ain't Markup Language（YAML不是标记语言）
核心特点：缩进式结构、可读性强、支持注释

YAML通过缩进（空格而非标签）表示层级关系，支持注释，常用于配置文件和数据交换，例如一个用户配置可能表示为：

user:
  id: 1002
  name: 王五
  email: wangwu@example.com
  orders:
    - orderId: 2024002
      amount: 149.99
    - orderId: 2024003
      amount: 79.99

优势：

• 可读性极佳：接近自然语言，适合人类编写和修改；
• 支持注释：可在文件中添加说明，便于维护；
• 支持复杂数据类型（如列表、字典、布尔值、日期等）。

劣势：

• 对缩进敏感（必须使用空格，且缩进层级不能混乱）；
• 解析速度较慢（依赖正则表达式，不适合高频数据传输）；
• 冗余度高于JSON（缩进和换行占用空间）。

典型应用：

• 配置文件（如Docker Compose、Kubernetes YAML配置）；
• 数据序列化（如Ansible playbook、CI/CD pipeline配置）；
• 文档数据（如Markdown前置元数据）。

TOML：简洁的“配置文件新贵”

全称：Tom's Obvious, Minimal Language（Tom的简洁语言）
核心特点：键值对结构、简洁直观、兼容INI格式

TOML由GitHub创始人Tom Preston-Werner设计，旨在解决YAML/JSON配置文件的复杂性，强调“简洁”和“易读”。

[user]
id = 1003
name = "赵六"
email = "zhaoliu@example.com"
[[orders]]
orderId = 2024004
amount = 199.99
[[orders]]
orderId = 2024005
amount = 129.99

优势：

• 极简语法：无缩进要求，键值对结构清晰；
• 易读易写：接近INI格式，学习成本低；
• 强类型支持（明确区分字符串、数字、布尔值等）。

劣势：

• 不适合复杂数据传输（主要面向配置文件）；
• 生态较小（解析库支持不如JSON/YAML广泛）；
• 不支持注释（部分实现支持，但非标准）。

典型应用：

• 项目配置文件（如Cargo.toml、pyproject.toml）；
• 开发工具配置（如VS Code settings、TOML格式的环境变量）；
• 轻量级数据交换（如小型应用的数据存储）。

其他特色数据传输格式

除了上述主流格式,还有一些针对特定场景的“小众但强大”的格式：

Avro：大数据领域的“动态序列化工具”

由Hadoop生态圈开发,支持动态类型和模式演进，常用于Kafka、HBase等大数据系统，适合需要灵活数据结构的场景。

CBOR：物联网的“紧凑二进制格式”

基于Concise Binary Object Representation，设计目标是比MessagePack更紧凑，支持二进制和文本模式，适合物联网设备（如传感器、嵌入式系统）的数据传输。

BSON：MongoDB的“二进制JSON”

Binary JSON是MongoDB的存储格式，在JSON基础上增加了二进制数据类型（如日期、二进制串），支持嵌套文档和数组，适合文档型数据库的数据交换。

如何选择？看场景说话！

没有“最好”的数据传输格式，只有“最适合”的格式，以下是选择建议：