JSON、XML、TOML、CSON、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。最后，假如你正在编写将代码转译为供其他代码读取的代码的代码，请从头思量你的人生选择。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!