本文档将回答一些关于协议缓冲区开源项目的常见问题解答。如果您还有未在此解答的问题，请加入论坛进行提问！
常规
您为何释放协议缓冲区？
导致这种情况的原因有以下几种：
- 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 员工添加的功能。我们甚至定期拒绝我们自己的团队成员添加的功能。
不过，我们仍然希望了解您的想法。加入协议缓冲区论坛，告诉我们。我们或许可以帮您找到一种方法，在不更改底层库的情况下执行所需的操作。或者，我们可能认为您的地图项非常有用或太简单，应该添加。