各類配置文件優缺點 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