XML 与 JSON 优劣对比，TOML、CSON、YAML

简介

XML 和 JSON 是现今互联网中最常用的两种数据交换格式。XML 格式由 W3C 于 1996 年提出。JSON 格式由 Douglas Crockford 于 2002 年提出。虽然这两种格式的设计目标并不相同，但它们常常用于同一个任务，也就是数据交换中。XML 和 JSON 的文档都很完善（RFC 7159、RFC 4825），且都同时具有 人类可读性(human-readable)和 机器可读性(machine-readable)。这两种格式并没有哪一个比另一个更强，只是各自适用的领域不用。（LCTT 译注：W3C 是互联网联盟，制定了各种 Web 相关的标准，如 HTML、CSS 等。Douglas Crockford 除了制定了 JSON 格式，还致力于改进 JavaScript，开发了 JavaScript 相关工具 JSLint 和 JSMin）

XML 的优点

XML 与 JSON 相比有很多优点。二者间最大的不同在于 XML 可以通过在标签中添加属性这一简单的方法来存储 元数据(metadata)。而使用 JSON 时需要创建一个对象，把元数据当作对象的成员来存储。虽然二者都能达到存储元数据的目的，但在这一情况下 XML 往往是更好的选择，因为 JSON 的表达形式会让客户端程序开发人员误以为要将数据转换成一个对象。举个例子，如果你的 C++ 程序需要使用 JSON 格式发送一个附带元数据的整型数据，需要创建一个对象，用对象中的一个 名称/值对(name/value pair)来记录整型数据的值，再为每一个附带的属性添加一个名称/值对。接收到这个 JSON 的程序在读取后很可能把它当成一个对象，可事实并不是这样。虽然这是使用 JSON 传递元数据的一种变通方法，但他违背了 JSON 的核心理念：“ JSON 的结构与常规的程序语言中的结构相对应，而无需修改。(JSON’s structures look like conventional programming language structures. No restructuring is necessary.)”1

虽然稍后我会说这也是 XML 的一个缺点，但 XML 中对命名冲突、 前缀(prefix)的处理机制赋予了它 JSON 所不具备的能力。程序员们可以通过前缀来把统一名称给予两个不同的实体。2 当不同的实体在客户端中使用的名称相同时，这一特性会非常有用。

XML 的另一个优势在于大多数的浏览器可以把它以 具有高可读性和强组织性的方式(highly readable and organized way)展现给用户。XML 的树形结构让它易于结构化，浏览器也让用户可以自行展开或折叠树中的元素，这简直就是调试的福音。

XML 对比 JSON 有一个很重要的优势就是它可以记录 混合内容(mixed content)。例如在 XML 中处理包含结构化标记的字符串时，程序员们只要把带有标记的文本放在一个标签内就可以了。可因为 JSON 只包含数据，没有用于指明标签的简单方式，虽然可以使用处理元数据的解决方法，但这总有点滥用之嫌。

JSON 的优点

JSON 自身也有很多优点。其中最显而易见的一点就是 JSON 比 XML 简洁得多。因为 XML 中需要打开和关闭标签，而 JSON 使用名称/值对表示数据，使用简单的 { 和 } 来标记对象，[ 和 ] 来标记数组，, 来表示数据的分隔，: 表示名称和值的分隔。就算是使用 gzip 压缩，JSON 还是比 XML 要小，而且耗时更少。3 正如 Sumaray 和 Makki 在实验中指出的那样，JSON 在很多方面都比 XML 更具优势，得出同样结果的还有 Nurseitov、Paulson、Reynolds 和 Izurieta。首先，由于 JSON 文件天生的简洁性，与包含相同信息的 XML 相比，JSON 总是更小，这意味着更快的传输和处理速度。第二，在不考虑大小的情况下，两组研究 4 5 表明使用 JSON 执行序列化和反序列化的速度显著优于使用 XML。第三，后续的研究指出 JSON 的处理在 CPU 资源的使用上也优于 XML。研究人员发现 JSON 在总体上使用的资源更少，其中更多的 CPU 资源消耗在用户空间，系统空间消耗的 CPU 资源较少。这一实验是在 RedHat 的设备上进行的，RedHat 表示更倾向于在用户空间使用 CPU 资源。6 不出意外，Sumaray 和 Makki 在研究里还说明了在移动设备上 JSON 的性能也优于 XML。7 这是有道理的，因为 JSON 消耗的资源更少，而移动设备的性能也更弱。

