不同配置格式的优缺点？

Question

我见过有人使用 *.cfg（Python Buildout）、*.xml（Gnome）、*.json（Chrome 扩展）、*.Z6EEDC03A68A69933C763E674F2D7C42F（用于 Google 应用程序配置文件）、*.ini 应用程序引擎文件。 （如 Django）。

我的问题是：为什么有这么多不同的配置文件格式？ I can see an advantage from a xml vs json approach (much less verbose) or a Python one (sometimes you have a Python app and don't want to use a specific module just to parse a config file), but what about the other方法？

我知道有比我举例说明的那些配置文件更多的格式。 与彼此相比，它们的真正优势是什么？ 历史原因？ 与不同系统的兼容性？

如果您要启动一个应用程序来读取某种配置文件（带有插件生态系统），您会使用哪一个？

我举的例子中哪些是最古老的？ 你知道它的历史吗？

Answer 1

这主要是个人喜好、目的和可用库。 我个人认为 xml 对于配置文件来说太冗长了，但它很流行并且有很棒的库。

.cfg、.ini 是运行良好的传统格式，许多语言都有一个可以读取它们的库。 我在 Java、Python、C++ 中使用过它，没有任何问题。 它并不能真正用作数据交换格式，如果我传递数据，我可能会使用相同的格式进行配置和数据交换。

yaml 和 json 介于 xml 和 cfg/ini 之间。 您可以在两者中定义许多数据结构，也可以是像 cfg 一样的简单键值。 这两种格式在 python 中都有很棒的库，我假设许多其他语言也有库。 我相信 json 是 yaml 的子集。

我从来没有使用过 python 文件作为配置，但它似乎对 django 工作得很好。 它确实允许您在配置中有一些可能有用的代码。

上次我选择格式时，我选择了 yaml。 它很简单，但有一些不错的功能，python 库很容易安装，而且非常好。 Json 紧随其后，因为 yaml 库解析了 json，所以我选择了 yaml 而不是它。

Answer 2

请注意，这纯粹是我的意见和推测，但我怀疑格式过多的最大原因可能是由于缺乏现成的、无所不在的配置文件解析库。 缺少这一点，大多数程序必须编写自己的解析器，因此通常会在配置结构需要的复杂程度（分层 vs 扁平，纯数据 vs 嵌入式逻辑（如 if 语句等））、开发人员付出多少努力之间取得平衡愿意花在编写配置文件解析器上，最终用户应该为此付出多少痛苦。 但是，您列出和想到的每一个原因可能都是一两个项目选择格式的动机。

对于我自己的项目，我倾向于使用 .ini 只是因为 Python 已经内置了一个出色的解析器，并且对于我的大多数用例来说它已经“足够好”了。 在这两种情况下它是不够的，我再次使用基于 XML 的配置文件，因为实现相对简单。

Answer 3

这实际上取决于配置文件的读取器/写入器是否是或可以是非程序员，或者它是否具有严格的编程访问权限。

XML、JSON 等，完全不适合人类消费，而 INI 格式对人类来说是合理的。

如果配置文件只能以编程方式访问（由程序员偶尔编辑），那么任何支持的格式（XML、JSON 或 INI）都是合适的。 INI 文件不适合结构化参数，其中 XML 和 JSON 可以支持数组、结构/对象等。

Answer 4

根据 Python 官方文档，“未来对配置功能的增强将添加到 dictConfig()”。

所以任何可以与 dictconfig() 一起使用的配置文件都应该没问题。

Answer 5

大多数配置文件格式继承了显着的复杂性，因为它们支持太多的数据类型。 例如， 2可以解释为 integer、实数和字符串，并且由于大多数配置语言将值转换为这些基础数据类型，因此像2这样的值必须以这样的方式编写，以便同时传达值和类型。 因此， 2通常被解释为 integer， 2.0被解释为实数， "2"被解释为字符串。 这使得不了解这些约定的非程序员很难使用这些语言。 它还增加了语言的复杂性和混乱度。 对于字符串尤其如此。 字符串是任意字符的序列，因此有效的字符串可能包含引号字符。 为了区分嵌入的引号字符和终止字符串的引号字符，必须对嵌入的引号字符进行转义。 这会导致更多的复杂性和混乱。

JSON 和 Python 是明确的并且可以很好地处理层次结构，但是被类型提示、引用和 escaping 弄乱了。

YAML 使引用成为可选，这反过来又使格式不明确。

INI 将所有值都作为字符串，这需要最终应用程序在需要时转换为预期的数据类型。 这消除了对类型提示、引用和 escaping 的需要。 但是INI天生不支持层次结构，而且不规范，不同的实现与它们对文件的解释不一致。

现在可以使用一种类似于 INI 的新格式，因为所有叶值都是字符串，但它是标准化的（它具有明确的规范和全面的测试套件）并且自然地处理层次结构。 NestedText产生了一种非常简单的配置格式，既适合程序员也适合非程序员。 它应该被视为所有新应用程序的配置文件和结构化数据文件格式，特别是对于那些临时用户可以读取、写入或修改文件的应用程序。