数据文件元格式

数据文件元格式是一套句法和词法约定，这套约定或者已经正式标准化，或者已经通过实践得到了充分的确定，已有标准服务库来处理列集和散集操作。

UNIX已经形成或采纳了适合多种应用程序的不同元格式。尽可能使用这些元格式（而不是标新立异自己的格式）是个好习惯。第一个好处是使用服务库可以避免编写大量的用户解析代码和生成代码。但最重要的好处还是开发者甚至很多用户都能立即认出这些格式，有亲切感，这就减少了学习新程序的磨合成本(friction cost) 。

在以下讨论中，当我们说到了“传统UNIX工具”时，我们指grep（1）、sed（1）、awk（1）和cut（1）这些文本搜索和变换工具的组合。对以上工具所提倡的面向行格式的解析，Perl和其他脚本通常自带支持功能。

以下就是一些可以作为典范使用的标准格式。

1）DSV风格

DSV代表“分隔符分割值”。（例子，/etc/passed 中使用冒号作为值分隔符的DSV格式）在UNIX中，对字段值可能包含空格的DSV格式，冒号是默认的分隔符。

/etc/passwd格式（每个记录一行，字段用冒号分隔）是UNIX中非常传统的格式，经常用于处理表列数据。其他经典的例子包括描述安全组的/etc/group文件盒在操作系统不同运行级别中控制UNIX服务程序启动和关闭的/etc/inittab文件。

这种风格的数据文件一般应通过反斜杠（\）转义符支持在数据域中包含冒号。更为普遍的是，读取这种文件的代码可通过忽略反斜线定义的换行符支持连续记录，并且允许c风格的反斜杠转义符嵌入非打印字符数据。

当数据为列表、名称（在首字段）为关键字、而且记录通常很短（少于80个字符）时，这种格式最适用。这种格式和传统的UNIX配合的很好。

示例：UNIX口令文件格式

在许多操作系统中，验证用户登录并开始用户会话所必须的用户数据都是不透明的二进制数据库。相反，在UNIX中，这种数据是文本文件，采用一行一条、字段用冒号分隔的记录格式。

以下是几行随机选择的文件行：

----------------------------------------------------------------------

games:*12:100:games:/usr/games;

gopher:*:13:30:gropher:/usr/lib/gopher-data:

ftp:*:14:50:FTP User:/home/ftp:

-----------------------------------------------------------------------

即使不知道字段的语义，我们也能发现这些数据在二进制格式中很难压缩得更紧。要达到冒号分隔符的功能至少需要相同的空间（通常是字节数或NUL）。每个用户的记录要么需要终止符（不太可能比一个新行符更短），要么很浪费地补齐到定长。

如果知道数据的实际语义，则通过二进制编码节省空间的实际可能性几乎不存在。我们可以压缩数字域，把这些数字域的位长缩小到用单字节表示，口令字符串采用8位编码。在本例中，这样可以节省8%左右的空间。

这8%的假定低效率却带给我们很多好处：可以避免武断地限制数字域范围，可以使我们能够使用自己选择的任何老式文本编辑器修改口令文件，而无需编制专用工具来编辑二进制文件（虽然在口令文件这个例子本身，我们需要对并发编辑特别小心），而且，还能够让我们能够用grep（1）这样的文本流工具队用户账号信息进行特别的搜索、过滤和报告。我们的确要十分小心，不要在任何文本字段中嵌入冒号。良好的做法应该是这样：告诉文件先用换码符嵌入冒号再写代码，然后告诉文件读取代码对其解锁。对此，UNIX传统偏爱使用反斜杠。

既然一般情况下很少读取，也不经常修改，所以经济性不是口令文件一开始就要考虑的主要因素。既然文件中的不同数据（特别是用户ID和组ID）不会从原始机器上搬移出去，互用性也不是问题。因此很明显，对口令文件而言，遵循透明性原则才是正确的选择。

2） RFC 822格式

RFC 822格式源于互联网电子邮件信息采用的文本格式：（在被RFC2822取代前）RFC一直是描述这种格式的只要互联网RFC。MIME（多用途网际邮件扩充协议）提供了RFC格式信息中嵌入类型化二进制数据的方法。