JSON 的另一个优点在于其对对象和数组的表述和 宿主语言(host language)中的数据结构相对应，例如 对象(object)、 记录(record)、 结构体(struct)、 字典(dictionary)、 哈希表(hash table)、 键值列表(keyed list)还有 数组(array)、 向量(vector)、 列表(list)，以及对象组成的数组等等。8 虽然 XML 里也能表达这些数据结构，也只需调用一个函数就能完成解析，而往往需要更多的代码才能正确的完成 XML 的序列化和反序列化处理。而且 XML 对于人类来说不如 JSON 那么直观，XML 标准缺乏对象、数组的标签的明确定义。当结构化的标记可以替代嵌套的标签时，JSON 的优势极为突出。JSON 中的花括号和中括号则明确表示了数据的结构，当然这一优势也包含前文中的问题，在表示元数据时 JSON 不如 XML 准确。

虽然 XML 支持 命名空间(namespace)与 前缀(prefix)，但这不代表 JSON 没有处理命名冲突的能力。比起 XML 的前缀，它处理命名冲突的方式更简洁，在程序中的处理也更自然。在 JSON 里，每一个对象都在它自己的命名空间中，因此不同对象内的元素名称可以随意重复。在大多数编程语言中，不同的对象中的成员可以包含相同的名字，所以 JSON 根据对象进行名称区分的规则在处理时更加自然。

也许 JSON 比 XML 更优的部分是因为 JSON 是 JavaScript 的子集，所以在 JavaScript 代码中对它的解析或封装都非常的自然。虽然这看起来对 JavaScript 程序非常有用，而其他程序则不能直接从中获益，可实际上这一问题已经被很好的解决了。现在 JSON 的网站的列表上展示了 64 种不同语言的 175 个工具，它们都实现了处理 JSON 所需的功能。虽然我不能评价大多数工具的质量，但它们的存在明确了开发者社区拥抱 JSON 这一现象，而且它们切实简化了在不同平台使用 JSON 的难度。

二者的动机

简单地说，XML 的目标是标记文档。这和 JSON 的目标想去甚远，所以只要用得到 XML 的地方就尽管用。它使用树形的结构和包含语义的文本来表达混合内容以实现这一目标。在 XML 中可以表示数据的结构，但这并不是它的长处。

JSON 的目标是用于数据交换的一种结构化表示。它直接使用对象、数组、数字、字符串、布尔值这些元素来达成这一目标。这完全不同于文档标记语言。正如上面说的那样，JSON 没有原生支持 混合内容(mixed content)的记录。

软件

这些主流的开放 API 仅提供 XML： 亚马逊产品广告 API(Amazon Product Advertising API)。

这些主流 API 仅提供 JSON： 脸书图 API(Facebook Graph API)、 谷歌地图 API(Google Maps API)、 推特 API(Twitter API)、AccuWeather API、Pinterest API、Reddit API、Foursquare API。

这些主流 API 同时提供 XML 和 JSON： 谷歌云存储(Google Cloud Storage)、 领英 API(Linkedin API)、Flickr API。

根据 可编程网络(Programmable Web) 9 的数据，最流行的 10 个 API 中只有一个是仅提供 XML 且不支持 JSON 的。其他的要么同时支持 XML 和 JSON，要么只支持 JSON。这表明了大多数应用开发者都更倾向于使用支持 JSON 的 API，原因大概是 JSON 更快的处理速度与良好口碑，加之与 XML 相比更加轻量。此外，大多数 API 只是传递数据而非文档，所以 JSON 更加合适。例如 Facebook 的重点在于用户的交流与帖子，谷歌地图则主要处理坐标和地图信息，AccuWeather 就只传递天气数据。总之，虽然不能说天气 API 在使用时究竟是 JSON 用的多还是 XML 用的多，但是趋势明确偏向了 JSON。10 11

这些主流的桌面软件仍然只是用 XML：Microsoft Word、Apache OpenOffice、LibraOffice。

因为这些软件需要考虑引用、格式、存储等等，所以比起 JSON，XML 优势更大。另外，这三款程序都支持混合内容，而 JSON 在这一点上做得并不如 XML 好。举例说明，当用户使用 Microsoft Word 编辑一篇论文时，用户需要使用不同的文字字形、文字大小、文字颜色、页边距、段落格式等，而 XML 结构化的组织形式与标签属性生来就是为了表达这些信息的。

