数据的存储与传输

设计原则（互用性、透明性、可扩展性和存储/事务处理的经济性）

设计将应用数据存储在永久存储器中的文件格式，和在协作程序中（可能会通过网络）传递数据和命令的应用协议。这两者都与内存数据结构的序列化有关。为了便于数据的传输与存储，像链表这样的数据结构，其可遍历的准空间部署需要平整化成字节流表达，以便日后能从这个表达式恢复数据结构。序列化（保存）操作有时也称为列集(marshaling)，其反向操作（载入）称为散集（unmarshaling）。这些术语通常使用在面对对象的语言中，如c++，Python或则java中对对象的操作，但同样可用于其他一些操作，如图形编辑器将图形文件载入内存并在修改后存盘。

c与c++程序员要维护的代码中，进行列集与散集操作的特别代码占了很大比例，Python和java等现代语言往往内置了散集与列集函数，可应用于任何对象或者代表对象的字节流，大大减少了工作量。

但是种种原因，这些天真的方法不尽人意，原因既包括机器件的互用问题，也包括对其他工具不透明这一负面特征。如果应用协议时网络协议，处于经济性考虑，可能会要求内部数据结构（比如携带源地址和目标地址的信息）不是序列化成单个的大型数据包（blob），而是序列化成接受设备可拒绝的一系列尝试性处理事件或信息（这样一来，如果目的地址无效，则整块信息就会被拒收）。

综合上诉，互用性、透明性、可扩展性和存储/事务处理的经济性--这些都是设计文件格式和应用协议时需要考虑的重要方面。互用性和透明性要求我们在此类设计中要重点考虑数据表达的清晰问题，而不是首先考虑实现的方便性和可能达到的最高性能。既然二进制协议很难扩展和干净的抽取子集，可扩展性当然也青睐文本化协议。事务处理的经济性有时会则会提出相反的要求--但我们应看到，首先考虑这个标准就是一种过早优化，不这么做往往是明智的选择。

文本化（数据）

管道和套接字既可以传输文本也可以传输二进制数据。但是我们将在第七章看到的例子都是文本化的，理由非常充分：那就是我们在第一章引用的Doug Mcllroy的建议。文本化是非常有用的通用格式，因为人无需专门工具就可以很容易地读写和编辑文本流，这些格式是透明的（或可以设计成透明的）。

同时，正是文本流的限制帮组强化封装：因为文本流不鼓励内容丰富、编码结构密集的复杂表达，也不提倡程序互相干涉内部状态。

当你很想设计一个复杂的二进制文件格式，或一个复杂的二进制应用协议时，通常明智的做法是躺下来等待这种感觉的过去。如果担心性能问题，就在应用协议之上或之下的某个层面上压缩文本协议流，最终产生的设计会比二进制协议更干净，性能也更好（文本压缩起来更好更快）。

使用二进制协议的唯一正当理由是：如果要处理大批量的数据集，因而确实关注能否在介质上获得最大位密度，或是非常关心将数据转化为芯片核心结构所必须的时间或指令开销。大图像和多媒体数据的格式有时可以算是前者的例子。对延时有严格要求的网络协议有时则可以算是后者的例子。

当找到一种极端情况，有足够理由使用二进制文件格式或协议时，需仔细考虑扩展性，并在设计中为以后发展留出余地。