许多项目用 JSON 作为配置文件。也许最著名的例子就是 npm 和 yarn 使用的 package.json，还有许多其他项目也用 JSON，如 CloudFormation（最初仅支持 JSON，现在还支持 YAML）和 composer（PHP）。

但是，有几个原因表明 JSON 其实非常不适合作为配置语言。不要误会，我很喜欢 JSON。它非常灵活，而且机器和人类读起来都很容易，是个非常好的数据交换和存储的格式。但作为配置语言，它有许多缺点。

为什么 JSON 成了流行的配置语言？

JSON 被用于配置文件有好几个原因。最大的原因就是很容易实现。许多语言的标准库都支持 JSON，标准库不支持 JSON 的语言也会有非常易用的 JSON 包。其次就是开发者和用户都已经很熟悉 JSON 了，不需要再为产品学一种新的配置格式。更不用说 JSON 的各种相关工具，包括语法高亮、自动格式化、验证工具等等。

这些都是很好的理由。可惜这种格式真的不适合作为配置文件。

JSON 的问题

没有注释

配置语言的一个绝对必要的功能就是注释。注释非常有用，它能标识出配置项的可能的值，以及选择某个值的原因，还有最重要的一点就是临时注释掉某部分配置以方便测试和调试。而作为数据交换格式的 JSON 完全没有使用注释的必要。

当然也有方法解决这个问题。最常见的方法就是在对象中使用特殊的键作为注释，如"//"或"__comment"。但是，这种语法并不是很易读，而且如果要想在同一个对象中使用多个注释，就得给每个注释使用唯一的键。David Crockford（JSON的发明人）建议使用预处理器去掉注释（）。如果你的应用程序要求 JSON 作为配置文件，那么我建议使用这种方法，特别是如果有某种构建过程的话。当然，这会给编辑配置带来一些额外的工作，因此如果你正在创建的应用程序需要解析配置文件的话，不要依赖用户去做这项工作。

一些 JSON 库允许使用注释。例如，Ruby 的 JSON 模块，以及 Java 的 Jackson 库加上启用 JsonParser.Feature.ALLOW_COMMENTS 功能，就能支持在 JSON 中使用 JavaScript 风格的注释。然而这并不是标准，许多编辑器也不能正常支持 JSON 文件中的注释，使得编辑配置文件比较困难。

过分严格

JSON 的标准非常严格。严格的目的是为了方便 JSON 解析器的实现，但我认为，它也影响了易读性，而且或多或少地使得人类书写 JSON 更困难。

低信噪比

与许多其他配置语言相比，JSON 的噪声很大。许多标点符号尽管使得机器很容易实现，但完全不能帮助人类阅读。具体来说，对于配置文件而言，对象中的键几乎必然是标识符，因此键的引号是完全不必要的。

而且 JSON 要求在整个文档外面使用大括号，这样做的目的是使之（几乎）成为 JavaScript 的子集，并且在发送多个 JSON 对象时易于分隔各个对象。但作为配置文件，最外层的大括号是完全无用的。键值对之间的逗号大部分情况下也没有用。通常，每一行就是一个键值对，所以完全可以把换行符作为分隔符。

说起逗号，JSON 还不支持末尾逗号。如果要求每个键值对都以逗号结尾，那么至少应该接受末尾逗号吧，因为末尾逗号使得在末尾添加新项目很容易，而且能更容易地比较不同版本的差异。

过长的字符串

JSON 作为配置文件的另一个问题是它不支持多行字符串。如果要在字符串中使用换行，就得转义成“\n”，而且更糟糕的是，如果想在文件中写一个跨行的字符串，那是完全没办法的。若是配置文件里没有特别长的字符串的话还好。但如果配置文件里包含长字符串，比如某个项目的描述，或者 GPG 秘钥，你肯定不希望把所有行都放在同一行里并用“\n”连接起来。

数字

