剛剛看了一篇 @何問起 的關於基於正則的INI輔助類文章：http://hovertree.com/h/bjaf/39ierjl2.htm，作者寫的不錯。還看到評論處有一個的地址，也是基於ini的一些便捷性封裝類。後者顯然比前者場合通用性強一些，前者則是簡單易用，很方便。但是總體來說都很不錯了。本人學淺，求勿噴！~！~
後面我想了一下，何不自己也些個ini輔助類？這樣一來便有了下文，這個ini類有以下幾個優點：
1.加快訪問速度。
我確實是個喜歡重新造輪子的人,因為我空余時間多。對於這種編程方面的基礎設施，還是有所講究的。敲代碼能省則省。很多人可能會說ini操作實在太簡單了，沒必要重新造輪子。要知道，別人寫的不一定性能都很好。微軟提供的win32api中【WritePrivateProfileString，GetPrivateProfileString】這樣的函數,看起來非常方便了，但是其實很雞肋。
因為GetPrivateProfileString是讀取一次要訪問一下磁盤，如果想讀取很多個鍵值對，那效率簡直不忍直視！
System.Diagnostics.Stopwatch stopwatch = new System.Diagnostics.Stopwatch();
string path = @"D:\Users\Administrator\Documents\SenderRobot\SenderRobot.ini";
stopwatch.Start();
for (int i = 0; i < 10000; i++)
{
List<IniStruct> iniStructs = Ini.ReadValues(path);//這裡我特意用了批量讀取的方法
}
string a = stopwatch.Elapsed.ToString();//INI類方法讀取所用的時間
stopwatch.Reset();
stopwatch.Start();
for (int i = 0; i < 10000; i++)
{
Util.ReadIniValue("應該模式", "sss", path);
}
stopwatch.Stop();
string b = stopwatch.Elapsed.ToString();//微軟的函數讀取所用的時間
自己修改然後對比一下效率看看！我是讀取一次，就把所有的鍵值對全部取出來放在內存裡了。而微軟則是要讀取很多次才能達到這個效果，所以效率可想而知！這樣在自己如果有程序要在啟動的時候加載很多參數的話，能讓磁盤多活幾年不說，讀取速度也是飛一樣的感覺！
2.另外我增加了對ini注釋的功能加強。很多人在ini裡直接用中文作為鍵。這樣一來，你的程序不是自降等級，感覺太山寨化了。用英文的作為鍵，並不是崇洋哦。這個INI類，既能批量讀取的同時把注釋也一並讀取了，還能在代碼裡寫入注釋到ini文件裡，這個功能恐怕微軟的api做不到吧。
3.ini的輔助類操作簡單。這個類對所有人都沒有門檻。就那麼幾個函數。其中有能靜態static訪問的，也有要實例化之後才能操作的。靜態的方便一次性操作。實例化訪問的在是方便經常操作的。
後了，我也說不出更多的優勢了。大家有需要的可以用用。
對於本地小批量數據的保存,目前主要有以下幾種方式：
1.ini
2.xml
3.本地數據庫
4.至於直接用文本的就直接忽略吧。太非主流了。
5.最近流行的protobuf
先說ini：
ini是比較古老的存儲方式了。在win2000的時代就已經很流行了。方便快捷
xml則後期新秀，比較標准化。很多場合可以直接取代ini。但是如果是小型程序裡，ini絕對是最適合的，除了性能方面的考慮，xml格式的太過嚴格也是原因之一。
本地數據庫通常用來保存大數據。比如常用的litesql等。小程序的話就算了吧。有這個寫sql語句的時間人家已經把整個都寫完 。
protobuf是谷歌貢獻給開源社區的文件傳輸格式，主要用來通過網絡收發信息。protocol的高效率和xml比起來，據稱至少要快xml 100倍。protocol是直接二進制保存，規則也較為簡單，因此解析速度必然會比xml要快很多，而且更省流量！
其實，還有一種某大公司開發的編碼格式，也是和protobuf類似的。叫unistruct（unipacket）官方沒有對外的編碼。只是從它的產品逆向獲知的。這種格式也是非常緊湊。傳輸也很得心應手。
好了不多說了，給大家傳上c#類，希望朋友們有幫助！
附件：http://files.cnblogs.com/uu102/Ini.rar
