文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

注：这是本人的翻译，可能不准确，可能有错误，但是基本上可以理解，希望能对大家有所帮助！（转载须注明出处：本文来自learnhard的博客：http://www.codelast.com/& http://blog.csdn.net/learnhard/）

·         Streaming Multiple Messages

·         Large Data Sets

·         Union Types

·         Self-describing Messages

This page describes some commonly-used design patterns for dealing with Protocol Buffers. You can also send design and usage questions to the Protocol Buffers discussion group.
文章来源：http://www.codelast.com/

l  将多个消息转化为流

l  大数据集

l  联合类型

l  自描述的消息

本文描述了处理Protocol Buffers的时候一些常用的设计模式。你也可以向Protocol Buffers讨论组（Protocol Buffers discussion group）发送设计和使用方面的问题寻求解答。

If you want to write multiple messages to a single file or stream, it is up to you to keep track of where one message ends and the next begins. The Protocol Buffer wire format is not self-delimiting, so protocol buffer parsers cannot determine where a message ends on their own. The easiest way to solve this problem is to write the size of each message before you write the message itself. When you read the messages back in, you read the size, then read the bytes into a separate buffer, then parse from that buffer. (If you want to avoid copying bytes to a separate buffer, check out the CodedInputStream class (in both C++ and Java) which can be told to limit reads to a certain number of bytes.)

如果你想将多个消息写入一个文件或流（stream）中，那么是由你来记录一个消息的终点以及另一个消息的起点的。Protocol Buffer数据传输格式不是自我限定的（self-delimiting），所以protocol buffer解析器无法自己决定一个消息结束于何处。解决这个问题的最简单的方法就是：在写入每一个消息之前，先写入消息的大小。当你读取消息的时候，先读取消息大小，然后将指定的字节数读入一个独立的缓冲区中，然后再解析缓冲区里的东西。如果你不想将数据拷贝到一个独立的缓冲区中，请查看CodedInputStream类（C++和Java都可用）的使用方法——你可以用它来限制只读取指定字节的数据。

文章来源：http://www.codelast.com/

Protocol Buffers are not designed to handle large messages. As a general rule of thumb, if you are dealing in messages larger than a megabyte each, it may be time to consider an alternate strategy.

Protocol Buffers不是设计来处理大消息的。根据一般经验，如果你要处理的单条消息大于1M，那就是采取其他策略的时候了。

That said, Protocol Buffers are great for handling individual messages within a large data set. Usually, large data sets are really just a collection of small pieces, where each small piece may be a structured piece of data. Even though Protocol Buffers cannot handle the entire set at once, using Protocol Buffers to encode each piece greatly simplifies your problem: now all you need is to handle a set of byte strings rather than a set of structures.

也就是说，Protocol Buffers非常适合于处理一个大数据集内有多个单独的消息。通常，大数据集只是许多小块数据的集合，每一小块都是一块结构化的数据。即使是这样，Protocol Buffers也不能马上处理整个数据集，使用Protocol Buffers来编码每一块数据可以极大地简化你的问题：现在你所需要的只是处理一组字符串，而不是一组结构体了。

Protocol Buffers do not include any built-in support for large data sets because different situations call for different solutions. Sometimes a simple list of records will do while other times you may want something more like a database. Each solution should be developed as a separate library, so that only those who need it need to pay the costs.

Protocol Buffers没有内置任何对大数据集的支持，因为不同的情况需要不同的解决方案。

有时，一个简单的记录列表就解决问题了，而在某些情况下，你可能更想要的是类似于数据库的东西。每个解决方案都应该作为一个独立的库来开发，所以只有需要它的人才需要付出代价。

You may sometimes want to send a message that could be one of several different types. However, protocol buffer parsers cannot necessarily determine the type of a message based on the contents alone. So how do you make sure that the recipient application knows how to decode your message? One solution is to create a wrapper message that has one optional field for each possible message type.

有时，你可能想发送一个消息，它的类型可以是几种不同的类型之一。然而，protocol buffer解析器无法仅凭消息内容来决定消息的类型。所以，你如何确保接收方应用程序能知道怎么解析消息呢？有一个解决方案是：创建一个封装的消息，其含有N个optional的字段，每一个字段对应一种可能的消息类型。

文章来源：http://www.codelast.com/

