unix文本文件格式的约定

• 如果可能，以新行符结束的每一行只存一个记录。这样用文本流工具提取记录就非常容易。为了和其他操作系统交换数据，最好让文件格式的解析器不受行结束符是ＬＦ还是ＣＲ－ＬＦ的影响。在这种格式中，习惯上忽略结尾的空白，以防范常见的编辑错误。

• 如果可能，每行不超过８０个字符。这样使格式可以在普通尺寸的终端视窗上浏览。如果很多记录一定要超过８０个字符，考虑使用分节格式

• 使用“＃”引入注释。能在数据文件中嵌入注解和说明会非常好。最好是把它们作为文件结构的一部分，便可被知道这种格式的工具保存下来。对于解析时不保存的说明，惯例上采用“＃”作为起始字符。

• 支持反斜杠约定。支持嵌入不可打印控制字符的最自然方法，就是解析ｃ语言风格的反斜杠转移－－\n表示新行，\r表示回车，\t表示制表符，\b表示退格，\f表示走纸。。。。。

• 在每一行记录的格式中，使用冒号或任何连续的空白作为字段分隔符。冒号约定似乎起源于unix的口令文件。如果某个字段必须包含风格符，使用反斜杠前缀进行转移。

• 不要过分区别Tab和whitespace。否则，当用户编辑器的Tab设置不同时，会产生很多令人头痛的麻烦。这条原则是治愈头痛的良方。况且，一般说来，眼睛很难区别Tab和whitespace。仅使用Tab作为分隔符尤其容易产生问题：相反，允许连续使用的Tab和空格作为分隔符却非常有效。

• 优先使用十六进制而不是八进制。和三位的八进制数字相比，两位或四位的十六进制数字更容易直观地与字节以及今天的32位和64位字对应起来；而且，效率或多或少高一点。强调该准则是因为od（1）等一些较老的unix工具违反了这条准则。这是较老的PDP小型机的机器语言指令字段大小所产生的历史遗留问题。

• 对于复杂的记录，使用“节”格式：一个记录若有多行，就使用%%\n或%\n作为记录分隔符。在人们肉眼检查文件时，这种分隔符时非常有用而且直观的边界标志。

• 在节格式中，要么每行一个记录字段，要么让记录格式和RFC822电子邮件头类似(参考http://blog.csdn.net/qaqwe/article/details/38538629)，用冒号终止的字段名关键字作为引导手段。当字段经常空缺或者超过80个字符，或则当记录很稀疏时，使用第二种方案。

• 在节格式中，支持连续行。解释文件时，或者抛弃空格符之后的反斜杠，或则将空格符之后的新行符解释为当个空格；这样一个很长的逻辑航就能够折叠成多个很短的物理行。在这些格式中，习惯傻瓜忽略结尾的空格，可防止常见的编辑错误。

• 要么包含一个版本号，要么将格式设计成相互独立的子描述字节块。哪怕只存在一丁点格式发生改变或扩展的可能性，也要包含一个版本号，这样代码才能够有条件地在所有版本上正确运行。换句话说，将格式设计成描述字节块，无需立即破坏旧代码就可以添加新的快类型。

• 注意浮点取整问题。由于转换库质量的不同，浮点数从二进制格式转换成文本格式在转换回二进制格式时可能会有精度损失。如果列集/散集的结构中包含浮点数，应该从两个方向都测试一下转换。如果看上去任何一个方向的转换都可能存在取整误差，做好将浮点字段作为未处理的二级制格式或字符串编码形式转储的准备。如果在c语言或调用了c printf/scanf的语言中编程，c99的%a指示符可以解决这个问题。

• 不要仅对文件的一部分进行压缩或二进制编码。