🔄 从 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 智能家居协议