關於配置檔案，在 php 的 zend framework 中我做過一些簡單的關於效能的測試：
。將 ninnypro 的配置檔案從 ini 修改為 xml ，並且聲稱能提高傳說中的效能。
最近被調到另外乙個在用 python 的組幫忙，閱讀了他們的實現伺服器端的 python **之，配置檔案近二十餘個，全是 xml 檔案。為了使用著些配置檔案，從 xmlfile 繼承，實現了二十餘個 config 類。
這看起來似乎沒什麼問題。
是的，一點問題也沒有。
xml是高度結構化的描述方式。
xml有大量豐富的包、庫支援。
xml的跨語言能力也是相當優異。你可以輕鬆的用市面上常見的所有語言輕鬆的掌控 xml。
這些都決定了 xml 作為配置檔案，肯定是比 ini 或者自定義結構的配置檔案更加優異的結構。同時，大量的實踐也證明 xml 的優異性。例如 j2ee 的實踐、soa的實現、jabber 的應用都說明 xml: is the lord of the configuration。
但是真得一點問題都沒有麼？
首先，來看一下 zend framework 的 zend_config。由於 php 自身的資料結構特點，zend_config_xml 和 zend_config_ini 兩個類都會載入相應的配置檔案，解析後作為陣列傳遞到 zend_config 類中。也就是說，最終殊途同歸，所有的配置都變成了 php 的陣列。
然後，再來看一下那個專案中的配置檔案。結構化的 xml 被 xmlfile 讀取，然後轉化為 xmlfile 物件。再統一放入 configmanagement 中，經過轉換，將部分結構轉為 dict 使用。
使用配置檔案的原因，我猜測是因為以前，編譯語言開發的程式經過編譯後，不具有動態改變引數的能力。雖然可以從命令列通過傳參來在每次執行時修改配置，但是無論是誰需要通過命令列傳遞成百上千的引數，都會瘋掉。而且，命令列傳參，不具有結構化的特徵。在一些場景下，需要快速修改部分配置，就變得極為困難。
於是聰明的程式設計師發明了對人友好的、結構化的配置檔案，通過讀取配置檔案來改變程式內部引數的使用。
這一習慣一直沿用至今。伴隨 xml 的問世，配置檔案的地位再次上公升。更有甚者，在開發中不做編碼，只寫配置。
看出問題了麼？
如果還是沒有想法的話，那就再來看看指令碼語言：
指令碼語言具有動態性。
指令碼語言自身就是結構化的。
指令碼語言可以增強編譯語言的動態能力。
在各個指令碼語言應用 xml 作為配置檔案的實踐中，不論是 php 的 array，還是 python 的 dict，無一例外的將配置檔案轉換為了指令碼語言內部的一種資料結構。在多數情況下，這也是 xml 作為指令碼語言配置檔案唯一的解決方案。
再來看乙個問題：在專案中使用 xml 作為配置檔案的時候，是否有使用 dtd 作為 xml 的效驗工具？
如果答案是否定的，那麼 xml作為指令碼語言就沒有任何優勢。沒有應用 dtd 的 xml 就如同 php 的 array，python 的 dict 一樣。
那又何必要苦苦的追隨 xml，不用指令碼語言的資料結構來直接編寫配置檔案呢？
本來，早就像對這個話題寫點什麼。星期六（2009-09-19）的時候參加了廣州技術沙龍，聽了朱童鞋的 nginx **剖析後，突然有所頓悟：
成功在於細節，效能在於細節。
指令碼語言 VS 配置檔案和設定嚮導
程式需要配置檔案是非常普遍的事情，儲存使用者特定的配置和一些重複使用的資訊，設定嚮導有利於直觀的指導使用者的配置操作。但是編寫介面類的控制面板和配置嚮導其工作量是非常恐怖的，涉及到ui美化，同步資料等等問題。更嚴重的是配置控制面板能夠完成的配置專案很難做到非常大，比如windows的登錄檔，功能是配...
指令碼語言 shell指令碼
指令碼語言的特徵 指令碼語言 於批處理命令語言，但更接近於程式語言。與批處理命令語言的差別是，指令碼語言有變數和豐富的控制語句 與一般程式語言的差別是 指令碼語言變數的值主要是字串，語言的基本單位是命令 而程式語言變數主要是數值，語言的基本單位是表示式 指令碼語言一般是解釋執行的，速度低，但開發成本...
使用指令碼語言
dim myvar myvar hello world myvar 在這個例子中，option explicit語句強制所有的變數必須專門宣告。dim語句宣告了變數myvar。如果在使用變數前沒有宣告變數，vbscript就會給出執行時錯誤資訊 variable is undefined myvar...