不同配置格式的优缺点？

Question

我见过人们使用 *.cfg (Python Buildout)、*.xml (Gnome)、*.json (Chrome 扩展)、*.yaml (Google App Engine)、*.ini 甚至 *.py 作为应用程序配置文件（如姜戈）。

我的问题是：为什么有这么多不同的配置文件格式？我可以看到 xml 与 json 方法（更不那么冗长）或 Python 方法（有时你有一个 Python 应用程序，并且不想仅使用特定模块来解析配置文件）的优势，但另一种呢？方法？

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

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

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

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

另一个可行的选择是 toml，这是另一种“介于 ini 和 xml”格式。

如今，toml 在 Python 中已经成熟 - 从 tomllib 上的 Python 3.11 开始，tomllib 已包含在 Python 中标准库。它是一个只读解析器，但官方文档提到了外部读写库。

toml 有什么好处？

# Toml prioritize human-readability, allowing comments.

[ section-1 ]
key = "value pair" # is basic.
"Thus looks" = "like ini."

list = ['And', 'arrays', 'are supported, too' ]
dict = { "json-like": "dict type is",
         "available": {
             "too.": "But this is",
             "very": "readable."
         }
       }

[ types ]
number.int = 123
numbers.hex = 0xABCD
numbers.float = 3.14e-16

local.date = 2023-06-28
local.time = 12:34:56

[ others ]
longline = '''Lorem
Ipsum Foo
Bar baz'''

comment = '''This could've been specified as others.comment.
See the official document for the details.'''

Answer 3

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

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

Answer 4

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

JSON 和 Python 是明确的，并且可以很好地处理层次结构，但由于类型提示、引用和转义而变得混乱。

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

INI 将所有值视为字符串，这要求最终应用程序根据需要转换为预期的数据类型。这消除了对类型提示、引用和转义的需要。但是INI本身并不支持层次结构，并且没有标准化，并且不同的实现与其对文件的解释不一致。

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

Answer 5

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

XML、JSON 等完全不适合人类使用，而 INI 格式对人类来说还算合理。

如果配置文件仅具有编程访问权限（程序员偶尔进行编辑），则任何受支持的格式（XML、JSON 或 INI）均适用。 INI 文件不适合结构化参数，其中 XML 和 JSON 可以支持数组、结构/对象等。

Answer 6

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

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