历史

了解 protobuf 的创建原因以及随着时间推移改变它的决策，可以帮助您更好地使用该工具的功能。

为什么要发布 Protocol Buffers？

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

Protocol buffers 在 Google 内部的许多项目中使用。我们还有其他项目想要开源，这些项目使用了 protocol buffers，所以为了做到这一点，我们需要首先发布 protocol buffers。事实上，这项技术的某些部分已经进入了开源领域；如果您深入研究 Google AppEngine 的代码，您可能会发现其中的一些。

我们想提供公共 API，这些 API 既接受 protocol buffers 也接受 XML，这既是因为它更有效率，也是因为无论如何我们在后端都会将 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 实现或协议绑定。