这些主流的数据库支持 XML：IBM DB2、Microsoft SQL Server、Oracle Database、PostgresSQL、BaseX、eXistDB、MarkLogic、MySQL。

这些是支持 JSON 的主流数据库：MongoDB、CouchDB、eXistDB、Elastisearch、BaseX、MarkLogic、OrientDB、Oracle Database、PostgreSQL、Riak。

在很长一段时间里，SQL 和关系型数据库统治着整个数据库市场。像 甲骨文(Oracle)和 微软(Microsoft)这样的软件巨头都提供这类数据库，然而近几年 NoSQL 数据库正逐步受到开发者的青睐。也许是正巧碰上了 JSON 的普及，大多数 NoSQL 数据库都支持 JSON，像 MongoDB、CouchDB 和 Riak 这样的数据库甚至使用 JSON 来存储数据。这些数据库有两个重要的特性是它们适用于现代网站：一是它们与关系型数据库相比 更容易扩展(more scalable)；二是它们设计的目标就是 web 运行所需的核心组件。12 由于 JSON 更加轻量，又是 JavaScript 的子集，所以很适合 NoSQL 数据库，并且让这两个品质更容易实现。此外，许多旧的关系型数据库增加了 JSON 支持，例如 Oracle Database 和 PostgreSQL。由于 XML 与 JSON 间的转换比较麻烦，所以大多数开发者会直接在他们的应用里使用 JSON，因此开发数据库的公司才有支持 JSON 的理由。（LCTT 译注：NoSQL 是对不同于传统的关系数据库的数据库管理系统的统称。参考来源） 13

未来

对互联网的种种变革中，最让人期待的便是 物联网(Internet of Things)（IoT）。这会给互联网带来大量计算机之外的设备，例如手表、温度计、电视、冰箱等等。这一势头的发展良好，预期在不久的将来迎来爆发式的增长。据估计，到 2020 年时会有 260 亿 到 2000 亿的物联网设备被接入互联网。14 15 几乎所有的物联网设备都是小型设备，因此性能比笔记本或台式电脑要弱很多，而且大多数都是嵌入式系统。因此，当它们需要与互联网上的系统交换数据时，更轻量、更快速的 JSON 自然比 XML 更受青睐。16 受益于 JSON 在 web 上的快速普及，与 XML 相比，这些新的物联网设备更有可能从使用 JSON 中受益。这是一个典型的梅特卡夫定律的例子，无论是 XML 还是 JSON，抑或是什么其他全新的格式，现存的设备和新的设备都会从支持最广泛使用的格式中受益。

Node.js 是一款服务器端的 JavaScript 框架，随着她的诞生与快速成长，与 MongoDB 等 NoSQL 数据库一起，让全栈使用 JavaScript 开发成为可能。这些都预示着 JSON 光明的未来，这些软件的出现让 JSON 运用在全栈开发的每一个环节成为可能，这将使应用更加轻量，响应更快。这也是任何应用的追求之一，所以，全栈使用 JavaScript 的趋势在不久的未来都不会消退。17

此外，另一个应用开发的趋势是从 SOAP 转向 REST。18 19 20 XML 和 JSON 都可以用于 REST，可 SOAP 只能使用 XML。

从这些趋势中可以推断，JSON 的发展将统一 Web 的信息交换格式，XML 的使用率将继续降低。虽然不应该把 JSON 吹过头了，因为 XML 在 Web 中的使用依旧很广，而且它还是 SOAP 的唯一选择，可考虑到 SOAP 到 REST 的迁移，NoSQL 数据库和全栈 JavaScript 的兴起，JSON 卓越的性能，我相信 JSON 很快就会在 Web 开发中超过 XML。至于其他领域，XML 比 JSON 更好的情况并不多。