For example, if you have message types Foo, Bar, and Baz, you can combine them with a type like:

例如，如果你有消息类型Foo，Bar和Baz，那么你可以将它们与类型结合起来，像这样：

You may also want to have an enum field that identifies which message is filled in, so that you can switch on it:

你也可能想这样做：添加一个枚举字段来标识是哪个消息被填充了，这样的话你就可以对它使用switch（来进行不同的处理）：

If you have a very large number of possible types, listing every one of them in your container type may be unwieldy. Instead, you should consider using extensions:

如果你有大量“可能的类型”，那么在你的容器类型中将它们一一列举出来可能非常困难。在这种情况下，你应该考虑使用扩展（extensions）：

Note that you can use the ListFields reflection method (in C++, Java, and Python) to get a list of all fields present in the message, including extensions. You might use this as part of a scheme for registering handlers for diverse message types.

注意：你可以使用反射函数ListFields（C++，Java和Python都可用）来获取一个消息中的所有字段的列表（包括扩展）。在实现一个为不同消息类型分别注册句柄的技术方案的时候，你可能用得上这个功能。

Protocol Buffers do not contain descriptions of their own types. Thus, given only a raw message without the corresponding .proto file defining its type, it is difficult to extract any useful data.

However, note that the contents of a .proto file can itself be represented using protocol buffers. The file src/google/protobuf/descriptor.protoin the source code package defines the message types involved. protoc can output a FileDescriptorSet – which represents a set of .proto files – using the --descriptor_set_out option. With this, you could define a self-describing protocol message like so:

Protocol Buffers不包含自我类型描述的信息。因此，如果只提供原始消息，而不提供对应的.proto文件，你将很难从中提取出任何有用的数据。

然而，请注意：一个.proto文件的内容可以使用protocol buffers来描述。通过使用--descriptor_set_out选项，源代码包中的src/google/protobuf/descriptor.proto文件定义了相关的消息类型。protoc编译器可以输出一个FileDescriptorSet——这个集合表示一系列的.proto文件。利用它，你可以像这样定义一个自描述的协议消息：

By using classes like DynamicMessage (available in C++ and Java), you can then write tools which can manipulate SelfDescribingMessages.

All that said, the reason that this functionality is not included in the Protocol Buffer library is because we have never had a use for it inside Google.

通过使用像DynamicMessage这样的类（C++和Java都可用），你可以编写出操作SelfDescribingMessage的工具。

总之，Protocol Buffer库之所以没有包含这个特性，是因为我们在Google还从没有需要用它的机会。

文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

注：这是本人的翻译，可能不准确，可能有错误，但是基本上可以理解，希望能对大家有所帮助！（转载须注明出处：本文来自learnhard的博客：http://www.codelast.com/ & http://blog.csdn.net/learnhard/）

·         Defining A Message Type

·         Scalar Value Types

·         Optional And Default Values

·         Enumerations

·         Using Other Message Types

·         Nested Types

·         Updating A Message Type

·         Extensions

·         Packages

·         Defining Services

·         Options

·         Generating Your Classes

This guide describes how to use the protocol buffer language to structure your protocol buffer data, including .proto file syntax and how to generate data access classes from your .proto files.

This is a reference guide – for a step by step example that uses many of the features described in this document, see the tutorial for your chosen language.

 l  定义一个消息（message）类型

l  标量值类型

l  可选的（optional）字段以及默认值

l  枚举

l  使用其他消息类型

l  嵌套类型

l  更新一个消息类型

l  扩展

l  包（package）

l  定义服务（service）

l  选项（option）

l  生成访问类

本指南描述了怎样使用protocol buffer语言来构造你的protocol buffer数据，包括.proto文件语法以及怎样生成.proto文件的数据访问类。

本文是一个参考指南——如果要查看如何使用本文中描述的多个特性的循序渐进的例子，请在tutorial中查找你需要的语言的教程。

First let's look at a very simple example. Let's say you want to define a search request message format, where each search request has a query string, the particular page of results you are interested in, and a number of results per page. Here's the .proto file you use to define the message type.

首先看一个非常简单的例子。假设你想定义一个“搜索请求”（search request）的消息格式，每一个搜索请求含有一个查询字符串、你感兴趣的查询结果所在的页数，以及每一页多少条查询结果。那么下面这个就是用来定义消息类型的.proto文件了：

