Google 的二进制编码格式：Protocol Buffers

Google 不久前开源了一种数据交换格式——Protocol Buffers。在它语焉不详的名字背后，藏着的是：

• 一种描述数据格式的 IDL
• 对 IDL 所描述的格式进行编码的一种二进制编码方案
• 通过代码生成器实现的数据绑定支持，Google 提供了 C++、Python、Java 实现

它的 IDL 用来描述数据格式，下面是来自Protocol Buffers 项目网站的例子： <pre id="qz4x11">message Person { <br id="qz4x12"></br> required int32 id = 1; <br id="qz4x13"></br> required string name = 2;<br id="qz4x14"></br>  optional string email = 3; <br id="qz4x15"></br>} 要明确指定字段名称对应的序号（称为“tag”），才能在以后变更格式。如果用自动分配的序号，对格式的更改会引起麻烦（比如在中间插入一个新字段）。为什么呢？因为在二进制格式，tag 是用来说明某段字节编码所表示的（协议描述里的）字段的。明确地分配 tag 序号，搭配上忽略未知 tag 的规则，在变更格式的时候就可以从容增加字段而不影响已有字段。 格式描述保存在.proto 文件里，编译成源代码之后使用。Protocol Buffers 发布的时候已经包括了对 C++、Python 和 Java 的支持。对其他语言的支持也正在进行之中，例如Ruby、Erlang、Perl、Haskell 等等。有意增加其他语言支持的人都应该会很高兴有人已经将.proto 文件的语法反向工程成了EBNF 。

语言支持就是把.proto 文件转换成目标语言的代码，组成映射到.proto 文件所定义格式的一些类。有了语言支持就能从二进制数据中重组出对象，修改里面的字段，然后把对象的状态重新序列化成二进制格式。

一如以往Google 发布新项目的情况， Protocol Buffers 也激起了不小的骚动，占据了不少博客帖子。 Google 的官方博客也解释了开发Protocol Buffers 的原因，里头曾提到XML 用作编码格式效率非常低。这种说法引来了潮水般的博客贴——有些认为Protocol Buffers 意味着XML 的结束，有些认为Protocol Buffers 不如XML。 Ted Neward 对现状做了如下总结：

总而言之，如果你想要松散耦合的终端程序，保留最大的灵活性，那就接着用 XML，包装进 SOAP 封包或者符合底层传输（也就是说 HTTP，因为依赖其他传输形式的 REST 还没有真正被定义）要求的 RESTful 封包。 如果你需要二进制格式，Protocol Buffers 是其中一个答案……但 ICE 也是，甚至 CORBA（虽然参与者日少已经使它失去了吸引力）。不要仅仅由于贴上了 Google 的商标，就忽略了对技术优势和劣势的分析。

与 XML 或 JSON 的比较很容易使人忽略 Protocol Buffers 其实是对现有技术的重新实现。除了前面已经提到的，还有一项广泛使用的技术—— ASN.1 也是其竞争对手。ASN.1 虽然已经存在了几十年，却不怎么显山露水。从用 ASN.1 描述的格式名单来看，这是非常奇怪的一件事情，请看看其中的几种格式：

• X.509 证书（许多系统的 PKI 都使用，包括 SSL）
• LDAP
• Cryptographic Message Syntax（CMS）用于电子邮件加密
• PKCS#1，用于 RSA 密匙
• 3G 电话网络

ASN.1 的用途广泛；例如，日常的电信通信就用到 ASN.1 编码的数据。ASN.1 基于与 Protocol Buffers 相似的概念——它也用 IDL 描述数据，用编译器为目标语言生成代码。但两者有一处关键差别—— ASN.1 允许多种编码方法，可以根据用途来选择。 Canonical Encoding Rules（CER）是其中的一种编码方式，其强制实行严格的编码规则，这对数字签名来说很关键，因为稍有差异就意味着很大的区别，其他可用的编码方式还有 Packed Encoding Rules（PER）。 XML Encoding Rules（XER）允许将数据编码成 XML，ASN.1 也就成了与 XML Schema 并列的选项。 Fast Web Services 技术就能把 XML Schemas 映射成 ASN.1，然后用 ASN.1 在端点之间进行编码效率更高的通信。

还有一种技术与 Google 的 Protocol Buffers 相似，那就是 Facebook 的 Thrift ，它的工作原理也差不多（见Protocol Buffers 与Thrift 的逐点对比）。Binary XML 也是一种不太成功的类似技术，它已经在XML 界酝酿了很久，但成功仍然遥遥无期。Erlang 的创造者Joe Armstrong 也在回答关于Protocol Buffers 的问题时提到可以把UBF 用作一种二进制格式直接传输程序字节码，无需解析。

这些技术共同的目标都是提高效率。有人可能觉得在线路上传输的数据量不是问题，因为有数据压缩技术。然而压缩/ 解压缩只是在使用数据前后执行的额外步骤，实际的解析过程中使用的仍然是没压缩的大量数据。对于XML 来说，意味着一次又一次重复地读取同样的元素标签——简直与Protocol Buffers 的数字标签没法比。当然，改善的程度取决于实际的格式。主要由字符串组成的格式效果就没有主要由数字数据组成的格式那么显著。

Mark Pilgirm 也整理了一份对Protocol Buffer 的反响。还有一个值得注意的方面，从Protocol Buffers 身上可以看出一个RPC 系统的蛛丝马迹。虽然目前还没有向大众公开，但在 Steve Vinoski 的博客上有一位 Google 的员工提到，Google 内部确有这样一个 RPC 系统在担当重任。

你是否遇到过出于效率原因而考虑二进制格式的时候？如果是，你是自己搞一套还是找现有的技术？

阅读英文原文： Google Introduces Binary Encoding Format: Protocol Buffers