加入网络标准的 YAML 格式有什么问题吗答案

【问题标题】：Is there anything wrong with YAML format to be joined to the web standards加入网络标准的 YAML 格式有什么问题吗
【发布时间】：2011-07-16 05:06:32
【问题描述】：

嗯，我觉得 YAML 真的很棒……

与任何其他数据序列化格式相比，它美观、易读、语法巧妙。作为JSON 的超集，我们可以说它更加精细，因此它的语言也在进化。

但我看到了一些不同的意见，例如：

YAML 已死，
不要使用yaml之类的...

我根本无法理解这是基于什么，因为它看起来很好:)

如果我们在网络上举几个成功的例子，例如 Ruby on Rails，我们知道他们使用 yaml 进行简单的配置，但让我好奇的一件事是 为什么 yaml 不是是最常用的网络格式的一部分，例如 XML 和 JSON。

如果您以 twitter 为例...为什么不从 API 中也提供 YAML 格式的数据？

这样做有什么问题吗？

我们可以看到像 couchdb、mongo 这样的 no-sql 数据库的演变，这些数据库都是基于 json 的，甚至还有一个名为 jsondb 的伟大项目，它看起来非常轻量级，它绝对可以完成这项工作。

但是在 json 中编写数据结构时，我真的不明白为什么不使用 YAML。

所以我担心的一个问题是 YAML 是否有问题？

人们可以说它很复杂，但是，如果你假装使用你会在 json 中获得的相同功能绝对不是。你肯定会得到一个更漂亮的文件，而且没有任何麻烦。如果您决定使用更多功能，确实会更复杂，但事情就是这样，至少您可以根据需要使用它。

可以选择是否要使用 双引号 作为字符串，这让一切变得更简洁、更易于阅读......好吧，你明白我的意思了 :)

所以我的问题是，为什么没有大量使用 YAML 来代替 JSON？

为什么它似乎不会用于在线社区内的数据结构传输？

我所能看到的只是人们将它用于简单的配置文件，仅此而已......

请多多包涵，因为我可能完全错了，而且可能正在发生非常大的项目，而且我对这个主题的无知不允许我参与其中:)

如果有任何基于 yaml 的大项目，我会很高兴知道的

提前致谢

【问题讨论】：

+close：建议迁移到 Programmers.SE。
朱丽叶，我无法理解您的 close 请求，这与其他已回答的主题一样多。 SE中的程序员网站被定义为对软件开发专业讨论感兴趣的专家程序员的问答，所以我不确定

标签： json data-structures format standards yaml

【解决方案1】：

在 Ruby 中，许多人认为配置应该是 Ruby，而不是 YAML。这节省了解析阶段，意味着您不必学习新语法，并且在动态生成 YAML 内容（Rails 固定装置）时不会到处都有 ERB 标记。

就我个人而言，我必须同意，并且看不出 YAML 会为网络传输提供什么，这将使它成为比 JSON 更值得考虑的因素。

【讨论】：

使用完整的编程语言作为配置语言是危险的 - 如果您使用 eval() 读取它，那么有人可以轻松编写一个存在安全风险的配置文件。

【解决方案2】：

这并不是说 YAML 有什么问题——只是它在许多情况下没有提供任何令人信服的好处。 YAML 基本上是 JSON 的超集。对于大多数用途来说，JSON 就足够了——即使人们拥有完整的 YAML 解析器，他们也不会使用高级 YAML 功能——而且它与 JavaScript 的紧密联系使其能够很好地适应 Web 开发人员正在使用的技术。

TLDR：人们已经在使用尽可能多的 YAML。在大多数情况下，这是 JSON。

【讨论】：

感谢@Chuck，是的，经过一番思考之后，似乎这确实是真正发生的事情，人们没有使用，实际上可能不需要完整的 YAML API，只有 JSON 非常适合美好的。 YML 与 JSON 相比的一大优势是语法更简洁，但由于在大多数情况下它们仍然通过程序读取并由它们生成，所以这可能不是一个大问题，而您可以简单地编写 yml，转换为 json并发送到程序，反之亦然。所以我必须同意你的看法，谢谢:)

【解决方案3】：

YAML 使用的数据比未经修饰的 JSON 多。它非常适合人类可能想要自己编辑的文件，但是当您所做的只是传递数据时，如果您使用的是 YAML，那么您就是在浪费带宽。

如果您需要解释：UTF-16 中的每个空格是两个字节。 YAML 使用空格进行缩进，使用换行符进行嵌套。

举个例子：

foo:
    bar:
        - foo
        - bar

这需要 44 个字符（包括换行符）。等效的 JSON 只有 29 个字符：

{"foo":{"bar":["foo","bar"]}}

然后想象一下如果你对 YAML 进行 URL 编码会发生什么。它变成了 95 个字符：

foo%3A%0A%20%20%20%20bar%3A%0A%20%20%20%20%20%20%20%20-%20foo%0A%20%20%20%20%20%20%20%20-%20bar

同时 JSON 只是变成 64 个字符：

%7B%22foo%22%3A%7B%22bar%22%3A%5B%22foo%22%2C%22bar%22%5D%7D%7D

在上面的示例中，当它是 URL 编码时，从 JSON 到 YAML 的大小增加了一倍以上。而且我相信你可以想象，你的 YAML 文件越长，这种差异就会越来越大。

哦，还有一个不使用 YAML 的原因：stackoverflow.com 不支持 YAML 语法高亮...！（当然，我认为 YAML 是如此美丽以至于它不支持' 需要语法高亮。我认为这就是 YAML 的重点。）

【讨论】：

我可以把你的例子写成foo: {bar:[foo,bar]}。

【解决方案4】：

我曾考虑过几次使用 YAML，但从未这样做过。原因总是与缩进的空白有关。虽然我个人很喜欢这个，但对我来说这听起来像是自找麻烦，因为

肯定有人会出错，没想到更改空格会破坏文件。有时，对语言/格式一无所知的人必须去文件中更改一个数字或字符串。
您不能保证每个地方的每个人都会正确配置比较/合并/SC 软件以捕捉空白或空行差异。

【讨论】：

【解决方案5】：

YAML 有很多问题，有一篇好文章 YAML: probably not so great after all 对此。简短摘要（除了其他答案中已经列出的问题）：

除了简单简短的内容外，无法阅读
默认不安全
存在可移植性问题
非常复杂，有很多令人惊讶的行为

【讨论】：