The SearchRequest message definition specifies three fields (name/value pairs), one for each piece of data that you want to include in this type of message. Each field has a name and a type.

SearchRequest消息类型指定了3个字段（名/值 对），你想在消息中承载的数据分别对应于每一个字段。每个字段都有一个名字（name）和一个类型（type）。

文章来源：http://www.codelast.com/

Specifying Field Types 指定字段类型

In the above example, all the fields are scalar types: two integers (page_number and result_per_page) and a string (query). However, you can also specify composite types for your fields, including enumerations and other message types.

在上面的例子中，所有字段都是标量类型（scalar types）:两个整型（page_number和result_per_page），一个string（query）。然而，你也可以为字段指定合成的类型，包括枚举（enumerations）以及其他消息类型。

Assigning Tags 分配标识号

As you can see, each field in the message definition has a unique numbered tag. These tags are used to identify your fields in the message binary format, and should not be changed once your message type is in use. Note that tags with values in the range 1 through 15 take one byte to encode. Tags in the range 16 through 2047 take two bytes. So you should reserve the tags 1 through 15 for very frequently occurring message elements. Remember to leave some room for frequently occurring elements that might be added in the future.

The smallest tag number you can specify is 1, and the largest is 2²⁹ - 1, or 536,870,911. You also cannot use the numbers 19000 though 19999 (FieldDescriptor::kFirstReservedNumber through FieldDescriptor::kLastReservedNumber), as they are reserved for the Protocol Buffers implementation - the protocol buffer compiler will complain if you use one of these reserved numbers in your .proto.

如你所见，在消息定义中，每一个字段都有一个独一无二的标识号（unique numbered tag）。这些标识号是用来在消息二进制格式（message binary format）中识别你的字段的。注意：[1,15]之内的标识号在编码的时候会占用一个字节。[16,2047]之内的标识号则占用2个字节。所以你应该为那些频繁出现的消息元素保留[1,15]之内的标识号。切记：要为将来有可能添加的、频繁出现的标识号预留一些标识号。

Specifying Field Rules 指定字段规则

You specify that message fields are one of the following:

·         required: a well-formed message must have exactly one of this field.

·         optional: a well-formed message can have zero or one of this field (but not more than one).

·         repeated: this field can be repeated any number of times (including zero) in a well-formed message. The order of the repeated values will be preserved.

你所指定的消息字段必须是如下之一：

l  required：一个格式良好的消息一定要含有1个这种字段。

l  optional：一个格式良好的消息可以有0个或1个这种字段（但不超过1个）。

l  repeated：在一个格式良好的消息中，这种字段可以重复任意多次（包括0次）。重复的值的顺序会被保留。

（译者注：这一段内容我不太理解，因为Google提供的.proto示例文件并没有按这个说法来编写…）

 For historical reasons, repeated fields of basic numeric types aren't encoded as efficiently as they could be. New code should use the special option [packed=true] to get a more efficient encoding. For example:

由于历史原因，基本数值类型的repeated的字段并没有被尽可能地高效编码。在新的代码（译者注：这里是指.proto文件的内容）中，用户应该使用特殊选项[packed=true]来保证更高效的编码。例如：

required是永久性的：在把一个字段标识为required的时候，你应该特别小心。如果在某些情况下你不想写入或者发送一个required的字段，那么将该字段更改为optional可能会遇到问题——旧版本的读者（译者注：即读取、解析消息的一方）会认为不含该字段的消息（message）是不完整的，从而有可能会拒绝解析。在这种情况下，你应该考虑编写特别针对于应用程序的、自定义的消息校验函数。Google的一些工程师得出了一个结论：使用required弊多于利；他们更愿意使用optional和repeated而不是required。当然，这个观点并不具有普遍性。

文章来源：http://www.codelast.com/

 Adding More Message Types 添加更多消息类型

Multiple message types can be defined in a single .proto file. This is useful if you are defining multiple related messages – so, for example, if you wanted to define the reply message format that corresponds to your SearchResponse message type, you could add it to the same .proto:

在一个.proto文件中可以定义多个消息类型。在定义多个相关的消息的时候，这一点特别有用——例如，如果你想定义与你的SearchResponse消息类型对应的回复消息格式的话，你可以将它添加到相同的.proto文件中：

