七、默认值

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

不同的类型对应的默认值不同：

• 对于字符串，默认值为空字符串。
• 对于字节，默认值为空字节。
• 对于布尔值，默认值为 false。
• 对于数值类型，默认值为 0。
• 对于枚举，默认值是第⼀个定义的枚举值， 必须为 0。
• 对于消息字段，未设置该字段。它的取值是依赖于语言。
• 对于设置了 repeated 的字段的默认值是空的（通常是相应语⾔的⼀个空列表）。
• 对于消息字段、oneof 字段和 any 字段，C++ 和 Java 语言中都有 has_ 方法来检测当前字段是否被设置。
• 对于标量数据类型，在 proto3 语法下，没有生成 has_ 方法。

八、更新消息

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 类型是不安全的。

2、保留字段 reserved

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

如果要删除老字段，要保证不使用已经被删除或者已经被注释掉的字段编号。确保不会发生上述这种情况的一种方法是：使用 reserved 将指定字段的编号或名称设置为保留项 。当我们再使用这些编号或名称时，protocol buffer 的编译器将会警告这些编号或名称不可用。举个例子：​​​​​​​

这里它推荐我们改成：int32 birthday = 4;

注意 ：不要在一行 reserved 声明中同时声明字段编号和名称。

（1）创建通讯录 3.0 版本 —— 验证错误删除字段造成的数据损坏

现模拟有两个服务，他们各自使用一份通讯录 .proto 文件，内容约定好了是一模一样的。

• 服务 1（service）：负责序列化通讯录对象，并写入文件中。
• 服务 2（client）：负责读取文件中的数据，解析并打印出来。

• ---

  一段时间后，service 更新了自己的 .proto 文件，更新内容为：删除了某个字段，并新增了一个字段，新增的字段使用了被删除字段的字段编号，并将新的序列化对象写进了文件。
• 但 client 并没有更新自己的 .proto 文件。

根据结论，可能会出现数据损坏的现象，下面来验证下这个结论：

新建两个目录：service、client，分别存放两个服务的代码。

A. service 目录下新增 contacts.proto（通讯录 3.0）

B. client 目录下新增 contacts.proto（通讯录 3.0）

分别对两个文件进行编译，可自行操作。

C. 继续对 service 目录下新增 service.cc（通讯录 3.0），负责向文件中写通讯录消息

D. service 目录下新增 makefile

E. client 目录下新增 client.cc（通讯录 3.0），负责向读出文件中的通讯录消息

F. client 目录下新增 makefile

代码编写完成后：再对 service 目录下的 contacts.proto 文件进行更新：删除 age 字段，新增 birthday 字段，新增的字段使用被删除字段的字段编号。

G. 更新后的 contacts.proto（通讯录 3.0）

H. 编译文件 .proto 后，还需要更新一下对应的 service.cc（通讯录 3.0）

这时输入的生日在反序列化时，会被设置到了使用了相同字段编号的年龄上。

结论：如果是移除老字段，要保证不再使用移除字段的字段编号，不建议直接删除或注释掉字段。那么正确的做法是：保留字段编号（reserved），以确保该编号将不能被重复使用。

I. 正确 service 目录下的 contacts.proto 写法如下（终版通讯录 3.0）

编译 .proto 文件后，还需要重新编译下 service.cc，让 service 程序保持使用新生成的 pb C++ 文件。

可以发现 ‘王五’ 的年龄为 0。这是由于新增时未设置年龄，通过 client 程序反序列化时，给年龄字段设置了默认值 0。

再解释一下，假设我们之前有一个存储的数据 ‘李四’，年龄依旧使用了之前设置的生日字段 ‘1221’。那么这是因为在新增 ‘李四’ 时，生日字段的字段编号依旧为 2，并且已经被序列化到文件中了。那么最后再读取时，字段编号依旧为 2。因为使用了 reserved 关键字，ProtoBuf 在编译阶段就拒绝了我们使用已经保留的字段编号。

如果使用了 reserved 2 了，那么 service 给 ‘王五’ 设置的生日 ‘1020’，client 就没法读到了吗？

答案是可以的。

3、未知字段

在通讯录 3.0 版本中，我们向 service 目录下的 contacts.proto 新增了 ‘生日’ 字段，但对于 client 相关的代码并没有任何改动。验证后发现新代码序列化的消息（service）也可以被旧代码（client）解析。新增的 ‘生日’ 字段在旧程序（client）中其实并没有丢失，而是会作为旧程序的未知字段。

