历史

了解 protobuf 的创建原因以及随时间发生的变化，有助于您更好地利用该工具的特性。

为什么发布 Protocol Buffers？

我们发布 Protocol Buffers 有几个原因。

Protocol buffers 在 Google 的许多项目中使用。我们还有其他一些项目希望开源，但这些项目使用了 protocol buffers，因此，为了做到这一点，我们首先需要发布 protocol buffers。事实上，这项技术的一部分已经公开；如果您深入研究 Google AppEngine 的代码，可能会找到一些。

我们希望提供接受 protocol buffers 和 XML 的公共 API，这既是因为它更有效率，也是因为我们最终都会在后端将其 XML 转换为 protocol buffers。

我们认为 Google 以外的人可能会觉得 protocol buffers 有用。将 protocol buffers 整理成我们乐于发布的形态是一项有趣的副项目。

为什么第一个发布版本是 2？版本 1 发生了什么？

Protocol buffers 的初始版本（“Proto1”）于 2001 年初开始开发，并在多年中不断演进，每当有人需要新功能并愿意为此付出努力时，它就会涌现出新功能。与以这种方式创建的任何事物一样，它有点混乱。我们得出结论，无法以现有形式发布代码。

版本 2（“Proto2”）进行了彻底重写，尽管它保留了大部分设计，并沿用了 Proto1 的许多实现思路。添加了一些功能，移除了一些功能。但最重要的是，代码得到了清理，并且不再依赖尚未开源的 Google 库。

为什么叫做“Protocol Buffers”？

这个名字起源于该格式的早期，那时我们还没有 protocol buffer 编译器来为我们生成类。当时，有一个名为 ProtocolBuffer 的类，它实际上充当了单个方法的缓冲区。用户可以通过调用 AddValue(tag, value) 等方法单独向此缓冲区添加标签/值对。原始字节存储在缓冲区中，一旦消息构建完成，就可以将其写出。

从那时起，“buffers”这个名字的含义已经丢失，但它仍然是我们使用的名称。如今，人们通常使用“protocol message”来指代抽象意义上的消息，“protocol buffer”来指代消息的序列化副本，而“protocol message object”则指代表示已解析消息的内存对象。

Google 是否拥有 Protocol Buffers 的专利？

Google 目前没有任何已授权的 protocol buffers 专利，我们乐于解决人们可能对 protocol buffers 和专利产生的任何担忧。

Protocol Buffers 与 ASN.1、COM、CORBA 和 Thrift 有何不同？

我们认为所有这些系统都有其优点和缺点。Google 在内部使用 protocol buffers，它们是我们成功的关键组成部分，但这并不意味着它们是解决所有问题的理想方案。您应该根据您自己项目的具体情况来评估每种替代方案。

不过，值得注意的是，其中一些技术同时定义了交换格式和 RPC（远程过程调用）协议。Protocol buffers 仅仅是一种交换格式。它们可以很容易地用于 RPC — 事实上，它们确实对定义 RPC 服务有有限的支持 — 但它们不与任何特定的 RPC 实现或协议绑定。