Adding Comments 添加注释

To add comments to your .proto files, use C/C++-style // syntax.

向.proto文件添加注释，可以使用C/C++风格的双斜杠（//） 语法格式。

What's Generated From Your .proto? 从你的.proto文件生成了什么？

When you run the protocol buffer compiler on a .proto, the compiler generates the code in your chosen language you'll need to work with the message types you've described in the file, including getting and setting field values, serializing your messages to an output stream, and parsing your messages from an input stream.

当你对.proto文件运行protocol buffer编译器（protocol buffer compiler）的时候，编译器生成你所选择的语言的代码，这些代码可以操作你在.proto文件中定义的消息类型，包括获取、设置字段值，将你的消息序列化到一个输出流中，以及从一个输入流中解析你的消息。

For C++, the compiler generates a .h and .cc file from each .proto, with a class for each message type described in your file.

For Java, the compiler generates a .java file with a class for each message type, as well as a special Builder classes for creating message class instances.

对C++来说，编译器为每一个.proto文件生成了一个.h文件和一个.cc文件，.proto文件中的每一个消息有一个对应的类。

对Java来说，编译器为每一个消息类型生成了一个.java文件，以及一个特殊的Builder类（这个类是用来创建消息类接口的）。

Python is a little different – the Python compiler generates a module with a static descriptor of each message type in your .proto, which is then used with a metaclass to create the necessary Python data access class at runtime.

You can find out more about using the APIs for each language by following the tutorial for your chosen language. For even more API details, see the relevant API reference.

对Python来说，有点不一样——Python编译器为.proto文件中的每个消息类型生成一个模型，其含有一个静态描述符（static descriptor，译者注：没用过Python，不清楚这样翻译正确与否），该模型与一个元类（metaclass）在运行时（runtime）被用来创建必需的Python数据访问类。

你可以从每种语言的教程中找到更多使用使用API的方法。如欲查看更详细的API信息，请阅相关的文章API reference。 

A scalar message field can have one of the following types – the table shows the type specified in the .proto file, and the corresponding type in the automatically generated class:

一个标量消息字段可以含有一个如下的类型——该表格展示了定义于.proto文件中的类型，以及与之对应的、在自动生成的访问类中定义的类型：

You can find out more about how these types are encoded when you serialize your message in Protocol Buffer Encoding.

^[1] In Java, unsigned 32-bit and 64-bit integers are represented using their signed counterparts, with the top bit simply being stored in the sign bit.

你可以在文章Protocol Buffer Encoding中，找到更多“序列化消息时各种类型如何编码”的信息。

^[1]在Java中，无符号32位和64位整型以它们对应的有符号类型来表示。

As mentioned above, elements in a message description can be labeled optional. A well-formed message may or may not contain an optional element. When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object is set to the default value for that field. The default value can be specified as part of the message description. For example, let's say you want to provide a default value of 10 for a SearchRequest's result_per_page value.

如上所述，消息描述中的一个元素可以被标记为“可选的”（optional）。一个格式良好的消息可以包含一个optional的元素，也可以不包含。当解析一个消息的时候，如果它不包含optional的元素，那么解析出来的对象中的对应字段就被置为默认值。默认值可以在消息描述文件中指定。例如，要为SearchRequest消息的result_per_page字段指定默认值10，可以这样做：

If the default value is not specified for an optional element, a type-specific default value is used instead: for strings, the default value is the empty string. For bools, the default value is false. For numeric types, the default value is zero. For enums, the default value is the first value listed in the enum's type definition.

如果没有为optional的元素指定默认值，那么就会使用与特定类型相关的默认值：对string来说，默认值是空字符串。对bool来说，默认值是false。对数值类型来说，默认值是0。对枚举来说，默认值是枚举类型定义中的第一个值。

文章来源：http://www.codelast.com/

When you're defining a message type, you might want one of its fields to only have one of a pre-defined list of values. For example, let's say you want to add a corpus field for each SearchRequest, where the corpus can be UNIVERSAL, WEB, IMAGES, LOCAL, NEWS, PRODUCTS or VIDEO. You can do this very simply by adding an enum to your message definition - a field with an enum type can only have one of a specified set of constants as its value (if you try to provide a different value, the parser will treat it like an unknown field). In the following example we've added an enum called Corpuswith all the possible values, and a field of type Corpus:

