配置文件格式的选择

配置文件格式的选择

        在软件开发过程中，我们或多或少会遇到文件操作，比如读取配置文件，数据写入文件等。对于文件操作，颇有一些需要注意的地方，下面说说我对配置文件格式选择方面的一些思考。
        由于我们开发出来的产品，可能会有不同的运行环境，以及不同的用户需求，所以会需要设置不同的运行参数，通常我们需要记住配置选项，以配置文件的形式写入存储设备。此时，对于配置文件的内容格式通常有几种选择：
1，二进制文件；
2，文本文件；
3，数据库；

1，二进制文件
        二进制文件的好处，是使用程序来读写非常方便。定义一个结构体，与配置项一一对应，直接按二进制的方式写入文件即可。读取时也是如此，打开文件，直接读入该结构体对应的变量中即可。如果配置项变化，结构体相应变化后，读写文件也不需要改动程序代码。
        另外，二进制文件能以最小的文件尺寸存储数据，不会因为格式而增加文件的大小。这个特性，在对存储空间敏感的情况下，例如图像文件、视频文件来说尤其重要。当前我们针对配置文件来考量，通常配置文件不会太大，节省存储空间这项就不算明显的优势了。
        然而二进制文件的缺陷也是很明显的，一旦配置项发生变化，用新的程序去读旧文件，也就是用新的结构体去对应旧结构体中的值，会导致读取内容的移位错误。使用旧的程序读新配置文件，也会遇到同样的移位错误。对于配置文件而言，配置项的变化（用户需求的变化）是极有可能的事情。新旧版本不兼容问题，是最致命的问题。
        而且，由于二进制文件直接打开后其内容不易识别，除了极专业的人员外都看不明白其内容，分辨文件与程序的对应关系也很难，修改内容也不方便，在实际使用时灵活性很差。用二进制文件来存储配置选项，我只在开发的初期使用，后期都转向文本文件了。

2，文本文件
        相比较而言，文本文件更适用于做配置文件，文本形式易读，对于一个表达良好的文本文件，打开文件，基本就能看明白内容。
当然，文本文件是个大概念，具体到内容的展示形式，就我使用过的主要有3种：
1，键值对；
2，json字符串文件；
3，xml文件。
        键值对形式的文本文件，通常一行写一个键值对，例如如下：
width=1920;
height=1080;
        当然，其中的形式是多样的，将“=”替换为“:”，或者直接用空格来分割的；行尾不使用“;”而使用其它符号的，等等。其关键处在于，前面是一个名称，对内容进行了描述，后面是一个相应内容的赋值。
        键值对这种形式，一是易读，二是易于修改，三是前向兼容，即对旧文件有兼容。若是配置内容有减少，读取旧配置文件时，只是不处理多出来的关键字即可。若是配置内容有增加,读取旧配置文件会导致相应关键字读不到值，读取时可以判断出来，提示版本不匹配，或者赋上默认值以保持系统运行。
        相比较于二进制文件，实现键值对的编码工作量，要增加了不少，而且，一旦配置选项发生变化，也需要相应改动程序。
        键值对文件对于比较简单的配置，是很方便的，但是对于复杂的情况，例如如下情况：
name=张三;
score=90;
name=李四;
score=95;
键值对就不太适用了。当然，我们可以通过修改关键字名字，进行逐个区分，这个在具体实现时会非常麻烦。我们也可以使用一些特殊符合，例如“{}”或“[]”来进行分段处理。
        但是我们有更好的选择，就是使用已经定义好的文本格式，已经在行业中通用的标准，例如json与xml。
json示例如下：
{
    "people":[
        {"Name":"张三","score":"90"},
        {"Name":"李四","score":"95"}
    ]
}
xml示例如下：
< ?xml version="1.0" encoding="UTF-8"?>
< people>
    <listitem>
        <id>1</id>
        <name>"张三"</name>
        <score>90</score>
    </listitem>
    <listitem>
        <id>2</id>
        <name>"李四"</name>
        <score>95</score>
    </listitem>
< /people>
通过以上两个示例，可以看出，xml要比json更复杂，对于配置文件而言，使用json已经足够了。

3，数据库
        数据库也可以存储配置参数，不过这就有些大材小用了。数据库更通常使用情况，是存储结构相同的记录，对于记录的插入、查询等操作，有独特的优势。

综上所述，我对于配置文件格式的选择是：json。

from:http://blog.csdn.net/lintax/article/details/50654953