角注

  1. Introducing JSON↩
  2. XML Tutorial↩
  3. JSON vs. XML: Some hard numbers about verbosity↩
  4. Comparison of JSON and XML Data Interchange Formats: A Case Study↩
  5. A comparison of data serialization formats for optimal efficiency on a mobile platform↩
  6. Comparison of JSON and XML Data Interchange Formats: A Case Study↩
  7. A comparison of data serialization formats for optimal efficiency on a mobile platform↩
  8. Introducing JSON↩
  9. Most Popular APIs: At Least One Will Surprise You↩
  10. Why JSON will continue to push XML out of the picture↩
  11. Thousands of APIs Paint a Bright Future for the Web↩
  12. Why JSON will continue to push XML out of the picture↩
  13. How JSON sparked NoSQL – and will return to the RDBMS fold↩
  14. A Simple Explanation Of ‘The Internet Of Things’↩
  15. Proofpoint Uncovers Internet of Things (IoT) Cyberattack↩
  16. Why JSON will continue to push XML out of the picture↩
  17. Why JSON will continue to push XML out of the picture↩
  18. Thousands of APIs Paint a Bright Future for the Web↩
  19. 3,000 Web APIs: Trends From A Quickly Growing Directory↩
  20. How REST replaced SOAP on the Web: What it means to you↩

 

JSON不总是更小,如: <a b="c"/> 和 "a":{"b":"c"} 对比一下长度

都9102年了，对比不应该加上yaml和protobuf么？

JSON、XML、TOML、CSON、YAML 大比拼

一段超级严肃的关于样本序列化的集合、子集和超集的文字

我是一名开发者，我读代码，我写代码，我写会写代码的代码，我写会写出供其它代码读的代码的代码。这些都非常火星语，但是有其美妙之处。然而，最后一点，写会写出供其它代码读的代码的代码，可以很快变得比这段文字更费解。有很多方法可以做到这一点。一种不那么复杂而且开发者社区最爱的方式是数据序列化。对于那些不了解我刚刚抛给你的时髦词的人，数据序列化是从一个系统获取一些信息，将其转换为其它系统可以读取的格式，然后将其传递给其它系统的过程。

虽然数据序列化格式多到可以埋葬哈利法塔，但它们大多分为两类：

  • 易于人类读写，
  • 易于机器读写。

很难两全其美，因为人类喜欢让我们更具表现力的松散类型和灵活格式标准，而机器倾向于被确切告知一切事情而没有二义性和细节缺失，并且认为“严格规范”才是它们最爱的口味。

由于我是一名 web 开发者，而且我们是一个创建网站的机构，我们将坚持使用 web 系统可以理解或不需要太多努力就能理解的特殊格式，而且对人类可读性特别有用的格式：XML、JSON、TOML、CSON 以及 YAML。每个都有各自的优缺点和适当的用例场景。

事实最先

回到互联网的早期，一些非常聪明的家伙决定整合一种让每个系统都能理解的标准语言，并创造性地将其命名为 标准通用标记语言(Standard Generalized Markup Language)（简称 SGML）。SGML 非常灵活，发布者也很好地定义了它。它成为了 XML、SVG 和 HTML 等语言之父。所有这三个都符合 SGML 规范，可是它们都是规则更严格、灵活性更少的子集。

最终，人们开始看到非常小、简洁、易读且易于生成的数据的好处，这些数据可以在系统之间以编程的方式共享，而开销很小。大约在那个时候，JSON 诞生了并且能够满足所有的需求。而另一方面，其它语言也开始出现以处理更多的专业用例，如 CSON，TOML 和 YAML。

XML：不行了

原本，XML 语言非常灵活且易于编写，但它的缺点是冗长，人类难以阅读、计算机非常难以读取，并且有很多语法对于传达信息并不是完全必要的。

今天，它在 web 上的数据序列化的用途已经消失了。除非你在编写 HTML 或者 SVG，否则你不太能在许多其它地方看到 XML。一些过时的系统今天仍在使用它，但是用它传递数据往往太重了。

我已经可以听到 XML 老爷爷开始在它们的石碑上乱写为什么 XML 是了不起的，所以我将提供一个小小的补充：XML 可以很容易地由系统和人读写。然而，真的，我的意思是荒谬的，很难创建一个可以规范的读取它的系统。这是一个简单美观的 XML 示例：

<book id="bk101">
<author>Gambardella, Matthew</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
<publish_date>2000-10-01</publish_date>
<description>An in-depth look at creating applications
with XML.</description>
</book>

太棒了。易于阅读、理解、写入，也容易编码一个可以读写它的系统。但请考虑这个例子：