当你定义一个消息类型的时候，你可能想为一个字段指定某“预定义值序列”（pre-defined list of values）中的一个值。例如，假设你想为每一个SearchRequest消息添加一个corpus字段，而corpus的值可能是UNIVERSAL，WEB，IMAGES，LOCAL，NEWS，PRODUCTS或VIDEO中的一个。你可以很容易地实现这一点：通过向你的消息定义中添加一个枚举（enum）就可以了。一个enum类型的字段只能用指定的常量集（specified set of constants）中的一个值作为其值（如果你尝试指定不同的值，解析器就会把它当作一个未知的字段来对待）。在下面的例子中，我们已经添加了一个叫做Corpus的枚举（enum）——它含有所有可能的值——以及一个类型为Corpus的字段：

Enumerator constants must be in the range of a 32-bit integer. Since enum values use varint encoding on the wire, negative values are inefficient and thus not recommended. You can define enums within a message definition, as in the above example, or outside – these enums can be reused in any message definition in your .proto file. You can also use an enum type declared in one message as the type of a field in a different message, using the syntax MessageType.EnumType.

When you run the protocol buffer compiler on a .proto that uses an enum, the generated code will have a corresponding enum for Java or C++, or a special EnumDescriptor class for Python that's used to create a set of symbolic constants with integer values in the runtime-generated class.

For more information about how to work with message enums in your applications, see the generated code guide for your chosen language.

枚举常量必须在32位整型值的范围内。因为enum值是使用可变编码方式的，对负数不够高效，因此不推荐在enum中使用负数。如上例所示，你可以在一个消息定义的内部或外部定义枚举——这些枚举可以在你的.proto文件中的任何消息定义里重用。你也可以在一个消息中声明一个枚举类型，而在另一个不同的消息中使用它——采用MessageType.EnumType的语法格式。

当你对一个使用了枚举的.proto文件运行protocol buffer编译器的时候，生成的代码中将有一个对应的enum（对Java或C++来说），或者一个特殊的EnumDescriptor类（对Python来说），它被用来在运行时生成的类中创建一系列的整型值符号常量（symbolic constants）。

关于如何在你的应用程序的消息中使用枚举的更多信息，请查看你所选择的语言的generated code guide。

You can use other message types as field types. For example, let's say you wanted to include Result messages in each SearchResponsemessage – to do this, you can define a Result message type in the same .proto and then specify a field of type Result in SearchResponse:

你可以将其他消息类型用作字段类型。例如，假设你想在每一个SearchResponse消息中包含Result消息，你可以这样做——在相同的.proto文件中定义一个Result消息类型，然后在SearchResponse消息中指定一个Result类型的字段：

Importing Definitions 导入定义

In the above example, the Result message type is defined in the same file as SearchResponse – what if the message type you want to use as a field type is already defined in another .proto file?

在上面的例子中，Result消息类型与SearchResponse是定义在同一文件中的——如果你要使用的消息类型已经在其他.proto文件中已经定义过了呢？

You can use definitions from other .proto files by importing them. To import another .proto's definitions, you add an import statement to the top of your file:

你可以通过导入（importing）其他.proto文件中的定义来使用它们。要导入其他.proto文件的定义，你需要在你的文件中添加一个导入声明：

The protocol compiler searches for imported files in a set of directories specified on the protocol compiler command line using the -I/--import_path flag. If no flag was given, it looks in the directory in which the compiler was invoked.

然后，protocol编译器就会在一系列目录中查找需要被导入的文件，这些目录通过protocol编译器的命令行参数-I/--import_path指定。如果不提供参数，编译器就在其调用目录下查找。

文章来源：http://www.codelast.com/

You can define and use message types inside other message types, as in the following example – here the Result message is defined inside the SearchResponse message:

你可以在其他消息类型中定义、使用消息类型，在下面的例子中，Result消息就定义在SearchResponse消息内：

If you want to reuse this message type outside its parent message type, you refer to it as Parent.Type:

如果你想在它的父消息类型的外部重用这个消息类型，你需要以Parent.Type的形式使用它：

You can nest messages as deeply as you like:

你可以将消息嵌套任意多层：

Groups 组

