🔄 从 XML 到 JSON,再到 CBOR:数据交换格式的演进之路
在软件工程中,数据交换格式 一直是系统通信、配置存储、网络传输的核心部分。过去几十年里,我们从笨重的 XML,迈入了简洁的 JSON,而如今,CBOR(Concise Binary Object Representation) 正在成为数据编码的新希望。
本文将带你回顾这一演变过程,并理解为什么 CBOR 是一个值得关注的未来选项。
🧾 一、XML:标准化的重量级选手
✅ 优点:
-
强结构化,适用于复杂文档结构
-
支持命名空间、schema 验证(XSD)
-
有广泛的标准和工具支持(如 SOAP、RSS)
❌ 缺点:
-
语法冗长,数据与标签比例严重失衡
-
可读性不佳,编写与解析繁琐
-
编码体积大,性能不佳,尤其在移动与嵌入式设备中
XML 曾主导 Web 服务和配置标准,但也因"太重"而逐渐失宠。
🔄 二、JSON:Web 时代的轻量希望
随着 Web 应用与 JavaScript 的兴起,JSON(JavaScript Object Notation)成为事实标准:
json
{ "name": "Alice", "age": 30, "skills": ["Go", "Rust", "Python"] }
✅ 优点:
-
简洁直观,易于阅读和编写
-
与 JavaScript 天然兼容
-
被绝大多数语言支持(标准库内置)
❌ 局限性:
-
无类型信息(无法区分整数与浮点、二进制 vs 字符串)
-
体积冗余(键名重复、结构符号重复)
-
只能表示基本类型(对象、数组、数字、布尔、字符串)
-
不适合高效传输与低功耗设备
JSON 的核心问题是它对人类友好,但对机器不够高效。
⚙️ 三、CBOR:为机器设计的 JSON 替代者
CBOR(RFC 8949)是一种二进制数据格式,旨在提供:
像 JSON 一样的语义,但更加紧凑、高效,并支持扩展类型。
💡 CBOR 的关键特性:
特性 | 描述 |
---|---|
✅ 二进制编码 | 更小的体积,更快的传输 |
✅ 支持完整类型系统 | 包括日期、浮点、二进制、标签类型、自定义扩展类型 |
✅ 自我描述 | 可以编码 tag、schema 信息 |
✅ 高效解析 | 适合低功耗设备(IoT)、嵌入式系统 |
✅ 和 JSON 可互转 | 支持 JSON roundtrip,兼容性良好 |
📦 示例对比
JSON 表达方式:
json
{ "temp": 23.5, "unit": "C", "timestamp": "2024-06-01T12:00:00Z" }
CBOR 二进制格式(表示相同数据):
A3 64 74 65 6D 70 FA 41 BC 00 00 64 75 6E 69 74 61 43 64 74 69 6D 65 73 74 61 6D 70 C0 78 19 32303234...
-
更短(节省带宽)
-
更快(减少解析成本)
-
可携带时间类型标识(如
tag 0
表示时间戳)
🔧 使用场景对比
应用场景 | 适合格式 |
---|---|
Web API、文档交换 | JSON(人类友好) |
IoT、传感器数据 | CBOR(紧凑高效) |
企业级服务互通(老系统) | XML(规范完备) |
区块链、消息队列、RPC | CBOR、MessagePack、Protobuf |
🧠 CBOR 与其他二进制格式的区别?
格式 | 特点 |
---|---|
CBOR | 面向 JSON 的二进制替代,标准化强,扩展性好 |
MessagePack | 类似 CBOR,但不支持 tag 与 schema |
Protobuf | 依赖 schema 文件,压缩率高但灵活性差 |
BSON | MongoDB 定制,体积大,携带元信息多 |
CBOR 适合需要无需 schema、跨语言兼容 的轻量级通信场景,是目前最具通用性的二进制 JSON 替代者。
🌉XML、JSON 和 CBOR 的比较概述

✅ 总结
XML 是为机器和协议设计的,
JSON 是为人类设计的,
CBOR 是为机器与人类之间的效率折中而设计的。
随着物联网、边缘计算和分布式通信的发展,CBOR 的使用正在不断增长。它已被广泛应用于:
-
CoAP 协议(IoT 领域)
-
DID 标准(去中心身份协议)
-
W3C Verifiable Credentials
-
Matter 智能家居协议