• 未知字段：解析结构良好的 protocol buffer 已序列化数据中的未识别字段的表示方式。例如，当旧程序解析带有新字段的数据时，这些新字段就会成为旧程序的未知字段。
• proto3 在解析消息时总是会丢弃未知字段，但在 3.5 版本中重新引⼊了对未知字段的保留机制。所以，在 3.5 或更高版本中，未知字段在反序列化时会被保留，同时也会包含在序列化的结果中。

（1）未知字段从哪获取

A. 了解相关类关系图

B. MessageLite 类介绍（了解）

• MessageLite 从名字看是轻量级的 message，仅仅提供序列化、反序列化功能。
• 类定义在 google 提供的 message_lite.h 中。

C. Message 类介绍（了解）

• 我们自定义的 message 类，都是继承自 Message。
• Message 最重要的两个接口 GetDescriptor / GetReflection，可以获取该类型对应的 Descriptor 对象指针和 Reflection 对象指针。
• 类定义在 google 提供的 message.h 中。

D. Descriptor 类介绍（了解）

• Descriptor：是对 message 类型定义的描述，包括 message 的名字、所有字段的描述、原始的 proto 文件内容等。
• 类定义在 google 提供的 descriptor.h 中。

E. Descriptor 类介绍（了解）

• Descriptor：是对 message 类型定义的描述，包括 message 的名字、所有字段的描述、原始的 proto 文件内容等。
• 类定义在 google 提供的 descriptor.h 中。

F. Reflection 类介绍（了解）

• Reflection接口类，主要提供了动态读写消息字段的接口，对消息对象的自动读写主要通过该类完成。
• 提供方法来动态访问 / 修改 message 中的字段，对每种类型，Reflection 都提供了⼀个单独的接口用于读写字段对应的值。

针对所有不同的field类型 FieldDescriptor::TYPE_* ,需要使⽤不同的 Get*() / Set*() / Add*() 接口；

repeated 类型需要使用 GetRepeated*() / SetRepeated*() 接口，不可以和非 repeated 类型接口混用；

message 对象只可以被由它自身的 reflection（message.GetReflection()） 来操作；

• 类中还包含了访问 / 修改未知字段的方法。
• 类定义在 google 提供的 message.h 中。

G. UnknownFieldSet 类介绍（重要）

• UnknownFieldSet 包含在分析消息时遇到但未由其类型定义的所有字段。
• 若要将 UnknownFieldSet 附加到任何消息，请调用 Reflection::GetUnknownFields()。
• 类定义在 unknown_field_set.h 中。

H. UnknownField 类介绍（重要）

• 表示未知字段集中的⼀个字段。
• 类定义在 unknown_field_set.h 中。

（2）升级通讯录 3.1 版本 —— 验证未知字段

A. 更新 client.cc（通讯录 3.1）

在这个版本中，需要打印出未知字段的内容。更新的代码如下：

其他文件均不用做任何修改，重新编译 client.cc，进行一次读操作可得如下结果：

类型为什么为 0 呢？

前面介绍 UnknownField 类中讲到了类中包含了未知字段的几种类型：

enum Type {TYPE_VARINT,TYPE_FIXED32,TYPE_FIXED64,TYPE_LENGTH_DELIMITED,TYPE_GROUP
};
// 类型为 0，即为 TYPE_VARINT。

（4）前后兼容性

根据上述的例子可以得出，pb 是具有向前兼容的。为了叙述方便，把增加了 “生日” 属性的 service 称为 “新模块”；未做变动的 client 称为 “老模块”。

• 向前兼容：老模块能够正确识别新模块生成或发出的协议。这时新增加的 “生日” 属性会被当作未知字段（pb 3.5 版本及之后）。
• 向后兼容：新模块也能够正确识别老模块生成或发出的协议。

前后兼容的作用：当我们维护⼀个很庞大的分布式系统时，由于我们无法同时升级所有模块，为了保证在升级过程中，整个系统能够尽可能不受影响，就需要尽量保证通讯协议的 “向后兼容” 或 “向前兼容”。

syntax = "proto2"; // descriptor.proto 使⽤ proto2 语法版本message FileOptions { ... } // ⽂件选项 定义在 FileOptions 消息中message MessageOptions { ... } // 消息类型选项 定义在 MessageOptions 消息中message FieldOptions { ... } // 消息字段选项 定义在 FieldOptions 消息中message OneofOptions { ... } // oneof字段选项 定义在 OneofOptions 消息中message EnumOptions { ... } // 枚举类型选项 定义在 EnumOptions 消息中message EnumValueOptions { .. } // 枚举值选项 定义在 EnumValueOptions 消息中message ServiceOptions { ... } // 服务选项 定义在 ServiceOptions 消息中message MethodOptions { ... } // 服务⽅法选项 定义在 MethodOptions 消息中...

option optimize_for = LITE_RUNTIME;