此外，JSON对于数字的定义在某些场合下很有问题。根据JSON标准，数字是任意精度的有限浮点数，以十进制表示。大多数情况下这没什么问题。但如果你需要十六进制表示，或者需要无穷大、NaN等值，那么TOML或YAML能更好地处理这些输入。

1{

2 "name": "example",

3 "description": "A really long description that needs multiple lines.\nThis is a sample project to illustrate why JSON is not a good configuration format. This description is pretty long, but it doesn't have any way to go onto multiple lines.",

4 "version": "0.0.1",

5 "main": "index.js",

6 "//": "This is as close to a comment as you are going to get",

7 "keywords": ["example", "config"],

8 "scripts": {

9 "test": "./test.sh",

10 "do_stuff": "./do_stuff.sh"

11 },

12 "bugs": {

13 "url": ""

14 },

15 "contributors": [{

16 "name": "John Doe",

17 "email": "johndoe@example.com"

18 }, {

19 "name": "Ivy Lane",

20 "url": ""

21 }],

22 "dependencies": {

23 "dep1": "^1.0.0",

24 "dep2": "3.40",

25 "dep3": "6.7"

26 }

27}

那应该用什么？

配置语言的选择取决于应用程序。每种语言都有自己的长处和短处。下面这些语言都可以考虑。这些都是专用于配置文件的语言，都比原本用于数据的 JSON 要好。

TOML

TOML（）作为配置语言日渐流行。它的使用者包括Cargo（Rust的编译工具）、pip（Python包管理器）和dep（golang 依赖管理器）。TOML 有点像 INI 格式，但与 INI 不同的是，它有自己的标准，而且对于嵌套结构有很好的支持。它要比 YAML 简单得多，所以当配置文件很简单时，TOML就很合适。但如果配置文件有大量嵌套结构，那么 TOML 可能会显得有点啰嗦，此时其他语言如 YAML、HOCON 可能是更好的选择。

1name = "example"

2description = """

3A really long description that needs multiple lines.

4This is a sample project to illustrate why JSON is not a \

5good configuration format. This description is pretty long, \

6but it doesn't have any way to go onto multiple lines."""

7

8version = "0.0.1"

9main = "index.js"

10# This is a comment

11keywords = ["example", "config"]

12

13[bugs]

14url = ""

15

16[scripts]

17

18test = "./test.sh"

19do_stuff = "./do_stuff.sh"

20

21[[contributors]]

22name = "John Doe"

23email = "johndow@example.com"

24

25[[contributors]]

26name = "Ivy Lane"

27url = ""

28

29[dependencies]

30

31dep1 = "^1.0.0"

32# Why we depend on dep2

33dep2 = "3.40"

34dep3 = "6.7"

HJSON

HJSON（）是个基于 JSON 的语言，但更灵活，因此更容易阅读。它支持注释、多行字符串、不带引号的键和字符串，以及可选的逗号。如果你喜欢 JSON 的简单结构，但希望更适合配置文件的话，可以试试HJSON。它还提供命令行工具将 HJSON 转换成 JSON，因此如果你的工具要求 JSON 的话，你可以用 HJSON 写配置文件，并在构建过程中转换成 JSON。与 HJSON 相似的另一个选择是 JSON5（）。

1{

2 name: example

3 description: '''

4 A really long description that needs multiple lines.

5

6 This is a sample project to illustrate why JSON is

7 not a good configuration format. This description

8 is pretty long, but it doesn't have any way to go

9 onto multiple lines.

10 '''

11 version: 0.0.1

12 main: index.js

13 # This is a a comment

14 keywords: ["example", "config"]

15 scripts: {

16 test: ./test.sh

17 do_stuff: ./do_stuff.sh

18 }

19 bugs: {

20 url:

21 }

22 contributors: [{

23 name: John Doe

24 email: johndoe@example.com

25 } {

26 name: Ivy Lane

27 url:

28 }]

29 dependencies: {

30 dep1: ^1.0.0

31 # Why we have this dependency

32 dep2: "3.40"

33 dep3: "6.7"

34 }

35}

