yaml,json,ini這三種格式用來做配置文件優缺點

適合人類編寫：ini > toml > yaml > json > xml > plist
可以存儲的數據復雜度：xml > yaml > toml ~ json ~ plist > ini

 

作者：趙扶搖
鏈接：https://www.zhihu.com/question/41253282/answer/119857880
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

其實我覺得這三者，甚至包括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
  }
}

而且不需要重新copy and paste之前所有的內容

它的繼承非常強大，語義可以說基本上和普通OO語言沒有太大區別

另外HOCON可以包含文件，比如說你可以寫一個基礎的配置文件base.conf，然后再針對dev，staging和production分別做一份不同的文件，這樣可以很輕松地做到在不同的環境下，用不同的配置而且沒有重復的配置代碼，比如說

include 'base.conf'

// 覆蓋默認值
db.connection = "product_machine:2000"
....