各类配置文件优缺点 yaml xml json hocon

适合人类编写：ini > toml > yaml > json > xml > plist
能够存储的数据复杂度：xml > yaml > toml ~ json ~ plist > ini

其实我以为这三者，甚至包括xml,都不是很好的配置文件格式

在小一点的工程中，我可能会考虑yaml，但我的强烈推荐的一个配置文件格式就是HOCON(Human-Optimized Config Object Notation)
是由typesafe（开发scala和play framework的公司）主导的项目：
GitHub - typesafehub/config: Configuration library for JVM languages

在Google干过的同窗能够参考GCL，会发现不少设计上的相似点。

我以为比较完美的配置文件格式需有这些特性

1. 语法要简单，灵活

简单你们都差很少

HOCON是JSON和java property的超集，最为灵活，你能够写

a: {
 b: {
  c: 3
  d: 4
 }
}

也能够单独写

a.b.c=5

":"号也能够换成"="或者就彻底省略

2. 可以写注释，这点json简直可悲，不过能够考虑加预处理的过程

3. 可以比较方便的覆盖参数值（方便书写或者debug），好比说在config文件中定义了
a=1

能够在运行的时候，经过相似 program -Da=2或者a=2 program的的方式来覆盖参数值，而不须要跑去修改配置文件自己

这一点HOCON完爆其余的几种

4. 可以重用配置片断，比较大一点的project中，常常有不少地方的配置须要保持一致，最好的办法就是引入变量和引用的概念，好比能够相似

db_connection: {host: a, password: b, db_name: c, ..... }

service_a: {
  host: yyy
  db: $db_connection
}

service_b: {
  host: yyy
  db: $db_connection
}

这样最大的好处是避免了copy and paste，在修改配置文件的时候能搞保证不出问题

这点yaml和hocon基本上都是作的不错的，json没有，ini我用的很少，好像是没有。
yaml的实现其实比较简单，就是单纯的文本替换，这样致使我要说的下一点被HOCON完爆。

5，能够继承
这是HOCON完爆其余语言的地方。仍是上面那个例子，假设service_b.db不单单是是要是用全局db_connection的值，要稍微修改其中host的值，能够

service_b: {
  host: yyy
  db: ${db_connection} {
    host: abc
  }
}

human:{name:测试,sex:男,add="中国"}
 
 person:${human}{add="测试地址"}

并且不须要从新copy and paste以前全部的内容

它的继承很是强大，语义能够说基本上和普通OO语言没有太大区别

另外HOCON能够包含文件，好比说你能够写一个基础的配置文件base.conf，而后再针对dev，staging和production分别作一份不一样的文件，这样能够很轻松地作到在不一样的环境下，用不一样的配置并且没有重复的配置代码，好比说

include 'base.conf'

// 覆盖默认值
db.connection = "product_machine:2000"
....

 

configuration library for JVM languages using HOCON files https://lightbend.github.io/config/

toml:https://github.com/toml-lang/toml