刚刚看了一篇 @云菲菲 的关于基于正则的INI辅助类文章：http://www.cnblogs.com/yunfeifei/p/4081977.html，作者写的不错。还看到评论处有一个的地址：https://devlib.codeplex.com/SourceControl/latest#main/product/Codes/DevLib.Configuration/IniEntry.cs，也是基于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 = ; i < ; i++)
{
List<IniStruct> iniStructs = Ini.ReadValues(path);//这里我特意用了批量读取的方法
}
string a = stopwatch.Elapsed.ToString();//INI类方法读取所用的时间
stopwatch.Reset();
stopwatch.Start();
for (int i = ; i < ; 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#类，希望朋友们有帮助！