python - TOML，YAML和StrictYAML

Question

TOML said“TOML和YAML都强调人类的可读性，例如使人们更容易理解给定行目的的注释。TOML的不同之处在于将它们组合在一起，允许注释(与JSON不同)，但保留了简单性(与YAML不同)。”
我可以看到TOML并不依赖空白，但是除此之外，我不确定它声称的简单。那到底是什么？
然后，我看到StrictYAML:“StrictYAML是一种类型安全的YAML解析器，用于解析和验证YAML规范的受限子集。” 类型安全的，这又是什么？
StrictYAML认为TOML不能为YAML解决的问题是什么？我确实阅读了StrictYAML网站上的文章，但仍不清楚。
因此，TOML和StrictYAML都希望解决YAML所存在的“问题”。但是，除了缩进，还有什么问题？
- - 更新 - -
我在reddit中发现StrictYaml的作者谈论了YAML vs TOML。但是到目前为止，我得到的答案是“strictyaml对YAML的理解很差”

YAML downsides:

Implicit typing causes surprise type changes. (e.g. put 3 where youpreviously had a string and it will magically turn into an int).

A bunch of nasty "hidden features" like node anchors and referencesthat make it look unclear (although to be fair a lot of people don'tuse this).

TOML downsides:

Noisier syntax (especially with multiline strings).

The way arrays/tables are done is confusing, especially arrays oftables.

I wrote a library that removed most of the nasty stuff I didn't likeabout YAML leaving the core which I liked. It's got a pretty detailedcomparison between it and a bunch of other config formats, e.g.: https://github.com/crdoconnor/strictyaml/blob/master/FAQ.rst#why-not-use-toml

Answer 1

这可能是一个自以为是的答案，因为我已经编写了多个YAML实现。

替代方案解决了对YAML的常见批评
YAML的突出语义特征是它可以表示可能的循环图。此外，YAML映射可以将复杂的节点(序列或映射)用作键。当您要表示任意数据结构时，可能需要这些功能。
YAML的另一个特殊功能是标签。他们的目标是用不同的编程语言抽象不同的类型，例如!!map在Python中是dict，而在JavaScript中是object。尽管很少明确使用，但是隐式标签解析是为什么false通常作为 bool 值加载而droggeljug作为字符串加载的原因。这里的明显目标是通过不需要写 bool 值(如!!bool false)或在每个字符串值上加引号来减少噪声。
但是，事实表明，很多人对此感到困惑，YAML定义可以解析yes，因为 bool 值也无济于事。 YAML 1.2试图通过描述您可以使用的不同模式来对此进行补救，其中基本的“故障安全”模式专门加载到映射，序列和字符串，而更复杂的“JSON”和“核心”模式则进行其他类型的猜测。但是，大多数YAML实现(主要是PyYAML)在YAML 1.1上保留了很长时间(许多实现最初是重写的PyYAML代码，例如libyaml，SnakeYAML)。这巩固了YAML做出需要修正的可疑打字决定的观点。
如今，一些实现得到了改进，您可以使用故障保护模式来避免不必要的 bool 值。在这方面，StrictYAML仅限于故障安全模式。不要相信它的论点，这是PyYAML无法做到的。
YAML实现的一个常见安全问题是，它们将标记映射到任意构造函数调用(you can read up about an exploit in Ruby on Rails based on this here)。记住这不是YAML的缺点； YAML不建议在对象构造过程中的任何地方调用未知函数。这里的基本问题是，数据序列化是数据封装的大敌。如果您的编程语言提供了构造函数作为构造对象的唯一方法，那么这就是在反序列化数据时需要执行的操作。这里的补救措施仅是调用已知的构造函数，该构造函数是在一系列此类攻击(另一个使用SnakeYAML iirc的攻击)浮出水面之后广泛实现的。如今，要调用未知的构造函数，您需要在PyYAML中使用一个恰本地命名为DangerLoader的类。
汤姆
TOML的主要语义差异是它不支持循环，复杂键或标记。这意味着，尽管可以在任意用户定义的类中加载YAML，但始终将TOML加载到包含数据的表或数组中。
例如，虽然YAML允许您将{foo: 1, bar: 2}加载到具有foo和bar整数字段的类的对象中，但TOML始终将其加载到表中。您通常在文档中发现的YAML功能的一个突出示例是，它可以将标量1d6加载到对象{number: 1, sides: 6}中； TOML将始终将其加载为字符串"1d6"。
TOML在这里的简单性在于它没有像YAML那样做某些事情。例如，如果您使用的是Java之类的静态类型语言，则在将{foo: 1, bar: 2}加载到对象myObject中之后，就可以安全地访问myObject.foo(获取整数1)。如果使用TOML，则需要执行myObject["foo"],，如果键不存在，则可能引发异常。在像Python这样的脚本语言中，情况并非如此:在这里，如果myObject.foo并非foo的属性，则myObject.会编译并因运行时错误而失败
我从这里回答许多YAML问题的观点是，人们不使用YAML的功能，而是经常将所有内容加载到Map<String, Object>之类的结构中(以Java为例)，然后从那里获取它。如果这样做，您也可以使用TOML。
TOML提供了一种不同的简单性语法:由于它比YAML简单得多，因此更容易发出用户可以理解的错误。例如，YAML语法错误中的常见错误文本是“在此上下文中不允许使用映射值”(尝试在SO上进行搜索以查找大量问题)。例如，您在这里获得此信息:

foo: 1
  bar: 2

该错误信息不能帮助用户修复错误。这是由于YAML的语法复杂:YAML认为 1和 bar是多行标量的一部分(因为 bar:比 foo:缩进更多)，将它们放在一起，然后看到第二个 :并失败，因为多行标量可能不是用作隐式键。但是，最有可能的是，用户只是缩进了 bar:或给他们留下了可以为foo( 1)和一些 child 提供标量值的印象。由于YAML语法的可能性，很难编写出可以帮助用户的错误消息。
由于TOML的语法非常简单，因此错误消息更易于理解。如果不希望编写TOML的用户是具有语法分析背景的人，那么这是一个很大的好处。
TOML在概念上比YAML具有优势:由于其结构允许较少的自由度，因此它往往更易于阅读。在阅读TOML时，您总是知道，“好吧，我要在其中嵌套有值的表”，而使用YAML时，您会有一些任意的结构。我认为这在读取YAML文件时需要更多的认知负担。
严格的YAML
StrictYAML认为它提供了类型安全性，但是由于YAML不是一种编程语言，并且特别地不支持赋值，因此基于StrictYAML链接的 Wikipedia definition，此声明没有任何意义(类型安全性与之相伴。是您使用的编程语言；例如，任何YAML在将其加载到适当的Java类实例中后都是类型安全的，但是使用Python这样的语言永远不会是类型安全的)。翻过 its list of removed features，它显示出对YAML的理解很差:

隐式键入:如上所述，可以使用故障安全模式在YAML实现中将其停用。

对象的直接表示形式:它只是链接到Ruby on Rails事件，这意味着即使在当今大多数实现中都可以安全删除该功能，还是无法避免的。

不允许使用重复键:YAML规范已经要求这样做。

节点 anchor 和引用:StrictYAML认为，将其用于重复数据删除对于非编程人员是不可读的，忽略了其意图是能够序列化循环结构，而没有 anchor 和别名是不可能的。

在反序列化方面，

All data is a string, list or OrderedDict

它基本上是TOML支持的相同结构(我相信StrictYAML支持映射中的复杂键，因为 list和 OrderedDict在Python中都不是可哈希的)。
您还将失去反序列化到预定义类结构的能力。有人可能会争辩说，无法使用定义良好的字段构造类对象会使StrictYAML的类型安全性不如标准YAML:标准的YAML实现可以保证返回的对象具有按类型描述的特定结构，而StrictYAML可以为您提供每种类型的结构设置字符串，列表或OrderedDict的级别，您将无法进行任何限制。
尽管它的某些论点存在缺陷，但最终的语言仍然可用。例如，使用StrictYAML，您无需关心 billion laughs attack困扰着某些YAML实现。同样，这不是YAML问题，而是实现问题，因为YAML不需要实现来复制从多个位置 anchor 定和引用的节点。
底线
某些YAML问题源于不良的实现，而不是源于语言本身的问题。但是，YAML作为一种语言肯定很复杂，语法错误可能很难理解，这可能是使用TOML之类的语言的正当理由。至于StrictYAML，它确实提供了一些好处，但是我建议您不要使用它，因为它没有适当的规范，只有一个实现，这是一个很容易成为维护噩梦的设置(项目可能会中止，中断轻松更改)。