#include<iostream>
#include<fstream>
#include"contact.pb.h"
using namespace std;void AddPeopleInfo(contacts::PeopleInfo* info)
{info->set_name("lisi");info->set_age(18);phone::Phone* newphone=info->add_phone();newphone->set_numbers("1234567890");
}int main()
{contacts::Contacts contacter;fstream input("contacts.bin",ios::in | ios::binary);if(!input){cerr<<"Creat A New File"<<endl;}else if(!contacter.ParseFromIstream(&input)) {cerr<<"Parse Error"<<endl;input.close();return -1;}AddPeopleInfo(contacter.add_people());fstream output("contacts.bin",ios::out|ios::binary|ios::trunc);if(!contacter.SerializeToOstream(&output)){cerr<<"write error"<<endl;input.close();output.close();return -1;}cout<<"write success"<<endl;return 0;
}

2.3.2 通讯录 2.0 的读取实现

#include<iostream>
#include<fstream>
#include"contact.pb.h"
using namespace std;
int main()
{contacts::Contacts contacter;fstream input("contacts.bin",ios::in | ios::binary);if(!contacter.ParseFromIstream(&input)) {cerr<<"Parse Error"<<endl;input.close();return -1;}for(int i=0;i<contacter.people_size();i++){const contacts::PeopleInfo& people=contacter.people(i);cout<<people.name()<<":"<<people.age()<<":";for(int j=0;j<people.phone_size();j++){const phone::Phone& numer=people.phone(j);cout<<numer.numbers()<<":";}cout<<endl;}return 0;
}

3. enum 类型

3.1 定义规则

语法⽀持我们定义枚举类型并使⽤。在.proto⽂件中枚举类型的书写规范为：

枚举类型名称：

使⽤驼峰命名法，⾸字⺟⼤写。 例如： MyEnum

常量值名称：

全⼤写字⺟，多个字⺟之间⽤ _ 连接。例如： ENUM_CONST = 0;

我们可以定义⼀个名为 PhoneType 的枚举类型，定义如下

要注意枚举类型的定义有以下⼏种规则：

1. 0 值常量必须存在，且要作为第⼀个元素。这是为了与 proto2 的语义兼容：第⼀个元素作为默认 值，且值为 0。

2. 枚举类型可以在消息外定义，也可以在消息体内定义（嵌套）。

3. 枚举的常量值在 32 位整数的范围内。但因负值⽆效因⽽不建议使⽤（与编码规则有关）。

3.2 定义时注意

将两个 ‘具有相同枚举值名称’ 的枚举类型放在单个 .proto ⽂件下测试时，编译后会报错：某某某常

量已经被定义！所以这⾥要注意：

• 同级（同层）的枚举类型，各个枚举类型中的常量不能重名。

• 单个 .proto ⽂件下，最外层枚举类型和嵌套枚举类型，不算同级。

• 多个 .proto ⽂件下，若⼀个⽂件引⼊了其他⽂件，且每个⽂件都未声明 package，每个 proto ⽂

件中的枚举类型都在最外层，算同级。

• 多个 .proto ⽂件下，若⼀个⽂件引⼊了其他⽂件，且每个⽂件都声明了 package，不算同级

我们继续更新我们的项目

write.cc当中的修改

read.cc的修改

4.Any 类

字段还可以声明为 Any 类型，可以理解为泛型类型。使⽤时可以在 Any 中存储任意消息类型。

型的字段也⽤ repeated 来修饰。

Any 类型是 google 已经帮我们定义好的类型，在安装 ProtoBuf 时，其中的 include ⽬录下查找所有 google 已经定义好的 .proto ⽂件。

PackFrom可以将其他类转化成Any类。

unpackto则可以将Any类还原。

5. oneof 类型

如果消息中有很多可选字段， 并且将来同时只有⼀个字段会被设置， 那么就可以使⽤ oneof 加强这 个⾏为，也能有节约内存的效果。

升级write.cc

升级read.cc

注意:

• 可选字段中的字段编号，不能与⾮可选字段的编号冲突。

• 不能在 oneof 中使⽤ repeated 字段。

• 将来在设置 oneof 字段中值时，如果将 oneof 中的字段设置多个，那么只会保留最后⼀次设置的成 员，之前设置的 oneof 成员会⾃动清除。

6. map 类型

语法⽀持创建⼀个关联映射字段，也就是可以使⽤ map 类型去声明字段类型，格式为：

map<key_type, value_type> map_field = N;

要注意的是：

• key_type 是除了 float 和 bytes 类型以外的任意标量类型。 value_type 可以是任意类型。

• map 字段不可以⽤ repeated 修饰

• map 中存⼊的元素是⽆序的

更新write.cc

更新read.cc

7. 默认值

反序列化消息时，如果被反序列化的⼆进制序列中不包含某个字段，反序列化对象中相应字段时，就 会设置为该字段的默认值。不同的类型对应的默认值不同：

• 对于字符串，默认值为空字符串。

• 对于字节，默认值为空字节。

• 对于布尔值，默认值为 false。

•  对于数值类型，默认值为 0。

• 对于枚举，默认值是第⼀个定义的枚举值， 必须为 0。

• 对于消息字段，未设置该字段。它的取值是依赖于语⾔。

• 对于设置了 repeated 的字段的默认值是空的（

通常是相应语⾔的⼀个空列表 ）。

• 对于 消息字段 、 oneof 字段 和 any 字段 ，C++ 和 Java 语⾔中都有 has_ ⽅法来检测当前字段

是否被设置。

8. 更新消息

8.1 更新规则

如果现有的消息类型已经不再满⾜我们的需求，例如需要扩展⼀个字段，在不破坏任何现有代码的情 况下更新消息类型⾮常简单。遵循如下规则即可：

