注意:此网站已被弃用。该网站将在 2023 年 1 月 31 日后关闭,而流量将重定向到位于 https://protobuf.dev 的新网站。在此期间,我们仅会针对 protobuf.dev 进行更新。

常见问题解答

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

本文档将回答一些关于协议缓冲区开源项目的常见问题解答。如果您还有未在此解答的问题,请加入论坛进行提问!

常规

您为何释放协议缓冲区?

导致这种情况的原因有以下几种:

  • Google 内部几乎所有人都使用协议缓冲区。我们还有许多其他项目要使用开放源代码进行发布,因此需要使用协议缓冲区,因此需要先发布协议缓冲区。事实上,一些技术已经在某种程度上开放了 - 如果您深入研究 Google AppEngine 的代码,可能会找到一些代码。
  • 我们想提供接受协议缓冲区和 XML 的公共 API,因为这种方式更高效,而且我们只是要将 XML 转换为协议缓冲区。
  • 我们认为 Google 之外的人可能会发现协议缓冲区很有用。
  • 将协议缓冲区转换为我们很乐意发布的表单是一个有趣的 20% 项目。

为什么要发布第一个版本 2?版本 1 发生了什么变化?

协议缓冲区的初始版本(又称“Proto1”)从 2001 年初开始在 Google 开发,历经多年发展,在有人需要并且愿意自己动手推出时推出新功能。就像以这种方式制作的任何东西一样,有些混乱。我们发现,按原样发布代码并不可行。

版本 2(“Proto2”)是一个完全的重写,但它保留了大部分设计并使用了 Proto1 的许多实现想法。部分功能已添加,部分功能已移除。但最重要的是,相关代码会被清理,且对尚未开源的 Google 库没有任何依赖项。

为何使用“协议缓冲区”?

该名称源自这种格式的早期阶段,那时我们尚未使用协议缓冲区编译器来生成类。当时有一个名为 ProtocolBuffer 的类,它实际上充当单个方法的缓冲区。用户需要通过调用 AddValue(tag, value) 等方法,向此缓冲区中分别添加标记/值对。原始字节存储在缓冲区中,该缓冲区在构建消息后可以写出。

从那以后,名称的“buffers”部分已失去意义,但仍是我们使用的名称。如今,人们通常使用术语“协议消息”来引用抽象消息,使用“协议缓冲区”来指代消息的序列化副本,使用“协议消息对象”来指代表示已解析消息的内存对象。

Google 是否拥有协议缓冲区的专利?

Google 目前还没有关于协议缓冲区的专利,我们很乐意解决有关协议缓冲区和人们可能拥有的专利的任何问题。

类似技术

协议缓冲区与 XML 有何不同?

请参阅概览页面上的回答

协议缓冲区与 ASN.1、COM、CORBA、Thrift 等有何区别?

我们认为所有这些系统都有各自的优缺点。Google 在内部依赖于协议缓冲区,它们对我们成功起着至关重要的作用,但这并不代表它们是解决所有问题的理想解决方案。您应该根据自己的项目来评估每种替代方案。

但需要注意的是,其中一些技术既定义了交换格式,又定义了 RPC(远程过程调用)协议。协议缓冲区只是一种交换格式。RPC 非常易于使用,并且确实对定义 RPC 服务的支持有限,但并不依赖于任何一种 RPC 实现或协议。

贡献

我可以向协议缓冲区添加对新语言的支持吗?

是的!事实上,协议缓冲区编译器的设计使得您可以轻松编写自己的编译器。请查看 CommandLineInterface 类,该类是 libprotoc 库的一部分。

我们建议您为新语言创建代码生成器和运行时库。为此,您应该启动自己的独立项目 - 这样,您就可以自由地管理项目,而不会被我们的发布流程阻止。请同时加入协议缓冲区论坛,向我们报告您的项目;我们很乐意链接到您的项目并帮助您解决设计问题。

我可以为协议缓冲区贡献补丁程序吗?

是的!请加入协议缓冲区论坛,与我们探讨相关事宜。

我可以向协议缓冲区添加新功能吗?

有可能需要。我们始终喜欢建议,但对于添加内容,我们非常谨慎。多年来我们了解到,有很多人对新功能很感兴趣。其中大多数功能在特定情况下非常有用,但如果我们接受了所有这些功能,协议缓冲区就会变得膨胀、混乱。所以我们必须非常挑剔在评估新功能时,我们会寻找广泛使用或极为简单的功能,或者希望两者兼而有之。我们会定期拒绝 Google 员工添加的功能。我们甚至定期拒绝我们自己的团队成员添加的功能。

不过,我们仍然希望了解您的想法。加入协议缓冲区论坛,告诉我们。我们或许可以帮您找到一种方法,在不更改底层库的情况下执行所需的操作。或者,我们可能认为您的地图项非常有用或太简单,应该添加。