你会用Protocol Buffers吗？这两天在我常去的网站上都有关于Protocol Buffers的新闻，光看新闻里吹嘘得这么
你会用Protocol Buffers吗？
这两天在我常去的网站上都有关于Protocol Buffers的新闻，光看新闻里吹嘘得这么好，感觉有点不过瘾，于是抽了点时间来了解整个项目。下面是我个人对Protocol Buffers的理解和看法：
?
1、项目背景
我觉得该项目的主要目的是用于处理复杂数据结构定义，这是XML文件所不能满足的；而数据文件大小和读写速度并不是那么重要；再说google并没有给出这个测试报告，具体有多大的优越性，这个还得打个问号（当然，我是相信google声称的文件的大小要小3-10倍，解析速度要快20-100倍）。
?
2、项目初探
Protocol Buffers的确很轻量级，拿Java来说，除了protocr外，源代码也就20来个；定义数据结构的描述文件也很简单易懂，基本上不需要注释说明；通过描述文件生成的源码会将数据结构封装成类，同时会提供一个静态Builder类，数据结构和数据组装的Builder都有明确的情况下，数据解析装配的数据应该会有所提升，还不需要其它工具的辅助。看来自己了解自己才是王道！对于文件大小这一点，对比一下两类文件就很明显，少了XML文件的复杂节点信息，存储的数据量小了，当然文件大小也就小了。
?
3、Protocol Buffers数据语言不是标准
现在在用Protocol Buffers的也就是google，用户群很小，外加不是标准，其它的一些组织还不一定卖google的帐；即使它有这么多优势在这里，但它是不是项目比不可少的，还值得讨论。
拿当前软件开发现状来说，配置文件已经是满天飞了，每个项目都有一大堆的配置问题，Java这边的趋势是用Annotation来替代配置，而ROR也是用约定来消除一些不必要的配置；Protocol Buffers还能在那些地方派上用场呢？
a.配置文件——感觉大材小用，一般的配置信息的数据结构都不复杂，对读写时的性能要求也不高；
b.数据文件——应该还是与数据库无法比，安全性，可操作性，可靠性都存在不足。
?
因此，除非是一定要在项目中处理复杂的数据结构文件时，可以考虑Protocol Buffers；否则，观望……
在SOA越来越热的今天。我想这个东东，终有一天会大有用途。
有时间研究下，在项目中取代xml。 9 楼 numenzq 2008-07-11 引用虽然Protocal buffers可能效率上会好一点，但是它的配置文件结构不如xml清晰，可读性效差！
不会吧，可读性差？比如下面的例子，你可以看作是定义个Person类，有两个必填字段id和name，还有一个可选字段email，然后定义了一个枚举类型PhoneType，还有一个PhoneNumber类及相应属性。
引用
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
10 楼 numenzq 2008-07-11 引用
Protocol Buffers 是不是文本形式?
谁能贴个示例上来啊?
我没google到
Protocol Buffers到底什么样??
不是纯文本形式，就拿google自带的例子来说，输入的数据为：
Enter person ID: 211
Enter name: numenzq
Enter email address (blank for none): numenzq@iteye.com
Enter a phone number (or leave blank to finish): 86-23-12345678
用UE打开该数据文件，内容为：
.
numenzq?numenzq@iteye.com"
86-23-12345678
输入的Id不见了，其他信息都还能看见，中文也没问题，不过中间多了些无法识别的符号，转换成16进制就能看出这些符号是一些标示，比如说第一组数据每个字段后面两字节为10 01，第二组就为10 02，类似这样的东西。 11 楼 stray 2008-07-11 Protocol Buffers我最不看好的一点就是缺少数据校验的能力，就像xml的xsd，而对于网络数据交换的载体来讲，校验却是必不可少的。如果仅仅作为配置文件，我想他绝对比不上xml，因为作为配置文件来讲，解析速度和文件大小就显得不是很重要。对于那些完全不需要校验的场合，我不清楚他相对于json有什么竞争力。
说白了，就是不知道他想取代谁！ 12 楼 numenzq 2008-07-11 引用说白了，就是不知道他想取代谁！
我觉得google把内部数据交换格式的protocal buffers开源了，出来也是给大家多一个选择，而拿XML文件做比较也是因为XML是当下的主流；对于取代谁谁谁的说法，目前还没有感觉到，也没必要想这么复杂，什么能满足我们的需求，我们就用什么呗。 13 楼 sunny_ljiang 2008-07-11 呵呵，我看最关键的问题还是在交互上面，XML文件现在已经成了交互文档事实上的标准，例如两个系统集成，必然涉及数据的相互转换，在这个领域XML已经是被公认了的格式，而google的这个格式即使是性能再好，也代替不了XML文件。 14 楼 soartju 2008-07-11 不过在网络上传输数据，数据的大小，解析速度是很重要的，尤其是大量的数据的情况下 15 楼 neodoxy 2008-07-12 引用虽然Protocal buffers可能效率上会好一点，但是它的配置文件结构不如xml清晰，可读性效差！
XML是对机器友好的,着你都读得懂,还怕读不懂Protocol Buffers么 16 楼 hax 2008-07-13 Protocol Buffers好像是一个二进制协议。自Web Services出现以来，一直有人搞二进制协议，但是始终不成气候，我觉得Google这个也悬。 17 楼 Sam1860 2008-07-13 引用XML是对机器友好的,着你都读得懂,还怕读不懂Protocol Buffers么
2进制才是机器友好的，其他数据格式都是向人类友好过度 18 楼 menlong999 2008-07-13 为什么只做配置文件用？我想google来使用Protocol Buffers，主要是作为数据交换格式，而非配置文件，用作配置文件仅仅是附加的功能而已。
比如rpc，比如在socket中做数据协议，并且提供跨语言。如果一个c++的服务端和java的客户端，用socket来通讯，传统的方式会定义基于c结构体的私有协议（当然也可以用webservice之类，或者基于xml的私有的文本协议），而改用Protocol Buffers，不仅协议简单，易于描述，二进制数据量极小，没有大坨大坨的xml标记，定义为optional的字段可以非常便于扩充和兼容老的协议，并且google所宣称的比xml高的多的效率等等因素，个人认为还是非常不错的数据交换格式。 19 楼 menlong999 2008-07-13 为什么只做配置文件用？我想google来使用Protocol Buffers，主要是作为数据交换格式，而非配置文件，用作配置文件仅仅是附加的功能而已。
比如rpc，比如在socket中做数据协议，并且提供跨语言。如果一个c++的服务端和java的客户端，用socket来通讯，传统的方式会定义基于c结构体的私有协议（当然也可以用webservice之类，或者基于xml的私有的文本协议），而改用Protocol Buffers，不仅协议简单，易于描述，二进制数据量极小，没有大坨大坨的xml标记，定义为optional的字段可以非常便于扩充和兼容老的协议，并且google所宣称的比xml高的多的效率等等因素，个人认为还是非常不错的数据交换格式。 20 楼 Caedmon 2011-09-13 你们都忘了很重要的一点，那就是普通基于TCP/IP协议的应用程序，程序协议都是自己定义的，但是那样的话一旦协议有改动，那就是牵一发而动全身，这个时候你就会明白Google Buffer Protocol的好处了。可维护性，可扩展性是是一个项目很关键的指标
