Merge pull request #102 from Sunt-ing/better-translation-扼杀

ch4: better-translation: 扼杀 → 破坏
This commit is contained in:
Feng Ruohang 2021-01-07 18:11:49 +08:00 committed by GitHub
commit c7ace9def3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

2
ch4.md
View File

@ -182,7 +182,7 @@ Thrift CompactProtocol编码在语义上等同于BinaryProtocol但是如[图4
#### 数据类型和模式演变 #### 数据类型和模式演变
如何改变字段的数据类型?这可能是可能的——检查文件的细节——但是有一个风险,值将失去精度或被扼杀。例如假设你将一个32位的整数变成一个64位的整数。新代码可以轻松读取旧代码写入的数据因为解析器可以用零填充任何缺失的位。但是如果旧代码读取由新代码写入的数据则旧代码仍使用32位变量来保存该值。如果解码的64位值不适合32位则它将被截断。 如何改变字段的数据类型?这可能是可能的——检查文件的细节——但是有一个风险,值将失去精度或被破坏。例如假设你将一个32位的整数变成一个64位的整数。新代码可以轻松读取旧代码写入的数据因为解析器可以用零填充任何缺失的位。但是如果旧代码读取由新代码写入的数据则旧代码仍使用32位变量来保存该值。如果解码的64位值不适合32位则它将被截断。
Protobuf的一个奇怪的细节是它没有列表或数组数据类型而是有一个字段的重复标记这是第三个选项旁边必要和可选。如[图4-4](img/fig4-4.png)所示,重复字段的编码正如它所说的那样:同一个字段标记只是简单地出现在记录中。这具有很好的效果,可以将可选(单值)字段更改为重复(多值)字段。读取旧数据的新代码会看到一个包含零个或一个元素的列表(取决于该字段是否存在)。读取新数据的旧代码只能看到列表的最后一个元素。 Protobuf的一个奇怪的细节是它没有列表或数组数据类型而是有一个字段的重复标记这是第三个选项旁边必要和可选。如[图4-4](img/fig4-4.png)所示,重复字段的编码正如它所说的那样:同一个字段标记只是简单地出现在记录中。这具有很好的效果,可以将可选(单值)字段更改为重复(多值)字段。读取旧数据的新代码会看到一个包含零个或一个元素的列表(取决于该字段是否存在)。读取新数据的旧代码只能看到列表的最后一个元素。