各种数据序列化格式进行比较。基本上，是回答以下问题：“能找到比JSON更好的东西吗？”。 这里找的是用于数据序列化的语言，而不是配置文件。
有两个轴线来比较各种语言：
- 自描述与模式定义的格式
- 可读格式与机器可读格式
即，是否在接收程序检查的单独文件（架构）中定义了结构的类型信息，或者消息本身是否包含类型信息。这有点类似于静态和动态类型的编程语言之间的差异。像编程语言一样，两者都有优点和缺点，但两者都不总是比对方好。这里不会真正比较工具的高低。目的是查看格式的内在特性。
不要与RPC协议混淆，尽管其中许多东西都在RPC协议中使用。无论是否以这种方式实现，HTTP / REST接口通常只是一种RPC协议。
人类可读的语言
JSON格式
http://json.org/
我们都知道JSON，都同意它足够好。
类别：易于理解，自我描述。尽管用于RPC协议的描述词汇表存在（https://json-schema.org/），但是似乎很少使用。
用户：每个人
优点：
- 与主要的编程语言相似–易于理解和调试
- 简单–易于阅读，编写和理解。
缺点：
- 类型很少-没有日期/时间，没有实数，没有结构体，没有联合/元组/等
- 没有规范化的形式，字段可能会重新排序，重复等。这使hash变得困难，必须阅读整个消息才能开始对其进行验证，等等。
- 没有好的方法来包含二进制数据
YAML
https://yaml.org/
最初是XML的一种更简单的替代品。
类别：易于理解，自我描述。
用户：很多人
优点：
- 基本形式的阅读和写作非常简单
- 视觉上简洁
缺点：
- 太复杂了–为JSON的严格超集，并且没有人使用该形式
- 多种语言实现彼此不同
XML格式
https://zh.wikipedia.org/wiki/XML
W3C的标准。
类别：人类可读的，具有常见模式用法的自我描述。具有RPC协议和许多其他复杂的东西。
用户：每个无法避免的人。
优点：
- 用于配置架构和验证
- 简单易用
- 实际上对于写文档来说还不错
缺点：
- 一切都是字符串输入
- 没有实际的数组
- 复杂化，很冗长
- 大概有3-4种不同的方式来完成每一件事
- 仍然不是包含二进制数据的好方法
机器可读语言
protocol-buffers
https://developers.google.com/protocol-buffers/
a.k.a协议buffer，但这是一个很别扭的名字。Google的常用快速在线序列化格式。
类别：机器可读的，模式定义的。有围绕它构建的RPC协议。
用户： Google，基本上每个人
优点：
- 在Google的支持下，它将很好地发挥Google的价值
- 基本上合理不错
- 现在对版本控制架构提供了一些支持
缺点：
- 在Google的支持下，它将很好地发挥Google的价值
- 不是特别简单
- 可能还有改进的空间
- 它的类型系统可能会更好
Cap'n Proto
https://capnproto.org/
其他二进制序列化协议。
类别：机器可读的，模式定义的。主要是为RPC设计的。
用户： sandstorm.io，Cloudflare ?其他各种人，但似乎人数不多
优点：
- 设计快
- 由Google致力于Protobuf的人之一制作，因此背后有很多经验。就是说，这并不意味着这永远都是对的，但肯定有试图表达的观点。
- 精致的RPC是标准包的一部分
- 专为零拷贝反序列化而设计
- 专为架构而设计
- 可爱的名字
- 非常明确地说明正确性和一致性，例如字段排序和布局
缺点：
- 非常明确地说明正确性和一致性，例如字段排序和布局
- 许多文档和概念都很底层，你通常不需要它
- 似乎比protobuf更复杂-这可能是第三方实现较少的原因之一
thrift
https://thrift.apache.org/
Apache的Protobuf版本。有人实际使用吗？显然，Facebook是因为他们发明了它，然后将其提供给了Apache。还有谁？
类别：机器可读的，模式定义的。主要为RPC设计。
用户：基本上主要是Facebook？Twitter和AirBNB显然也使用它，也不是不受欢迎。
优点：
- 有用？
缺点：
- 文档很烂
- Apache的开源项目的悲剧
- 显然仍然不如flatbuffers
flatbuffers
https://google.github.io/flatbuffers/
感觉有点像Google的Cap'n Proto，因为它具有一些相同的设计目标-零副本序列化和布局更适合版本控制。
类别：机器可读的，模式定义的。包括RPC协议。
用户： Google，Cocos2D，Facebook的移动客户端
优点：
- 专为零拷贝反序列化而设计
- 专为架构而设计
缺点：
- 相同问题已经由Capnp解决
- 出于某种原因包括JSON解析器？
- 类型系统对于实际应用来说有点贫乏
CBOR
https://cbor.io/
基本上是对JSON的二进制重新构想。
类别：机器可读的，自我描述的。
用户： ???
优点：
- 相当不错的类型系统–诸如fixnum，datetime，blob等
- 紧凑
- 内置可扩展性
- 旨在替代JSON
- IETF标准
缺点：
- 尽管出于紧凑性和综合类型的考虑，但它比它需要的复杂得多。例如，在可能的情况下，将数字密集地打包为更少的位。
- 出于某种原因，实际上似乎没有被广泛采用吗？
msgpack
https://msgpack.org/
CBOR是从msgpack派生的。设计简单紧凑。
类别：机器可读的，自我描述的。
用户： Redis，还有其他几个吗？
优点：
- 简单
- 紧凑
缺点：
- 规格有点弱
- 没有真正的元组或枚举类型
- 为什么不只是CBOR？
BSON
http://bsonspec.org/
顾名思义，JSON的二进制形式。由MongoDB创建为其内部数据格式。
类别：机器可读的，自我描述的。
用户： MongoDB
优点：
- 类型系统充满了MongoDB特定的类型，但是相当实用
缺点：
- 类型系统相当实用，但是充满了不赞成使用的，以及MongoDB特定的东西
- C字符串–尽管也有随机的非C字符串。
- 它的数组是反对序列化的怪胎
- 基本上是MongoDB的实现细节，看起来像这样
其他
有趣但实际上不在序列化语言范围之内的语言。
toml
https://github.com/toml-lang/toml
它被设计为配置语言，而不是序列化格式。从根本上讲，这是一种使像Windows .INI文件那样简单和普遍存在的尝试，而这实际上是一种规范，而不是一种流行语言。
类别：易于理解的分类，虽然通常要尝试使用特定的数据结构，但它还是可以自我描述的。
用户：各种，尤其是cargo（Rust的构建工具）
优点：
- 在没有深度嵌套结构的情况下，可以很好地用作配置语言
缺点：
- 尝试制作深度嵌套的结构时效果不佳
ron
https://github.com/ron-rs/ron
Rust的对象符号。因为将Rust的ML-y类型系统导入JSON并不是一件很有趣的事情。为此目的，其效果惊人，但基本上在其他地方都没有尝试过。
类别：易于理解的分类，虽然通常要尝试使用特定的数据结构，但它还是可以自我描述的。
用户：少数，尤其是Amethyst.rs
优点：
- 适用于复杂的功能样式语言的良好类型系统
- 简单合理紧凑
- 实际上非常擅长
缺点：
- 年轻，规格不足，以Rust为中心
bincode
https://github.com/servo/bincode
主要包括完整性。它不是在不能保证稳定性的单个特定实现之外进行标准化的，因此不适用于通用用途。它旨在用作Servo的快速简便的RPC / IPC格式，而实际格式基本上是该目标的实现细节。
用户：服务器，是由内向的人编写的程序，他们并不关心彼此之间的交谈。
优点：
- 紧凑，快速，简单。
- 具有Rust代码的IPC基本透明地工作。
缺点：
- 除了该特定库的特定版本以外，没有其他定义。
ASN.1
https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
一些愚蠢的电信标准组织试图做protobuf以后会做的事情。问题的标准机构与创造了一种故意的现实幻觉的机构-OSI网络模型有关。
类别：机器可读的，模式定义的。
用户：LDAP和SSL证书。
优点：
- 强大而精确的字体系统
- 到处都有模式
- 二进制和文本形式，以及将其转换为几乎任何其他数据格式的方法
缺点：
- 大约有十亿种数据变体格式
- 超级冗长
- 实际使用起来太复杂了，更不用说实现了
XDR
https://tools.ietf.org/html/rfc4506
Sun Microsystems尝试做protobuf以后会做的事情。
基本上，一个非常出色的C编码器并想要通过网络传输结构化数据时，会想到的事情。
类别：机器可读的，模式定义的。
用户：仍在某些地方使用，例如ZFS，NFS等
优点：
- 相当不错
缺点：
- 除非您是1990年代初的C程序，否则不一定做得太多
S-Expressions
Lisp代码是由什么组成的，是从更文明的时代开始的一种优雅的表示法。像许多Lisp解决方案一样，它非常有效，直到需要使两个Lisp实现使用同一类东西为止。至少从1970年代开始，就一直没有尝试过在Lisp之外流行。
没有实际的通用规范，更不用说实现了。EDN是一个不错的开始。
类别：易于理解，自我描述
用户：任何类似Lisp的语言，主要的“实际例子”是Scheme，Racket，Clojure和理论上常见的Lisp。
优点：
- 轻快的人会喜欢它，非轻快的人会讨厌它。
- 合理简单好看
缺点：
- 轻快的人会喜欢它，非轻快的人会讨厌它。
- 对于列表以外的复合数据类型，实际上没有公认的语法。
- READ尽管已经被证明是一个糟糕的主意，但任何使用Lisp解释器的人都会尝试使用它进行阅读。
- 无论您使用哪种形式的S表达式，都会在某处使人烦恼，因为他们特定的Lisp形式无法使用加载它READ。
- 人们将尝试在其中编写Lisp代码。
结论
够好了：
- JSON？
- Protobuffer
- Cap'n Proto
- Flatbuffers
- CBOR
- msgpack
避免：
- YAML
- XML格式
- Thrift?
- BSON
XML的变革
这实际上是一个有趣的原因，因为很容易跟踪每种格式，ASN.1，XDR和都早于当前的互联网时代。现代始于XML。XML有很长的一段历史，但是却形成了一个瓶颈。人们实际上关心的大多数事物都是对XML的响应，因此这就是开始的地方。最广泛使用的事物的家谱将是：
JSON的替代品
因此，当实际查看此列表时，实际上并没有JSON的替代品。没有比“人类可读”列更好的了。哦，有很多尝试过的方法，例如：
- JSON5（https://json5.org/）
- STOB（http://igagis.github.io/stob/）
- ENO（https://eno-lang.org/）
- AXON（https://intellimath.bitbucket.io/axon/）
- BRE（https://baremessages.org/）
…但是这些几乎没有更新最新版本，更不用说广泛使用了。由于JSON5最接近其前身，因此它可能最接近。