<!DOCTYPE r [ <!ENTITY y "a]>b"> ]>
<r>
<a b="&y;>" />
<![CDATA[[a>b <a>b <a]]>
<?x <a> <!-- <b> ?> c --> d
</r>

这上面是 100% 有效的 XML。几乎不可能阅读、理解或推理。编写可以使用和理解这个的代码将花费至少 36 根头发和 248 磅咖啡渣。我们没有那么多时间或咖啡，而且我们大多数老程序员们现在都是秃头。所以，让它活在我们的记忆里，就像 css hacks、IE 6 浏览器 和真空管一样好了。

JSON：并列聚会

好吧，我们都同意，XML = 差劲。那么，好的替代品是什么？ JavaScript 对象表示法(JavaScript Object Notation)，简称 JSON。JSON（读起来像 Jason 这个名字） 是 Brendan Eich 发明的，并且得到了伟大而强力的 JavaScript 意见领袖 Douglas Crockford 的推广。它现在几乎用在任何地方。这种格式很容易由人和机器编写，按规范中的严格规则解析也相当容易，并且灵活 —— 允许深层嵌套数据，支持所有的原始数据类型，及将集合解释为数组或对象。JSON 成为了将数据从一个系统传输到另一个系统的事实标准。几乎所有语言都有内置读写它的功能。

JSON语法很简单。方括号表示数组，花括号表示记录，由冒号分隔的两个值分别表示属性或“键”（在左边）、值（在右边）。所有键必须用双引号括起来：

{
    "books": [
      {
        "id": "bk102",
        "author": "Crockford, Douglas",
        "title": "JavaScript: The Good Parts",
        "genre": "Computer",
        "price": 29.99,
        "publish_date": "2008-05-01",
        "description": "Unearthing the Excellence in JavaScript"
      }
    ]
  }

这对你来说应该是完全有意义的。它简洁明了，并且从 XML 中删除了大量额外废话，并传达相同数量的信息。JSON 现在是王道，本文剩下的部分会介绍其它语言格式，这些格式只不过是 JSON 的简化版，尝试让其更简洁或对人类更易读，可结构还是非常相似的。

TOML: 缩短到彻底的利他主义

TOML（ Tom 的显而易见的最小化语言(Tom’s Obvious, Minimal Language)）允许以相当快捷、简洁的方式定义深层嵌套的数据结构。名字中的 Tom 是指发明者 Tom Preston Werner，他是一位活跃于我们行业的创造者和软件开发人员。与 JSON 相比，语法有点尴尬，更类似 ini 文件。这不是一个糟糕的语法，但是需要一些时间适应。

[[books]]
id = 'bk101'
author = 'Crockford, Douglas'
title = 'JavaScript: The Good Parts'
genre = 'Computer'
price = 29.99
publish_date = 2008-05-01T00:00:00+00:00
description = 'Unearthing the Excellence in JavaScript'

TOML 中集成了一些很棒的功能，例如多行字符串、保留字符的自动转义、日期、时间、整数、浮点数、科学记数法和“表扩展”等数据类型。最后一点是特别的，是 TOML 如此简洁的原因：

[a.b.c]
d = 'Hello'
e = 'World'

以上扩展到以下内容：

{
  "a": { 
    "b": {
      "c": { 
        "d": "Hello"
        "e": "World"
      }
    }
  }
}

使用 TOML，你可以肯定在时间和文件长度上会节省不少。很少有系统使用它或非常类似的东西作为配置，这是它最大的缺点。根本没有很多语言或库可以用来解释 TOML。

CSON: 特定系统所包含的简单样本

首先，有两个 CSON 规范。 一个代表 CoffeeScript Object Notation，另一个代表 Cursive Script Object Notation。后者不经常使用，所以我们不会关注它。我们只关注 CoffeeScript。

CSON 需要一点介绍。首先，我们来谈谈 CoffeeScript。CoffeeScript 是一种通过运行编译器生成 JavaScript 的语言。它允许你以更加简洁的语法编写 JavaScript 并转译成实际的 JavaScript，然后你可以在你的 web 应用程序中使用它。CoffeeScript 通过删除 JavaScript 中必需的许多额外语法，使编写 JavaScript 变得更容易。CoffeeScript 摆脱的一个大问题是花括号 —— 不需要它们。同样，CSON 是没有大括号的 JSON。它依赖于缩进来确定数据的层次结构。CSON 非常易于读写，并且通常比 JSON 需要更少的代码行，因为没有括号。

CSON 还提供一些 JSON 不提供的额外细节。多行字符串非常容易编写，你可以通过使用 # 符号开始一行来输入注释，并且不需要用逗号分隔键值对。

books: [
  id: 'bk102'
  author: 'Crockford, Douglas'
  title: 'JavaScript: The Good Parts'
  genre: 'Computer'
  price: 29.99
  publish_date: '2008-05-01'
  description: 'Unearthing the Excellence in JavaScript'
]

这是 CSON 的大问题。它是 CoffeScript 对象表示法(CoffeeScript Object Notation)。也就是说你要用 CoffeeScript 解析/标记化/lex/转译或其它方式来使用 CSON。CoffeeScript 是读取数据的系统。如果数据序列化的目的是允许数据从一个系统传递到另一个系统，这里我们有一个只能由单个系统读取的数据序列化格式，这使得它与防火火柴、防水海绵或者叉匙恼人的脆弱叉子部分一样有用。

如果这种格式被其它系统也采用，那它在开发者世界中可能非常有用。但到目前为止这基本上没有发生，所以在 PHP 或 JAVA 等替代语言中使用它是不行的。

YAML：年轻人的呼喊

开发人员感到高兴，因为 YAML 来自一个 Python 的贡献者。YAML 具有与 CSON 相同的功能集和类似的语法，有一系列新功能，以及几乎所有 web 编程语言都可用的解析器。它还有一些额外的功能，如循环引用、软包装、多行键、类型转换标签、二进制数据、对象合并和集合映射。它具有非常好的可读性和可写性，并且是 JSON 的超集，因此你可以在 YAML 中使用完全合格的 JSON 语法并且一切正常工作。你几乎不需要引号，它可以解释大多数基本数据类型（字符串、整数、浮点数、布尔值等）。

books:
  - id: bk102
  author: Crockford, Douglas
  title: 'JavaScript: The Good Parts'
  genre: Computer
  price: 29.99
  publish_date: !!str 2008-05-01
  description: Unearthing the Excellence in JavaScript

业界的年轻人正在迅速采用 YAML 作为他们首选的数据序列化和系统配置格式。他们这样做很机智。YAML 具有像 CSON 一样简洁的所有好处，以及与 JSON 一样的数据类型解释的所有功能。YAML 像加拿大人容易相处一样容易阅读。

YAML 有两个问题，对我而言，第一个是大问题。在撰写本文时，YAML 解析器尚未内置于多种语言，因此你需要使用第三方库或扩展来为你选择的语言解析 .yaml 文件。这不是什么大问题，可似乎大多数为 YAML 创建解析器的开发人员都选择随机将“附加功能”放入解析器中。有些允许标记化，有些允许链引用，有些甚至允许内联计算。这一切都很好（某种意义上），只是这些功能都不是规范的一部分，因此很难在其他语言的其他解析器中找到。这导致系统限定，你最终遇到了与 CSON 相同的问题。如果你使用仅在一个解析器中找到的功能，则其他解析器将无法解释输入。大多数这些功能都是无意义的，不属于数据集，而是属于你的应用程序逻辑，因此最好简单地忽略它们和编写符合规范的 YAML。

第二个问题是很少有解析器完全实现规范。所有的基本要素都有，但是很难找到一些更复杂和更新的东西，比如软包装、文档标记和首选语言的循环引用。我还没有看到对这些东西的刚需，所以希望它们不让你很失望。考虑到上述情况，我倾向于保持 1.1 规范 中呈现的更成熟的功能集，而避免在 1.2 规范 中找到的新东西。然而，编程是一个不断发展的怪兽，所以当你读完这篇文章时，你或许就可以使用 1.2 规范了。

最终哲学

这是最后一段话。每个序列化语言都应该以个案标准的方式评价。当涉及机器的可读性时，有些 无出其右(the bee’s knees)。对于人类可读性，有些 名至实归(the cat’s meow)，有些只是 金玉其外(gilded turds)。以下是最终细分：如果你要编写供其他代码阅读的代码，请使用 YAML。如果你正在编写能写出供其他代码读取的代码的代码，请使用 JSON。最后，如果你正在编写将代码转译为供其他代码读取的代码的代码，请重新考虑你的人生选择。

posted @ 2021-07-30 10:36  CharyGao  阅读(1522)  评论(0)  编辑  收藏  举报