Note that this feature is deprecated and should not be used when creating new message types – use nested message types instead.

注意：这个特性已经被弃用了，在创建新的消息类型的时候，不应该再使用它——你应该使用嵌套消息类型来代替它。

Groups are another way to nest information in your message definitions. For example, another way to specify a SearchResponse containing a number of Results is as follows:

“组”是在你的消息定义中嵌套信息的另一种方法。例如，在SearchResponse中包含若干Result的另一种方法是 ：

A group simply combines a nested message type and a field into a single declaration. In your code, you can treat this message just as if it had aResult type field called result (the latter name is converted to lower-case so that it does not conflict with the former). Therefore, this example is exactly equivalent to the SearchResponse above, except that the message has a different wire format.

一个“组”只是简单地将一个嵌套消息类型和一个字段捆绑到一个单独的声明中。在你的代码中，你可以把它看成是含有一个Result类型、名叫result的字段的消息（后面的名字被转换成了小写，所以它不会与前面的冲突）。

因此，除了数据传输格式（wire format）不同之外，这个例子与上面的SearchResponse例子是完全等价的。 

If an existing message type no longer meets all your needs – for example, you'd like the message format to have an extra field – but you'd still like to use code created with the old format, don't worry! It's very simple to update message types without breaking any of your existing code. Just remember the following rules:

如果一个已有的消息无法再满足你的需求——例如，你想在消息中添加一个额外的字段——但是你同时还想让为旧版本写的代码仍然可用，不用怕！更新消息而不破坏已有代码是非常简单的。只要你记住下面的规则：

·         Don't change the numeric tags for any existing fields.

·         Any new fields that you add should be optional or repeated. This means that any messages serialized by code using your "old" message format can be parsed by your new generated code, as they won't be missing any required elements. You should set up sensible default values for these elements so that new code can properly interact with messages generated by old code. Similarly, messages created by your new code can be parsed by your old code: old binaries simply ignore the new field when parsing. However, the unknown fields are not discarded, and if the message is later serialized, the unknown fields are serialized along with it – so if the message is passed on to new code, the new fields are still available. Note that preservation of unknown fields is currently not available for Python.