在这些元格式中，记录属性每行存放一个，以类似邮件头字段名的标记命名，用冒号后接空白作为结束。字段不得包含空格：通常用横线代替空格。改行的其余部分都是属性值。除了结尾的空格和换行。以Tab（制表符）或whitespace（空格符）开始的物理行被解释为当前逻辑行的延续。空行可能被解释为记录的结束，也可能是表明接下来是非结构化的文本。

在unix中，对那些带属性的或任何与电子邮件类似的信息，这都是传统而且首选的文本化格式。一般说来，这种格式适合具有不同字段集合而字段中数据层次又扁平（没有递归或树形结构）的记录。

Usenet使用的就是这种格式，万维网使用的http1.1（以及后续版本）也使用这种格式。这种格式非常便于人工编辑。在属性搜索上，传统的unix搜索工具仍能使用，只不过寻找记录边界要比“每行一个记录”的格式要多费些周折。

3） cookie-Jar格式

cookie-jar格式是fortune（1）程序为随机引用数据库而使用的一种格式。这种格式很使用记录只是一堆结构化文本的情况。这种格式简单使用跟随%%的新行符（或者有时只有一个%）作为记录分隔符。例是来自电子邮件签名引用文件的部分例行。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

“Among the many misdeeds of british rule in india,,.............................................................................."

--Mohandas Gandhi,"An Autobiography",pg 446

%

The people of the various provinces are ..........................

--..

%

.........

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

寻找记录分隔符时接受%后的空格是个好做法，有助于解决人为编辑的错误。更好的做法就是使用%%，并忽略从%%到行结束处的所有文本。
cookie-jar分隔符最初是“%%\n”，我当时希望找个能比“%”更显眼的东西。事实上，任何“%%”之后的内容都作注释处理（至少我是这样写的）。

--ken Arnold

简单的cookie-jar格式适用于词以上结构没有自然顺序，而且结构不易区别的文本段，或适用于搜索关键字而不是文本上下文的文本段。

4) Record-Jar 格式

cookie-jar记录分隔符和RFC822记录元格式结合的非常好，产生一种我们称之为“record-Jar”的格式。如果文本要支持显示字段数目可变的多重记录，众望所归的方法就是采用下例类似的格式。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Planet : Mecury

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

4）XML

XML语法类似HTML，非常简单--尖括号括起的（<>）标签和“&”记号引导字面值序列。它几乎和纯文本标记一样简单，但又能表达递归嵌套的数据结构。XML只是一种低级的语法，需要文档类型定义和相关的应用逻辑赋予其语义。

XML非常适合复杂的数据格式，尽管对简单的数据来说未免大材小用。它尤其适合那些RFC 822元格式不太好处理、有复杂递归或嵌套数据结构的格式。对这种格式的详细介绍，可参见《XML in a Nutshell》一书【Harold Means】。

XML 的一个优势在于经常无需知道数据语义，仅通过语法检查就能发现形式不良、损坏或错误生成的数据。

xml最严重的问题是无法很好和传统的unix工具协作。读取XML格式的软件需要XML解析器，这就意味着需要庞大复杂的程序。同样，xml本身也非常庞大，要在所有的标记中找到数据很困难。

xml占据明显优势的应用领域是文档文件的标记格式。在大块纯文本中，此类文件的标记往往比较稀疏，因此unix传统工具仍能出色完成简单的文本搜索和转换。

这些领域间有一个很有趣的沟通桥梁，就是PYX格式--面向行的xml转换，可有传统的unix面向行文本工具进行修改，然后再无损转换成xml。在网上搜索“Pyxie”即可找到相关资源。xmltk工具包则采取相反的方法，提供类似grep（1）和sort（1）的面向流工具来过滤xml文档；在网上搜索“xmltk”即可找到。

选择xml可以简化问题，也可能使问题复杂化。对它的大肆捧吹很多，但不要不加批判地采用或拒绝，否则就会成为时尚的牺牲品。请谨慎选择牢记KISS原则。