谷歌Protobuf目前最新3.6.1版本官方支持许多语言：C++、Java、Python、Go等等。除官方支持外这里还列出了许多开源的第三方扩展。
如果官方不支持自己的语言，各种开源库也不能满足需求，那么就需要自己动手编写第三方扩展来支持目标语言。
本文介绍如何为Protobuf编写第三方扩展。注意：
- 本文不讨论谷歌RPC
- 本文假设读者已经了解Protobuf的基本用法，如果你还不会用那么本文不适合你阅读
第1章 了解Protobuf
Protobuf分为编译器和运行时两个部分。本章介绍Protobuf是如何工作的。
1.1 Protobuf是如何运行的
通常我们编写好xxx.proto文件后需要：
- 编译：将proto文件编译生成目标码，不同目标语言的目标码形式都不相同。
以Python为例，protoc --python_out=/path/to/output/ xxx.proto会生成xxx_pb2.py。
protoc可以在GitHub的release页面下载，例如：protoc-3.6.1-linux-x86_64.zip。 - 运行：将生成的目标码拷贝至目标机运行，要求目标机上有对应的运行时。
以Python为例，Python应用程序中可以直接调用：import xxx_pb2。
运行需要依赖Protobuf的Python运行时，可以在release页面下载，例如：protobuf-python-3.6.1.tar.gz。
图1-1 显示了Protobuf是如何工作的，也有的时候编译、运行是在同一个机器上进行的。
1.2 编写第三方扩展的几种方案
读到这应该也猜到了，我们需要编写编译器和运行时两个部分。运行时没什么好说的，可以参考后续的Demo。编译器分为前端和后端两个部分，见图1-2。
谷歌已经实现了编译器前端，在此基础上我们只需要编写编译器后端即可：
- 方案一：在谷歌CommandLineInterface接口的基础上进一步开发，该接口封装了Protobuf编译器前端，在此基础上你可以轻松实现编译器后端；你必须使用C++语言开发后端；
- 方案二：编写插件来实现，Protobuf 3.0开始支持插件，这是目前最推荐的方式；
- 方案三：自己编写编译器前端和后端，如果没有特殊需求的话非常不推荐这种方式，详见下文；
第2章 三种方案快速入门
2.1 方案一：通过C++接口实现编译器后端（不推荐）
早期Protobuf 2不支持插件，因此一些较老的开源项目是使用此方案，如：
- protobuf-c
Protobuf 3开始已经支持插件了，我们推荐使用插件实现，本节的技术点算是过时了。因此这一节的内容被我移到这篇文章了。
2.2 方案二：通过编写插件实现编译器后端（推荐）
编译器后端无非就是获取proto语法树，然后进行生成。在方案一中，语法树是通过C++的一个类来表达的，这样就导致后端代码需要依赖谷歌C++的头文件和库，兼容性较差。
而方案二是通过proto数据流来表达语法树的，后端只要依赖相应语言的Protobuf库即可。这是兼容性最好的方案。由于Protobuf官方就支持：C++、Dart、Go、Java、Python、Ruby、C#、OC、Javascript、PHP，因此无论使用上述哪种语言都可以用来开发编译器后端插件。
2.2.1 一个哲学概念
proto代码定义的是信息的模型，例如下面一段proto代码定义的就是人的信息模型：
syntax = "proto3";
package demo;
message Person {
string name = 1;
int32 id = 2;
string email = 3;
}
而这段信息模型对应的一个可能的信息内容是：
张三, 112233, [email protected]
这样我们就知道信息模型是信息内容的抽象泛化，它们处于不同层次。就好像我们可以通过橡皮泥模子捏出各种颜色的橡皮泥。那么信息模型就好比橡皮泥模子，而信息内容就好比捏出来的橡皮泥。
然而proto代码自身也可以看做是信息，它也能有对应的模型，即：proto代码是proto代码的模型，这听起来真的很绕，自己怎么就成了自己的模型了呢。其实更详细的说应该是：有一种特殊的proto代码，它是其它任意proto代码的模型，这个特殊的proto代码就是descriptor.proto。这真的很哲学，从某角度来看descriptor.proto也是proto代码，它和普通proto代码是同一个层次的；但从另一个角度来看descriptor.proto能作为所有proto代码的模型，它又和普通proto代码不在同一个层次。
descriptor.proto的这种现象在计算机科学中叫做「元（meta）」，例如：
- 在Python中我们用一个类来定义其它类，这叫元类
- 在Lua中我们用一个表来定义其它表，这叫元表
- 类似的词汇你可能还听过很多，例如：元编程
几乎毫无例外的，各个技术领域出现的「元」的概念都成为最难理解的知识点之一，元本身的概念超出了本文范围。
2.2.2 插件的运行流程
在执行protoc编译的时候，命令行是这样写的：protoc -python_out=./ *.proto，Protobuf原生支持Python所以认识-python_out，这表示把当前目录下所有proto都编译成python。如果我们命令行这样写：protoc -xxx_out=./ *.proto，由于不认识xxx，于是protoc会在PATH路径下寻找一个叫做protoc-gen-xxx的可执行文件。而protoc-gen-xxx就是我们要实现的插件。
插件的运行流程如图：
- 我们只需要关注步骤3.1~3.5，其余步骤是谷歌protoc完成
- CodeGeneratorRequest和CodeGeneratorResponse对象定义在plugin.proto里面
- FileDescriptor代表了一个proto文件，定义在descriptor.proto里面
2.2.3 插件具体实现代码
本章概述就说了插件可以通过多种语言（Python、Java、C#等）实现，这里我们以Python为例。实现涉及到的主要类为：
- CodeGeneratorRequest对应：
from google.protobuf.compiler.plugin_pb2 import CodeGeneratorRequest - CodeGeneratorResponse对应：
from google.protobuf.compiler.plugin_pb2 import CodeGeneratorResponse - FileDescriptor对应：
from google.protobuf.descriptor import FileDescriptor
一个简单的Demo代码如下，将代码命名为protoc-gen-hello，赋予可执行权限，然后放置到PATH路径下：
#!/usr/bin/env python3
import sys
from google.protobuf.compiler import plugin_pb2
# 3.1 读取二进制
input_data = sys.stdin.buffer.read()
# 3.2 反序列化
req = plugin_pb2.CodeGeneratorRequest.FromString(input_data)
# 3.3 根据业务需求具体实现
# req.proto_file[0]是FileDescriptor类型的对象
# 正常业务肯定要通过req.proto_file[0]读取proto代码的信息，然后根据具体业务需求解析
# 但这段代码只是为了简单演示，就不读取了
# 3.4 构造CodeGeneratorResponse对象
# 下面这段逻辑说明，不管输入的proto如何
# 本插件都会输出aaa.txt和bbb.txt文件，文件内容都是hello
resp = plugin_pb2.CodeGeneratorResponse()
resp.file.add()
resp.file[0].name = 'aaa.txt'
resp.file[0].content = 'hello'
resp.file.add()
resp.file[1].name = 'bbb.txt'
resp.file[1].content = 'hello'
# 3.5 将CodeGeneratorResponse序列化成二进制后打印
sys.stdout.buffer.write(resp.SerializeToString())
为了运行这段代码，我们的命令是：protoc --hello_out=./ *.proto，这样protoc会去寻找一个叫做protoc-gen-hello的可执行文件。
2.3 方案三：自己编写编译器前端、后端
此法风险和难度比较大：
- 需要开发者熟练掌握编译原理
- 谷歌并没有对此方案提供任何技术支持
- Protobuf有一些隐含语法，这部分并没有在官方文档中说明，让此方案的兼容性得不到保障
如果有特殊需求才考虑此法：
- 有proto文件热加载需求，即希望应用能够直接加载proto文件
目前也有一些开源库使用此方案：
- https://github.com/dcodeIO/protobuf.js
2.4 方案对比
方案一只能通过C++实现。如果不是遗留项目，方案一没有什么优势。
方案二可选开发语言多样，推荐使用。
方案三难度最大，基本只有特殊需求、学习研究会考虑此法。
第三章 Protobuf插件开发详解
在2.2节中已经介绍了基本内容，因为从Protobuf 3开始这是最常用的方法，所以这里花一个章节的篇幅详细介绍。
本章以Python语言为例编写一个简易的Protobuf插件，该插件的名字是protoc-gen-lint，用来检测proto代码是否有潜在问题。我们知道一个成熟的lint工具检测内容是非常多的，甚至包括英语单词拼写是否正确，但是本章作为教学例子，只做了非常有限的几个功能。
本章例子的检测的内容是：
- 判断message名是否为驼峰命名法，即不能含有下划线、不能有两个连续大写字母出现
- 等等
3.1 代码如下
#!/usr/bin/env python3
import sys
from google.protobuf.compiler import plugin_pb2
input_data = sys.stdin.buffer.read()
req = plugin_pb2.CodeGeneratorRequest.FromString(input_data)
resp = plugin_pb2.CodeGeneratorResponse()
for f in req.proto_file:
log = ''
for m in f.message_type:
if '_' in m.name:
# 判断是否存在下划线
log += '{0}中的{1}不符合驼峰命名法\n'.format(f.name, m.name)
break
else:
# 判断是否存在连续的大写字母
for i in range(len(m.name) - 1):
if m.name[i].isupper() and m.name[i+1].isupper():
log += '{0}中的{1}不符合驼峰命名法\n'.format(f.name, m.name)
break
if log != '':
# 若确实存在问题，则将报错信息输出到.lint.txt后缀的文件中
resp.file.add()
resp.file[-1].name = f.name.rstrip('.proto') + '.lint.txt'
resp.file[-1].content = log
sys.stdout.buffer.write(resp.SerializeToString())