比JSON好吗？
我想简要介绍一下各种数据序列化格式，并对它们进行比较。基本上，我们的目标是回答这个问题，“我们能找到比JSON更好的东西吗？”但是，请注意，我们查看这些内容是为了数据序列化，而不是为了配置文件或其他东西，因此这是判断这些内容的目标。
也就是说，结构的类型信息是在接收程序检查的单独文件(模式)中定义的，还是消息本身包含类型信息。这几乎就是静态类型编程语言和动态类型编程语言之间的区别。就像编程语言一样，这两种语言都有优缺点，它们中的任何一种都不总是比另一种更好。这样做的目的是将苹果与苹果进行比较，所以我们会注意到这些东西属于哪一类，但不会根据它们做出价值判断。还有模糊的边；许多自描述格式也可以有一个架构层。同样，我们不会真正比较工具质量；我们的目标是查看格式的内在属性。不过，他们周围的文化可能会被考虑在内。
这一点也很重要，不要与RPC协议混为一谈，尽管RPC协议中使用了其中许多内容。请记住，HTTP/REST接口通常只是一种RPC协议，无论是否以这种方式实现。
截至2020年10月的最新情况。不会尝试包括无数的小事，因为世界上只有那么多时间。
现在所有的东西都会拿来做比较。我们都知道JSON，我们都同意它已经足够好了，但是真的有点垃圾。
类别：人类可读的、自我描述的。(https://json-schema.org/是存在的，但似乎没有得到广泛使用。)。有一个RPC协议，但它似乎也很少使用，这可能更通用。
简单-易于读、写和理解…。至少对简单的事情来说是这样。不过，结果还是有很多人被抓到了。
类型系统非常垃圾-没有日期/时间，没有实型整数，没有实型结构，没有联合/元组/等等
倾向于不鼓励模式的“简单到不需要它”，直到它变得不那么简单。
没有标准化的表单域可以被重新排序、复制等。这使得散列它变得困难，必须读取整个消息才能开始验证它，等等。
太复杂了-出于某些该死的原因，他们将其打造成JSON的严格超集，而且没有人使用这种形式，所以这只是一堆徒劳。
不确定是否有人真正知道XML是如何发生的。我想这基本上是W3C的错吧？有些事情是可以的，但最终我不确定这是不是任何人真正想要使用的东西，这只会是过去的又一个错误。
类别：人类可读的、自我描述的、具有常见模式用法的。有RPC协议和许多其他复杂的东西。
又名Protocol Buffers，但这是一个相当愚蠢的名字。谷歌常用的、快速的在线序列化格式。
在谷歌的支持下，它将擅长谷歌看重的东西。
现在对版本化方案提供了一些支持，尽管这通常是一个很难解决的问题
在谷歌的支持下，它将擅长谷歌看重的东西。
类别：机器可读，模式定义。主要针对RPC设计，它内置于参考实现中。
用户：SandStorm.io、Cloudflare？、各种其他用户，但看起来并不多。
是由一位在谷歌致力于Protobuf的人制作的，所以它背后有很多经验。也就是说，这并不意味着这只猫总是正确的，但肯定有一些观点试图表达出来。
很多文档和概念都是相当低级的，您通常不需要它。
看起来比协议Buf更复杂-这可能是第三方实现较少的原因之一。
阿帕奇版本的Protobuf。有人真的用这个吗？显然，Facebook，因为他们发明了它，然后把它给了阿帕奇。还有其他人吗？
用户：基本上都是Facebook？Twitter和Airbnb显然也在使用它，所以显然它并不是不受欢迎。
感觉有点像谷歌对Capn Proto的回应，因为它有一些相同的设计目标--零拷贝序列化和更易于版本化的布局。
非常好的类型系统-有诸如fixnum、DateTime、BLOBS之类的东西。
比需要的要复杂一些，尽管这是为了紧凑和全面的类型。例如，在可能的情况下，数字被密集地打包成更少的比特。
另一个CBOR，或者更确切地说，CBOR就是从这个派生出来的。设计简单紧凑。有点像稍微降低的CBOR，实际上，它们的整数规范内容看起来几乎相同。
顾名思义，JSON的二进制分支。由MongoDB创建，作为其内部数据格式。
有趣但实际上不在序列化语言范围内的东西，或者在其他方面不相关的东西。
无效，它被设计为配置语言，而不是序列化格式。它基本上是一种尝试，试图使像windows.INI文件这样简单和普遍的东西成为一种实际的规范，而不是一种时尚。
类别：人类可读的，有点自我描述的，尽管通常您有一个特定的数据结构，您试图将其与之相适应。
生锈的物体符号。因为将Rust的ML-y类型系统硬塞到JSON中并不是很有趣。在这个目的上效果非常好，但在其他地方基本上没有尝试过。
类别：人类可读的，有点自我描述的，尽管通常您有一个特定的数据结构，您试图将其与之相适应。
包括主要是为了完整性。除了不能保证稳定性的单个特定实现之外，它不是标准化的，因此不打算用于通用用途。它的目的是作为一种用于Servo的快速而简单的RPC/IPC格式，而实际的格式基本上是该目标的实现细节。
用户：伺服，由内向的人编写的程序，他们不在乎能否相互交谈。(但事实证明，这是一个有用的利基市场，谁知道呢？)。
该特定库的特定版本以外的任何内容都是未定义的。不过，如果你不介意的话，那就太好了。
某个愚蠢的电信标准机构试图做协议稍后会做的事情。所讨论的标准机构与创造现实的任性幻觉的标准机构有关，该机构被称为OSI网络模型。
但实际上也有好的一面。如果它不是故意复杂和过度设计，它可能会相当不错。
用户：希望您看到的唯一位置是在LDAP和SSL证书中。
二进制和文本格式，以及将其放入几乎任何其他数据格式的方法。
包括的主要是歇斯底里的葡萄干。太阳微系统公司试图做Protobuf后来会做的事情。
基本上，当您是一名非常优秀的C程序员，并且希望通过网络传输结构化数据时，会发生什么情况。不过，就这一点而言，这是相当合理的。
除非你是20世纪90年代初的C程序，否则不一定能做很多事情。
Lisp代码是由什么组成的，一个来自更文明时代的优雅符号。与许多Lisp解决方案一样，它工作得非常好，直到您需要获得两个Lisp实现才能使用相同的东西。尽管至少从20世纪70年代开始尝试，但在Lisp之外一直没有成功地流行起来。
没有真正的通用规范，更不用说实现了。不过，EDN是一个相当不错的开端。
用户：任何类似Lisp的语言，主要的真实示例是Scheme、racket、Clojure和理论上的Common Lisp。
任何有Lisp解释器的人都会尝试用read来阅读它，尽管这已经被证明是一个糟糕的想法。
无论您使用哪种形式的S表达式，总会有人为他们的特定形式的Lisp不能加载Read而感到恼火。
这实际上有点有趣，因为很容易将每种格式作为对之前格式的反应进行跟踪。ASN.1、XDR和一个由更奇怪的东西组成的动物园早在当前的互联网时代之前就存在了。现代始于XML。XML有自己的悠久历史，但它形成了某种瓶颈。这是技术本体论的变化之一，就像大灭绝一样。人们真正关心的大多数事情都是在对XML的反应中形成的，所以这就是我要从这里开始的。
因此，最广为流传的事情的家谱是(对那些使用手机的人表示歉意)：
/--&>；CBORXML-(XML过于冗长)-+-&>；JSON--(JSON，但二进制且紧凑)--+->；msgpack|\->；YAML\-->；bson||\-(XML，但二进制)-+--&>；Protobuf--(协议，但速度更快)-+-->；Cap&39；n协议\->；平缓冲器。
因此，当您实际查看此列表时，有一件事非常突出：实际上并没有JSON的替代品。在“人类可读”专栏里，没有什么比这更好的了。哦，已经有很多人试过了，比如：
…。但其中似乎没有几个是最新的，更不用说广泛使用了。JSON5可能是最接近的，因为它最接近它的前身。不过，这似乎是一个创新的成熟领域。
也就是说，除非实际被多个组织使用，否则请停止建议更多内容