·         Non-required fields can be removed, as long as the tag number is not used again in your updated message type (it may be better to rename the field instead, perhaps adding the prefix "OBSOLETE_", so that future users of your .proto can't accidentally reuse the number).

·         A non-required field can be converted to an extension and vice versa, as long as the type and number stay the same.

·         int32, uint32, int64, uint64, and bool are all compatible – this means you can change a field from one of these types to another without breaking forwards- or backwards-compatibility. If a number is parsed from the wire which doesn't fit in the corresponding type, you will get the same effect as if you had cast the number to that type in C++ (e.g. if a 64-bit number is read as an int32, it will be truncated to 32 bits).

·         sint32 and sint64 are compatible with each other but are not compatible with the other integer types.

·         string and bytes are compatible as long as the bytes are valid UTF-8.

·         Embedded messages are compatible with bytes if the bytes contain an encoded version of the message.

·         fixed32 is compatible with sfixed32, and fixed64 with sfixed64.

l   不要更改任何已有的字段的数值标识（tag）。

l   你添加的任何字段都必须是optional或repeated的。这就意味着任何使用你的“旧”消息格式的代码序列化的消息可以被你的新代码所解析，因为它们不会丢掉任何required的元素。你应该为这些元素设置合理的默认值（default values），这样新的代码就能够正确地与老代码生成的消息交互了。类似地，你的新代码创建的消息也能被你的老代码解析：老的二进制程序在解析的时候只是简单地将新字段忽略。然而，未知的字段是没有被抛弃的，此后，如果消息被序列化，未知的字段会随之一起被序列化——所以，如果消息传到了新代码那里，则新的字段仍然可用。注意：对Python来说，对未知字段的保留策略是无效的。

l   非required的字段可以移除——只要它们的标识号（tag number）在你的新消息类型中不再使用（更好的做法可能是重命名那个字段，例如在字段前添加“OBSOLETE_”前缀，那样的话，你的.proto文件的用户将来就不会无意中重新使用了那些不该使用的标识号）。

l   一个非required的字段可以转换为一个扩展（extension），反之亦然——只要它的类型和标识号保持不变。

l   int32, uint32, int64, uint64,和bool是全部兼容的，这意味着你可以将这些类型中的一个转换为另外一个，而不会破坏前向、后向的兼容性。如果解析出来的数字与对应的类型不相符，那么结果就像在C++中对它进行了强制类型转换一样（例如，如果把一个64位数字当作int32来读取，那么它就会被截断为32位的数字）。

l   sint32和sint64是互相兼容的，但是它们与其他整数类型不兼容。

l   string和bytes是兼容的——只要bytes是有效的UTF-8编码。

l   嵌套消息与bytes是兼容的——只要bytes包含该消息的一个编码过的版本。

l   fixed32与sfixed32是兼容的，fixed64与sfixed64是兼容的。

Extensions let you declare that a range of field numbers in a message are available for third-party extensions. Other people can then declare new fields for your message type with those numeric tags in their own .proto files without having to edit the original file. Let's look at an example:

通过扩展，你可以将一个范围内的字段标识号声明为可被第三方扩展所用。然后，其他人就可以在他们自己的.proto文件中为你的消息类型声明新的字段，而不必去编辑原始文件了。让我们看个例子：

This says that the range of field numbers [100, 199] in Foo is reserved for extensions. Other users can now add new fields to Foo in their own.proto files that import your .proto, using tags within your specified range – for example:

这个例子表明：在消息Foo中，范围[100,199]之内的字段标识号被保留为扩展用。现在，其他人就可以在他们自己的.proto文件中添加新字段到Foo里了，但是添加的字段标识号要在指定的范围内——例如：

This says that Foo now has an optional int32 field called bar.

When your user's Foo messages are encoded, the wire format is exactly the same as if the user defined the new field inside Foo. However, the way you access extension fields in your application code is slightly different to accessing regular fields – your generated data access code has special accessors for working with extensions. So, for example, here's how you set the value of bar in C++:

这个例子表明：消息Foo现在有一个名为bar的optional int32字段。

当用户的Foo消息被编码的时候，数据的传输格式与用户在Foo里定义新字段的效果是完全一样的。

然而，你在程序代码中访问扩展字段的方法与访问普通的字段稍有不同——你生成的数据访问代码为扩展准备了特殊的访问函数来访问它。例如，下面是你如何在C++中设置bar的值：

Similarly, the Foo class defines templated accessors HasExtension(), ClearExtension(), GetExtension(), MutableExtension(), andAddExtension(). All have semantics matching the corresponding generated accessors for a normal field. For more information about working with extensions, see the generated code reference for your chosen language.

Note that extensions can be of any field type, including message types.

类似地，Foo类也定义了模板函数HasExtension()，ClearExtension()，GetExtension()，MutableExtension()，以及AddExtension()。这些函数的语义都与对应的普通字段的访问函数相符。要查看更多使用扩展的信息，请参考相应语言的代码生成指南。

注意：扩展可以是任何字段类型，包括消息类型。

文章来源：http://www.codelast.com/

Nested Extensions 嵌套的扩展

You can declare extensions in the scope of another type:

你可以在另一个类型的范围内声明扩展：

In this case, the C++ code to access this extension is:

在此例中，访问此扩展的C++代码是：

In other words, the only effect is that bar is defined within the scope of Baz.

换句话说，唯一的效果就是bar被定义在Baz的范围内。

A common pattern is to define extensions inside the scope of the extension's field type – for example, here's an extension to Foo of type Baz, where the extension is defined as part of Baz:

一个通常的设计模式就是：在扩展的字段类型的范围内定义该扩展——例如，下面是一个Foo的扩展（该扩展是Baz类型的），其中，扩展被定义为了Baz的一部分：

（译者注：这样的定义形式确很容易引起混淆，请继续往下看，以帮助你消除这种混淆）

However, there is no requirement that an extension with a message type be defined inside that type. You can also do this:

然而，并没有强制要求一个消息类型的扩展一定要定义在那个消息中。你也可以这样做：

In fact, this syntax may be preferred to avoid confusion. As mentioned above, the nested syntax is often mistaken for subclassing by users who are not already familiar with extensions.

事实上，这种语法格式更能防止引起混淆。正如上面所提到的，嵌套的语法通常被错误地认为有子类化的关系——尤其是对那些还不熟悉扩展的用户来说。

文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：