• 禁⽌修改任何已有字段的字段编号。

• 若是移除⽼字段，要保证不再使⽤移除字段的字段编号。正确的做法是保留字段编号

（reserved），以确保该编号将不能被重复使⽤。不建议直接删除或注释掉字段。

• int32， uint32， int64， uint64 和 bool 是完全兼容的。可以从这些类型中的⼀个改为另⼀个，

⽽不破坏前后兼容性。若解析出来的数值与相应的类型不匹配，会采⽤与 C++ ⼀致的处理⽅案

（例如，若将 64 位整数当做 32 位进⾏读取，它将被截断为 32 位）。

• sint32 和 sint64 相互兼容但不与其他的整型兼容。

• string 和 bytes 在合法 UTF-8 字节前提下也是兼容的。

• bytes 包含消息编码版本的情况下，嵌套消息与 bytes 也是兼容的。

• fixed32 与 sfixed32 兼容， fixed64 与 sfixed64兼容。

• enum 与 int32，uint32， int64 和 uint64 兼容（注意若值不匹配会被截断）。但要注意当反序

列化消息时会根据语⾔采⽤不同的处理⽅案：例如，未识别的 proto3 枚举类型会被保存在消息

中，但是当消息反序列化时如何表⽰是依赖于编程语⾔的。整型字段总是会保持其的值。

• oneof：

◦ 将⼀个单独的值更改为 新 oneof 类型成员之⼀是安全和⼆进制兼容的。

◦ 若确定没有代码⼀次性设置多个值那么将多个字段移⼊⼀个新 oneof 类型也是可⾏的。

◦ 将任何字段移⼊已存在的 oneof 类型是不安全的。

8.2 保留字段 reserved

如果通过 删除 或 注释掉 字段来更新消息类型，未来的⽤⼾在添加新字段时，有可能会使⽤以前已经 存在，但已经被删除或注释掉的字段编号。将来使⽤该 .proto 的旧版本时的程序会引发很多问题：数 据损坏、隐私错误等等。

确保不会发⽣这种情况的⼀种⽅法是：使⽤ reserved 将指定字段的编号或名称设置为保留项 。当

我们再使⽤这些编号或名称时，protocol buffer 的编译器将会警告这些编号或名称不可⽤。举个例

⼦：

8.3 未知字段

• 未知字段：解析结构良好的 protocol buffer 已序列化数据中的未识别字段的表⽰⽅式。例如，当

旧程序解析带有新字段的数据时，这些新字段就会成为旧程序的未知字段。

• 本来，proto3 在解析消息时总是会丢弃未知字段，但在 3.5 版本中重新引⼊了对未知字段的保留机

制。所以在 3.5 或更⾼版本中，未知字段在反序列化时会被保留，同时也会包含在序列化的结果

中。

8.4 前后兼容性

根据上述的例⼦可以得出，pb是具有向前兼容的。为了叙述⽅便，把增加了“⽣⽇”属性的 service

称为“新模块”；未做变动的 client 称为 “⽼模块”。

• 向前兼容：⽼模块能够正确识别新模块⽣成或发出的协议。这时新增加的“⽣⽇”属性会被当作未

知字段（pb 3.5版本及之后）。

• 向后兼容：新模块也能够正确识别⽼模块⽣成或发出的协议。

前后兼容的作⽤：当我们维护⼀个很庞⼤的分布式系统时，由于你⽆法同时 升级所有 模块，为了保证

在升级过程中，整个系统能够尽可能不受影响，就需要尽量保证通讯协议的“向后兼容”或“向前兼

容”。

9. 选项 option

.proto ⽂件中可以声明许多选项，使⽤ option 标注。选项能影响 proto 编译器的某些处理⽅式。

选项分为 ⽂件级、消息级、字段级 等等， 但并没有⼀种选项能作⽤于所有的类型

9.1 常⽤选项列举

• optimize_for : 该选项为⽂件选项，可以设置 protoc 编译器的优化级别，分别为 SPEED 、

CODE_SIZE 、 LITE_RUNTIME 。受该选项影响，设置不同的优化级别，编译 .proto ⽂件后⽣

成的代码内容不同。

• SPEED : protoc 编译器将⽣成的代码是⾼度优化的，代码运⾏效率⾼，但是由此⽣成的代码

编译后会占⽤更多的空间。 SPEED 是默认选项。

• CODE_SIZE : proto 编译器将⽣成最少的类，会占⽤更少的空间，是依赖基于反射的代码来

实现序列化、反序列化和各种其他操作。但和 SPEED 恰恰相反，它的代码运⾏效率较低。这

种⽅式适合⽤在包含⼤量的.proto⽂件，但并不盲⽬追求速度的应⽤中。

• LITE_RUNTIME : ⽣成的代码执⾏效率⾼，同时⽣成代码编译后的所占⽤的空间也是⾮常

少。这是以牺牲Protocol Buffer提供的反射功能为代价的，仅仅提供 encoding+序列化 功能，

所以我们在链接 BP 库时仅需链接libprotobuf-lite，⽽⾮libprotobuf。这种模式通常⽤于资源

有限的平台，例如移动⼿机平台中

• allow_alias ： 允许将相同的常量值分配给不同的枚举常量，⽤来定义别名。该选项为枚举选项。

9.2设置⾃定义选项

ProtoBuf 允许⾃定义选项并使⽤。该功能⼤部分场景⽤不到，在这⾥不拓展讲解。

有兴趣可以参考： https://developers.google.cn/protocol-buffers/docs/proto?hl=zh

cn#customoptions

至此大家应该就已经能够基本使用protobuf了，谢谢大家观看。