HOCON

HOCON（）是为Play框架（）设计的配置语言，但在Scala项目中非常流行。它是JSON的超集，所以可以兼容JSON文件。除了注释、可选逗号、多行字符串等标准功能之外，HOCON还支持从其他文家中导入，引用其他值的键以避免重复代码，以及使用点分隔的键指定到某个值的路径，这样用户就不需要把所有值直接放在大括号对象里了。

1name = example

2description = """

3A really long description that needs multiple lines.

4

5This is a sample project to illustrate why JSON is

6not a good configuration format. This description

7is pretty long, but it doesn't have any way to go

8onto multiple lines.

9"""

10version = 0.0.1

11main = index.js

12# This is a a comment

13keywords = ["example", "config"]

14scripts {

15 test = ./test.sh

16 do_stuff = ./do_stuff.sh

17}

18bugs.url = ""

19contributors = [

20 {

21 name = John Doe

22 email = johndoe@example.com

23 }

24 {

25 name = Ivy Lane

26 url = ""

27 }

28]

29dependencies {

30 dep1 = ^1.0.0

31 # Why we have this dependency

32 dep2 = "3.40"

33 dep3 = "6.7"

34}

YAML

YAML（YAML Ain't Markup Language，“YAM不是标记语言”，）是个非常灵活的格式，它几乎是JSON的超集，许多著名的项目都使用YAML，如Travis CI、Circle CI和AWS CloudFormation。YAML的库几乎和JSON一样流行。除了支持注释、换行符分隔、多行字符串、不带引号的字符串和更灵活的类型系统之外，YAML还可以引用之前定义过的结构，从而避免代码重复。

YAML的主要缺点就是它的标准太复杂，导致不同实现之间的不一致。它的缩进层次还有重要的语法意义（类似于Python），这也是褒贬不一的地方。复制粘贴YAML也比较困难。关于YAML的缺点可以参考“也许不是那么好的YAML”（）一文。

1name: example

2description: >

3 A really long description that needs multiple lines.

4

5 This is a sample project to illustrate why JSON is not a good

6 configuration format. This description is pretty long, but it

7 doesn't have any way to go onto multiple lines.

8version: 0.0.1

9main: index.js

10# this is a comment

11keywords:

12 - example

13 - config

14scripts:

15 test: ./test.sh

16 do_stuff: ./do_stuff.sh

17bugs:

18 url: ""

19contributors:

20 - name: John Doe

21 email: johndoe@example.com

22 - name: Ivy Lane

23 url: ""

24dependencies:

25 dep1: ^1.0.0

26 # Why we depend on dep2

27 dep2: "3.40"

28 dep3: "6.7"

脚本语言

如果你的应用程序是用某种脚本语言写的，如 Python 或 Ruby，而且配置文件的来源可信，那么最好的选择就是用那种语言本身编写配置文件。对于编译语言，如果需要真正灵活的配置选项，也可以嵌入类似 Lua 这种脚本语言。这样可以享受到脚本语言的灵活性，而且比使用另一种配置文件更容易。但使用脚本语言的缺点就是它可能过于强大，而且如果配置语言的来源不可信，这样做会引入很严重的安全问题。

编写自己的配置语言

如果出于某种原因，键值配置格式不符合你的要求，并且由于性能或大小限制不能使用脚本语言，那么可能自己写一个配置格式更合适。但在这样做之前，务必要认真考虑，因为这样做不仅需要自行维护解析器，还需要让你的用户熟悉一种新的配置格式才行。

结论

有了这么多配置语言的选择，使用JSON并不是个好注意。如果你要创建新的应用、框架或库，需要一个配置文件，那么选择JSON之外的格式吧。

原文：

作者：Thayne McCombs© Lucidchart。

译者：弯月，责编：屠敏

“征稿啦！”

CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。

如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（guorui@csdn.net）。