历史

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

你们为什么要发布 Protocol Buffers？

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

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

我们希望提供公共 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 实现或协议绑定。