语言指南 (proto 3)

本指南描述了如何使用 protocol buffer 语言来组织你的 protocol buffer 数据，包括 .proto 文件语法以及如何从你的 .proto 文件生成数据访问类。本指南涵盖了 protocol buffers 语言的 proto3 版本。

有关 editions 语法的信息，请参阅 Protobuf Editions 语言指南。

有关 proto2 语法的信息，请参阅 Proto2 语言指南。

这是一份参考指南——若想通过一个分步示例来了解本文档中描述的许多功能，请参阅你所选语言的教程。

定义消息类型

首先，我们来看一个非常简单的例子。假设你想定义一个搜索请求消息格式，其中每个搜索请求都有一个查询字符串、你感兴趣的特定结果页面以及每页的结果数。这里是用于定义该消息类型的 .proto 文件。

syntax = "proto3";

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 results_per_page = 3;
}

• 文件的第一行指定了你正在使用 protobuf 语言规范的 proto3 版本。

  • edition（或对于 proto2/proto3 是 syntax）必须是文件中第一个非空、非注释行。
  • 如果没有指定 edition 或 syntax，protocol buffer 编译器将假定你正在使用 proto2。

• SearchRequest 消息定义指定了三个字段（名称/值对），每种你想包含在此类消息中的数据都对应一个字段。每个字段都有一个名称和一个类型。

指定字段类型

在前面的例子中，所有字段都是标量类型：两个整数（page_number 和 results_per_page）和一个字符串（query）。你还可以为你的字段指定枚举和复合类型，如其他消息类型。

分配字段编号

你必须为消息定义中的每个字段赋予一个介于 1 和 536,870,911 之间的编号，并遵守以下限制：

• 给定的编号必须在该消息的所有字段中是唯一的。
• 字段编号 19,000 到 19,999 为 Protocol Buffers 实现保留。如果你在消息中使用这些保留的字段编号，protocol buffer 编译器会报错。
• 你不能使用任何先前保留的字段编号或任何已分配给扩展的字段编号。

一旦你的消息类型被使用，这个编号就不能更改，因为它在消息线路格式中标识该字段。“更改”一个字段编号等同于删除该字段并创建一个具有相同类型但编号不同的新字段。请参阅删除字段了解如何正确操作。

字段编号永远不应被重用。切勿将一个字段编号从保留列表中移出，用于新的字段定义。请参阅重用字段编号的后果。

你应该为最常设置的字段使用 1 到 15 的字段编号。较小的字段编号值在线路格式中占用更少的空间。例如，范围在 1 到 15 的字段编号需要一个字节进行编码。范围在 16 到 2047 的字段编号需要两个字节。你可以在Protocol Buffer 编码中找到更多相关信息。

重用字段编号的后果

重用字段编号会使解码线路格式的消息变得模棱两可。

protobuf 线路格式是精简的，没有提供检测使用一种定义编码的字段并用另一种定义解码的方法。

使用一种定义编码一个字段，然后用不同的定义解码同一个字段可能导致：

• 开发者浪费时间调试
• 解析/合并错误（最好的情况）
• 个人身份信息/敏感个人身份信息泄露
• 数据损坏

字段编号重用的常见原因

• 重编号字段（有时为了实现字段编号顺序更美观）。重编号实际上是删除并重新添加所有涉及的字段，导致不兼容的线路格式变更。
• 删除一个字段并且没有保留其编号以防止未来重用。

字段编号限制为 29 位而不是 32 位，因为有三位用于指定字段的线路格式。有关更多信息，请参阅编码主题。

指定字段基数

消息字段可以是以下之一：

• 单一 (Singular):

  在 proto3 中，有两种类型的 singular 字段：

  • optional：（推荐）一个 optional 字段处于以下两种可能状态之一：

    • 该字段已设置，并包含一个被显式设置或从线路中解析出的值。它将被序列化到线路中。
    • 该字段未设置，并将返回默认值。它将不会被序列化到线路中。

    你可以检查该值是否被显式设置。

    为了与 protobuf editions 和 proto2 达到最大兼容性，推荐使用 optional 而非隐式字段。

  • 隐式：（不推荐）一个隐式字段没有显式的基数标签，其行为如下：

    • 如果字段是消息类型，其行为与 optional 字段完全相同。

    • 如果字段不是消息类型，它有两种状态：

      • 字段被设置为一个非默认（非零）值，该值被显式设置或从线路中解析。它将被序列化到线路中。
      • 字段被设置为默认（零）值。它将不会被序列化到线路中。实际上，你无法确定默认（零）值是被设置了还是从线路中解析的，或者根本就没有提供。有关此主题的更多信息，请参阅字段存在性。

• repeated：此字段类型在一个格式良好的消息中可以重复零次或多次。重复值的顺序将被保留。

• map：这是一个键值对字段类型。有关此字段类型的更多信息，请参阅映射。

重复字段默认打包

在 proto3 中，标量数值类型的 repeated 字段默认使用 packed 编码。

你可以在 Protocol Buffer 编码中找到更多关于 packed 编码的信息。

消息类型字段始终具有字段存在性

在 proto3 中，消息类型字段已经具有字段存在性。因此，添加 optional 修饰符并不会改变该字段的字段存在性。

以下代码示例中 Message2 和 Message3 的定义为所有语言生成相同的代码，并且在二进制、JSON 和 TextFormat 表示中没有区别：

syntax="proto3";

package foo.bar;

message Message1 {}

message Message2 {
  Message1 foo = 1;
}

message Message3 {
  optional Message1 bar = 1;
}

格式良好的消息

术语“格式良好”在应用于 protobuf 消息时，指的是序列化/反序列化的字节。protoc 解析器会验证给定的 proto 定义文件是否可解析。

单一字段可以在线路格式字节中出现多次。解析器会接受输入，但只有该字段的最后一个实例可以通过生成的绑定访问。有关此主题的更多信息，请参阅后来者胜。

添加更多消息类型

可以在单个 .proto 文件中定义多个消息类型。如果你正在定义多个相关的消息，这会很有用——例如，如果你想定义与你的 SearchResponse 消息类型相对应的回复消息格式，你可以将其添加到同一个 .proto 文件中。

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 results_per_page = 3;
}

message SearchResponse {
 ...
}

合并消息会导致臃肿：虽然可以在单个 .proto 文件中定义多种消息类型（如消息、枚举和服务），但当大量具有不同依赖关系的消息在单个文件中定义时，也可能导致依赖臃肿。建议每个 .proto 文件包含尽可能少的消息类型。

添加注释

要为你的 .proto 文件添加注释：

• 优先使用 C/C++/Java 风格的行尾注释 '//'，放在 .proto 代码元素的前一行。

• 也接受 C 风格的内联/多行注释 /* ... */。

  • 使用多行注释时，推荐使用 '*' 作为边距行。

/**
 * SearchRequest represents a search query, with pagination options to
 * indicate which results to include in the response.
 */
message SearchRequest {
  string query = 1;

  // Which page number do we want?
  int32 page_number = 2;

  // Number of results to return per page.
  int32 results_per_page = 3;
}

删除字段

如果操作不当，删除字段可能会导致严重问题。

当你不再需要一个字段并且所有引用都已从客户端代码中删除时，你可以从消息中删除该字段定义。但是，你必须保留已删除的字段编号。如果你不保留该字段编号，开发人员将来可能会重用该编号。

你也应该保留字段名称，以允许你的消息的 JSON 和 TextFormat 编码继续解析。

保留字段编号

如果你通过完全删除一个字段或将其注释掉来更新一个消息类型，未来的开发者在对该类型进行自己的更新时可能会重用该字段编号。这可能会导致严重问题，如重用字段编号的后果中所述。为确保这种情况不会发生，请将你删除的字段编号添加到 reserved 列表中。

如果未来的开发者试图使用这些保留的字段编号，protoc 编译器将生成错误消息。

message Foo {
  reserved 2, 15, 9 to 11;
}

保留的字段编号范围是包含性的（9 to 11 与 9, 10, 11 相同）。

保留字段名

之后重用旧字段名通常是安全的，除非在使用 TextProto 或 JSON 编码时，字段名会被序列化。为避免这种风险，你可以将被删除的字段名添加到 reserved 列表中。

保留名称仅影响 protoc 编译器的行为，不影响运行时行为，但有一个例外：TextProto 实现在解析时可能会丢弃具有保留名称的未知字段（不会像其他未知字段那样引发错误）（目前只有 C++ 和 Go 的实现这样做）。运行时 JSON 解析不受保留名称的影响。

message Foo {
  reserved 2, 15, 9 to 11;
  reserved "foo", "bar";
}

请注意，你不能在同一个 reserved 语句中混合使用字段名和字段编号。

从你的 .proto 文件生成了什么？

当你在一个 .proto 文件上运行protocol buffer 编译器时，编译器会用你选择的语言生成你需要用来处理文件中描述的消息类型的代码，包括获取和设置字段值、将消息序列化到输出流，以及从输入流解析消息。

• 对于 C++，编译器会从每个 .proto 文件生成一个 .h 和一个 .cc 文件，其中为你文件中描述的每种消息类型都提供一个类。
• 对于 Java，编译器会为每种消息类型生成一个包含一个类的 .java 文件，以及一个用于创建消息类实例的特殊 Builder 类。
• 对于 Kotlin，除了 Java 生成的代码外，编译器还为每个消息类型生成一个 .kt 文件，其中包含一个改进的 Kotlin API。这包括一个简化消息实例创建的 DSL、一个可空字段访问器和一个复制函数。
• Python 有点不同 — Python 编译器会生成一个模块，其中包含你 .proto 文件中每种消息类型的静态描述符，然后该模块与一个元类一起在运行时创建必要的 Python 数据访问类。
• 对于 Go，编译器会生成一个 .pb.go 文件，其中包含你文件中每种消息类型的一个类型。
• 对于 Ruby，编译器会生成一个 .rb 文件，其中包含一个 Ruby 模块，该模块包含你的消息类型。
• 对于 Objective-C，编译器会从每个 .proto 文件生成一个 pbobjc.h 和 pbobjc.m 文件，其中为你文件中描述的每种消息类型都提供一个类。
• 对于 C#，编译器会从每个 .proto 文件生成一个 .cs 文件，其中为你文件中描述的每种消息类型都提供一个类。
• 对于 PHP，编译器会为你文件中描述的每种消息类型生成一个 .php 消息文件，并为你编译的每个 .proto 文件生成一个 .php 元数据文件。元数据文件用于将有效的消息类型加载到描述符池中。
• 对于 Dart，编译器会生成一个 .pb.dart 文件，其中包含你文件中每种消息类型的一个类。

你可以通过按照你所选语言的教程来了解更多关于使用每种语言 API 的信息。要了解更详细的 API 信息，请参阅相关的API 参考。

标量值类型

一个标量消息字段可以有以下类型之一——该表显示了在 .proto 文件中指定的类型，以及在自动生成的类中对应的类型：

^[1] 为了确保在混合的 Java/Kotlin 代码库中的兼容性，Kotlin 即使对于无符号类型也使用 Java 对应的类型。

^[2] 在 Java 中，无符号 32 位和 64 位整数使用其有符号的对应类型来表示，最高位仅存储在符号位中。

^[3] 在所有情况下，为字段设置值都会进行类型检查以确保其有效。

^[4] 64 位或无符号 32 位整数在解码时总是表示为 long，但在设置字段时如果给定的是 int，也可以是 int。在所有情况下，设置的值必须符合所表示的类型。参见 [2]。

^[5] Python 字符串在解码时表示为 unicode，但如果给定的是 ASCII 字符串，也可以是 str（这可能会改变）。

^[6] 在 64 位机器上使用 Integer，在 32 位机器上使用 string。

你可以在 Protocol Buffer 编码中了解更多关于这些类型在序列化消息时的编码方式。

字段默认值

当解析消息时，如果编码的消息字节中不包含某个特定字段，那么在解析的对象中访问该字段将返回该字段的默认值。默认值是类型特定的：

• 对于字符串，默认值是空字符串。
• 对于字节，默认值是空字节。
• 对于布尔值，默认值是 false。
• 对于数值类型，默认值是零。
• 对于消息字段，该字段未被设置。其确切值取决于语言。详情请参阅生成的代码指南。
• 对于枚举，默认值是第一个定义的枚举值，该值必须为 0。请参阅枚举默认值。

对于 repeated 字段，默认值是空的（通常是相应语言中的空列表）。

对于 map 字段，默认值是空的（通常是相应语言中的空 map）。

请注意，对于隐式存在性标量字段，一旦消息被解析，就无法判断该字段是被显式设置为默认值（例如，布尔值是否被设置为 false），还是根本就没有设置：在定义消息类型时应考虑到这一点。例如，如果不想让某个行为默认发生，就不要用一个设置为 false 时会开启该行为的布尔值。另请注意，如果一个标量消息字段被设置为其默认值，该值将不会被序列化到线路上。如果一个 float 或 double 值被设置为 +0，它将不会被序列化，但 -0 被认为是不同的，并且会被序列化。

有关默认值在生成代码中如何工作的更多细节，请参阅你所选语言的生成代码指南。

枚举

在定义消息类型时，你可能希望它的某个字段只能是预定义列表中的值之一。例如，假设你想为每个 SearchRequest 添加一个 corpus 字段，其中 corpus 可以是 UNIVERSAL、WEB、IMAGES、LOCAL、NEWS、PRODUCTS 或 VIDEO。你可以通过在你的消息定义中添加一个 enum 并为每个可能的值定义一个常量来非常简单地实现这一点。

在下面的例子中，我们添加了一个名为 Corpus 的 enum，包含了所有可能的值，以及一个类型为 Corpus 的字段：

enum Corpus {
  CORPUS_UNSPECIFIED = 0;
  CORPUS_UNIVERSAL = 1;
  CORPUS_WEB = 2;
  CORPUS_IMAGES = 3;
  CORPUS_LOCAL = 4;
  CORPUS_NEWS = 5;
  CORPUS_PRODUCTS = 6;
  CORPUS_VIDEO = 7;
}

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 results_per_page = 3;
  Corpus corpus = 4;
}

枚举默认值

SearchRequest.corpus 字段的默认值是 CORPUS_UNSPECIFIED，因为这是枚举中定义的第一个值。

在 proto3 中，枚举定义中定义的第一个值必须为零，并且其名称应为 ENUM_TYPE_NAME_UNSPECIFIED 或 ENUM_TYPE_NAME_UNKNOWN。这是因为：

• 必须有一个零值，这样我们才能使用 0 作为数值默认值。
• 零值需要是第一个元素，以便与 proto2 的语义兼容，在 proto2 中，除非明确指定了不同的值，否则第一个枚举值是默认值。

还建议这个第一个默认值除了“此值未指定”外，不具有任何语义含义。

枚举值别名

你可以通过将相同的值赋给不同的枚举常量来定义别名。为此，你需要将 allow_alias 选项设置为 true。否则，当发现别名时，protocol buffer 编译器会生成一条警告消息。尽管所有别名值在序列化时都是有效的，但在反序列化时只使用第一个值。

enum EnumAllowingAlias {
  option allow_alias = true;
  EAA_UNSPECIFIED = 0;
  EAA_STARTED = 1;
  EAA_RUNNING = 1;
  EAA_FINISHED = 2;
}

enum EnumNotAllowingAlias {
  ENAA_UNSPECIFIED = 0;
  ENAA_STARTED = 1;
  // ENAA_RUNNING = 1;  // Uncommenting this line will cause a warning message.
  ENAA_FINISHED = 2;
}

枚举器常量必须在 32 位整数的范围内。由于 enum 值在线路上使用 varint 编码，负值效率低下，因此不推荐使用。你可以在消息定义内部定义 enum，如前面的例子所示，也可以在外部定义——这些 enum 可以在你的 .proto 文件中的任何消息定义中重用。你还可以使用在一个消息中声明的 enum 类型作为另一个消息中字段的类型，使用语法 _MessageType_._EnumType_。

当你在使用 enum 的 .proto 文件上运行 protocol buffer 编译器时，生成的代码对于 Java、Kotlin 或 C++ 将有一个相应的 enum，对于 Python 则会有一个特殊的 EnumDescriptor 类，用于在运行时生成的类中创建一组带有整数值的符号常量。

在反序列化期间，无法识别的枚举值将保留在消息中，尽管当消息被反序列化时如何表示这取决于语言。在支持开放枚举类型（其值超出指定符号范围）的语言中，如 C++ 和 Go，未知的枚举值仅作为其底层的整数表示来存储。在具有封闭枚举类型的语言中，如 Java，枚举中的一个 case 用于表示无法识别的值，并且可以使用特殊访问器访问底层整数。在任何一种情况下，如果消息被序列化，无法识别的值仍将与消息一起被序列化。

有关如何在你的应用程序中使用消息 enum 的更多信息，请参阅你所选语言的生成代码指南。

保留值

如果你通过完全移除一个枚举条目或将其注释掉来更新一个枚举类型，未来的用户在对该类型进行自己的更新时可能会重用该数值。如果他们以后加载同一 .proto 的旧实例，这可能会导致严重问题，包括数据损坏、隐私漏洞等。确保这种情况不发生的一种方法是，指定你已删除条目的数值（和/或名称，名称也可能导致 JSON 序列化问题）是 reserved 的。如果未来的用户试图使用这些标识符，protocol buffer 编译器会报错。你可以使用 max 关键字指定你的保留数值范围达到最大可能值。

enum Foo {
  reserved 2, 15, 9 to 11, 40 to max;
  reserved "FOO", "BAR";
}

请注意，你不能在同一个 reserved 语句中混合使用字段名和数值。

使用其他消息类型

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

message SearchResponse {
  repeated Result results = 1;
}

message Result {
  string url = 1;
  string title = 2;
  repeated string snippets = 3;
}

导入定义

在前面的例子中，Result 消息类型与 SearchResponse 在同一个文件中定义——如果你想用作字段类型的消息类型已经定义在另一个 .proto 文件中，该怎么办？

你可以通过导入来使用其他 .proto 文件中的定义。要导入另一个 .proto 的定义，你在文件顶部添加一个 import 语句：

import "myproject/other_protos.proto";

默认情况下，你只能使用直接导入的 .proto 文件中的定义。然而，有时你可能需要将一个 .proto 文件移动到新位置。你可以不在一次变更中直接移动 .proto 文件并更新所有调用点，而是在旧位置放置一个占位的 .proto 文件，使用 import public 的概念将所有导入转发到新位置。

注意： Java 中可用的公共导入功能在移动整个 .proto 文件或使用 java_multiple_files = true 时最有效。在这些情况下，生成的名称保持稳定，避免了更新代码中引用的需要。虽然在不使用 java_multiple_files = true 的情况下移动 .proto 文件的一部分在技术上是可行的，但这样做需要同时更新许多引用，因此可能不会显著简化迁移。该功能在 Kotlin、TypeScript、JavaScript、GCL 中不可用，也不适用于使用 protobuf 静态反射的 C++ 目标。

import public 依赖可以被任何导入包含 import public 语句的 proto 的代码传递性地依赖。例如：

// new.proto
// All definitions are moved here

// old.proto
// This is the proto that all clients are importing.
import public "new.proto";
import "other.proto";

// client.proto
import "old.proto";
// You use definitions from old.proto and new.proto, but not other.proto

协议编译器在一组通过 -I/--proto_path 标志在协议编译器命令行上指定的目录中搜索导入的文件。如果没有给出标志，它会在调用编译器的目录中查找。通常，你应该将 --proto_path 标志设置到项目的根目录，并对所有导入使用完全限定名称。

使用 proto2 消息类型

可以导入 proto2 消息类型并在你的 proto3 消息中使用它们，反之亦然。然而，proto2 枚举不能直接在 proto3 语法中使用（如果导入的 proto2 消息使用它们是可以的）。

嵌套类型

你可以在其他消息类型内部定义和使用消息类型，如下例所示——这里的 Result 消息是在 SearchResponse 消息内部定义的。

message SearchResponse {
  message Result {
    string url = 1;
    string title = 2;
    repeated string snippets = 3;
  }
  repeated Result results = 1;
}

如果你想在其父消息类型之外重用此消息类型，你可以通过 _Parent_._Type_ 的方式引用它：

message SomeOtherMessage {
  SearchResponse.Result result = 1;
}

你可以随心所欲地嵌套消息。在下面的例子中，请注意两个名为 Inner 的嵌套类型是完全独立的，因为它们是在不同的消息中定义的：

message Outer {       // Level 0
  message MiddleAA {  // Level 1
    message Inner {   // Level 2
      int64 ival = 1;
      bool  booly = 2;
    }
  }
  message MiddleBB {  // Level 1
    message Inner {   // Level 2
      int32 ival = 1;
      bool  booly = 2;
    }
  }
}

更新消息类型

如果一个现有的消息类型不再满足你的所有需求——例如，你希望消息格式有一个额外的字段——但你仍然想使用旧格式创建的代码，别担心！当你使用二进制线路格式时，更新消息类型而不断开任何现有代码是非常简单的。

请查阅 Proto 最佳实践和以下规则：

二进制线路非安全变更

线路非安全变更是指，如果你使用旧模式序列化的数据，并用新模式的解析器来解析（反之亦然），将会中断的模式变更。只有当你知道所有数据的序列化器和反序列化器都在使用新模式时，才进行线路非安全的变更。

• 更改任何现有字段的字段编号是不安全的。
  • 更改字段编号等同于删除该字段并添加一个具有相同类型的新字段。如果你想重编号一个字段，请参阅删除字段的说明。
• 将字段移入一个现有的 oneof 是不安全的。

二进制线路安全变更

线路安全的变更是指完全安全地演进模式，而不会有数据丢失或新的解析失败的风险。

请注意，任何线路安全的变更都可能对给定语言的应用程序代码造成破坏性变更。例如，向一个已有的枚举添加一个值，对于任何对该枚举进行穷尽 switch 的代码来说，都会是一个编译中断。因此，Google 可能会避免在公共消息上进行某些此类变更：AIPs 包含了关于哪些变更在那里是安全的指导。

• 添加新字段是安全的。
  • 如果你添加了新字段，任何使用你的“旧”消息格式的代码序列化的消息仍然可以被你的新生成代码解析。你应该记住这些元素的默认值，以便新代码可以正确地与旧代码生成的消息交互。同样，由你的新代码创建的消息可以被你的旧代码解析：旧的二进制文件在解析时会简单地忽略新字段。详情请参阅未知字段部分。
• 移除字段是安全的。
  • 在更新后的消息类型中，不得再次使用相同的字段编号。你可能想重命名字段，或许添加前缀“OBSOLETE_”，或者将字段编号设为保留，这样你 .proto 的未来用户就不会意外地重用该编号。
• 向枚举添加额外的值是安全的。
• 将一个单一的显式存在字段或扩展变更为一个新的 oneof 的成员是安全的。
• 将一个只包含一个字段的 oneof 更改为显式存在字段是安全的。
• 将一个字段更改为具有相同编号和类型的扩展是安全的。

二进制线路兼容变更（有条件安全）

与线路安全变更不同，线路兼容意味着相同的数据在给定变更前后都可以被解析。然而，在这种变更形式下，数据的解析可能会是有损的。例如，将 int32 更改为 int64 是一个兼容的变更，但如果写入了一个大于 INT32_MAX 的值，一个将其作为 int32 读取的客户端将丢弃该数字的高位比特。

只有当你仔细管理系统的推出时，才可以对你的模式进行兼容性更改。例如，你可以将 int32 更改为 int64，但要确保在所有端点部署新模式之前，继续只写入合法的 int32 值，然后在之后开始写入更大的值。

如果你的模式是在组织外部发布的，通常不应该进行线路兼容的更改，因为你无法管理新模式的部署，从而无法知道何时使用不同范围的值是安全的。

• int32、uint32、int64、uint64 和 bool 都是兼容的。
  • 如果从线路中解析出一个不适合相应类型的数字，你将得到与在 C++ 中将该数字强制转换为该类型相同的效果（例如，如果一个 64 位数字被作为 int32 读取，它将被截断为 32 位）。
• sint32 和 sint64 彼此兼容，但与其他整数类型不兼容。
  • 如果写入的值在 INT_MIN 和 INT_MAX（含）之间，用任一类型解析都会得到相同的值。如果一个 sint64 值在那个范围之外被写入并作为 sint32 解析，varint 会被截断为 32 位，然后进行 zigzag 解码（这将导致观察到不同的值）。
• 只要字节是有效的 UTF-8，string 和 bytes 就是兼容的。
• 如果字节包含消息的编码实例，则嵌入式消息与 bytes 兼容。
• fixed32 与 sfixed32 兼容，fixed64 与 sfixed64 兼容。
• 对于 string、bytes 和消息字段，singular 与 repeated 兼容。
  • 给定一个重复字段的序列化数据作为输入，期望该字段为单一字段的客户端如果它是基本类型字段，将取最后一个输入值；如果它是消息类型字段，将合并所有输入元素。请注意，这对于数值类型（包括布尔值和枚举）通常是不安全的。数值类型的重复字段默认以打包格式序列化，当期望单一字段时，将无法正确解析。
• enum 与 int32、uint32、int64 和 uint64 兼容。
  • 请注意，当消息被反序列化时，客户端代码可能会以不同方式处理它们：例如，未识别的 proto3 enum 值将被保留在消息中，但当消息被反序列化时，其表示方式取决于语言。
• 在 map<K, V> 和相应的 repeated 消息字段之间更改字段是二进制兼容的（有关消息布局和其他限制，请参阅下面的映射）。
  • 然而，变更的安全性取决于应用程序：当反序列化和重新序列化消息时，使用 repeated 字段定义的客户端将产生语义上相同的结果；然而，使用 map 字段定义的客户端可能会重新排序条目并丢弃具有重复键的条目。

未知字段

未知字段是格式良好的 protocol buffer 序列化数据，表示解析器无法识别的字段。例如，当一个旧的二进制文件解析由一个新的二进制文件发送的带有新字段的数据时，这些新字段在旧的二进制文件中就成为未知字段。

Proto3 消息会保留未知字段，并在解析和序列化输出中包含它们，这与 proto2 的行为一致。

保留未知字段

一些操作可能导致未知字段丢失。例如，如果你执行以下操作之一，未知字段将丢失：

• 将 proto 序列化为 JSON。
• 遍历消息中的所有字段以填充一个新消息。

为避免丢失未知字段，请执行以下操作：

• 使用二进制格式；避免使用文本格式进行数据交换。
• 使用面向消息的 API，如 CopyFrom() 和 MergeFrom()，来复制数据，而不是逐个字段复制。

TextFormat 是一个有点特殊的情况。序列化为 TextFormat 会使用字段编号打印未知字段。但如果存在使用字段编号的条目，将 TextFormat 数据解析回二进制 proto 会失败。

Any

Any 消息类型允许你将消息作为嵌入类型使用，而无需其 .proto 定义。一个 Any 包含一个任意序列化的消息作为 bytes，以及一个作为该消息类型的全局唯一标识符并解析到该类型的 URL。要使用 Any 类型，你需要导入 google/protobuf/any.proto。

import "google/protobuf/any.proto";

message ErrorStatus {
  string message = 1;
  repeated google.protobuf.Any details = 2;
}

给定消息类型的默认类型 URL 是 type.googleapis.com/_packagename_._messagename_。

不同的语言实现将支持运行时库助手来以类型安全的方式打包和解包 Any 值——例如，在 Java 中，Any 类型将有特殊的 pack() 和 unpack() 访问器，而在 C++ 中有 PackFrom() 和 UnpackTo() 方法。

// Storing an arbitrary message type in Any.
NetworkErrorDetails details = ...;
ErrorStatus status;
status.add_details()->PackFrom(details);

// Reading an arbitrary message from Any.
ErrorStatus status = ...;
for (const google::protobuf::Any& detail : status.details()) {
  if (detail.Is<NetworkErrorDetails>()) {
    NetworkErrorDetails network_error;
    detail.UnpackTo(&network_error);
    ... processing network_error ...
  }
}

Oneof

如果你有一个包含许多 singular 字段的消息，并且在同一时间最多只有一个字段会被设置，你可以通过使用 oneof 功能来强制执行此行为并节省内存。

Oneof 字段类似于 optional 字段，只是 oneof 中的所有字段共享内存，并且在同一时间最多只能设置一个字段。设置 oneof 的任何成员都会自动清除所有其他成员。你可以使用一个特殊的 case() 或 WhichOneof() 方法来检查 oneof 中设置了哪个值（如果有的话），具体取决于你选择的语言。

请注意，如果*设置了多个值，则由 proto 中的顺序决定的最后一个设置的值将覆盖所有先前的值*。

oneof 字段的字段编号必须在封闭消息中是唯一的。

使用 Oneof

要在你的 .proto 文件中定义一个 oneof，你使用 oneof 关键字，后跟你 oneof 的名称，在本例中是 test_oneof：

message SampleMessage {
  oneof test_oneof {
    string name = 4;
    SubMessage sub_message = 9;
  }
}

然后你将你的 oneof 字段添加到 oneof 定义中。你可以添加任何类型的字段，除了 map 字段和 repeated 字段。如果你需要向 oneof 中添加一个 repeated 字段，你可以使用一个包含该 repeated 字段的消息。

在你生成的代码中，oneof 字段与常规字段具有相同的 getter 和 setter。你还会得到一个特殊的方法来检查 oneof 中设置了哪个值（如果有的话）。你可以在相关的 API 参考中找到更多关于你所选语言的 oneof API 的信息。

Oneof 特性

• 设置一个 oneof 字段将自动清除 oneof 的所有其他成员。所以如果你设置了几个 oneof 字段，只有你设置的*最后一个*字段仍然有值。

  SampleMessage message;
  message.set_name("name");
  CHECK_EQ(message.name(), "name");
  // Calling mutable_sub_message() will clear the name field and will set
  // sub_message to a new instance of SubMessage with none of its fields set.
  message.mutable_sub_message();
  CHECK(message.name().empty());
  

• 如果解析器在线路上遇到同一个 oneof 的多个成员，则在解析的消息中只使用最后看到的成员。在线路解析数据时，从字节的开头开始，评估下一个值，并应用以下解析规则：

  • 首先，检查同一个 oneof 中的*另一个*字段当前是否已设置，如果是，则清除它。

  • 然后像该字段不在 oneof 中一样应用内容：

    • 一个基本类型将覆盖任何已设置的值。
    • 一个消息将合并到任何已设置的值中。

• 一个 oneof 不能是 repeated。

• 反射 API 适用于 oneof 字段。

• 如果你将一个 oneof 字段设置为默认值（例如将一个 int32 oneof 字段设置为 0），该 oneof 字段的“case”将被设置，并且该值将被序列化到线路上。

• 如果你正在使用 C++，请确保你的代码不会导致内存崩溃。下面的示例代码会崩溃，因为 sub_message 已经通过调用 set_name() 方法被删除了。

  SampleMessage message;
  SubMessage* sub_message = message.mutable_sub_message();
  message.set_name("name");      // Will delete sub_message
  sub_message->set_...            // Crashes here
  

• 同样在 C++ 中，如果你 Swap() 两个带有 oneofs 的消息，每个消息最终会得到对方的 oneof case：在下面的例子中，msg1 将有一个 sub_message，而 msg2 将有一个 name。

  SampleMessage msg1;
  msg1.set_name("name");
  SampleMessage msg2;
  msg2.mutable_sub_message();
  msg1.swap(&msg2);
  CHECK(msg1.has_sub_message());
  CHECK_EQ(msg2.name(), "name");
  

向后兼容性问题

添加或删除 oneof 字段时要小心。如果检查一个 oneof 的值返回 None/NOT_SET，这可能意味着该 oneof 尚未被设置，或者它被设置为一个不同版本 oneof 中的字段。没有办法区分这两种情况，因为无法知道线路上的一个未知字段是否是该 oneof 的成员。

标签重用问题

• 将单一字段移入或移出 oneof：在消息被序列化和解析后，你可能会丢失一些信息（一些字段将被清除）。然而，你可以安全地将单个字段移入一个新的 oneof，并且如果已知只有一个字段会被设置，你可能可以移动多个字段。有关更多详细信息，请参阅更新消息类型。
• 删除一个 oneof 字段再加回来：这可能会在消息被序列化和解析后清除你当前设置的 oneof 字段。
• 拆分或合并 oneof：这与移动单一字段有类似的问题。

映射

如果你想在数据定义中创建关联映射，protocol buffers 提供了一种方便的快捷语法：

map<key_type, value_type> map_field = N;

...其中 key_type 可以是任何整数或字符串类型（即，除了浮点类型和 bytes 之外的任何标量类型）。请注意，枚举和 proto 消息都不能作为 key_type。value_type 可以是除另一个映射之外的任何类型。

因此，举例来说，如果你想创建一个项目映射，其中每个 Project 消息都与一个字符串键相关联，你可以这样定义它：

map<string, Project> projects = 3;

映射特性

• 映射字段不能是 repeated。
• 映射值的线路格式顺序和映射迭代顺序是未定义的，所以你不能依赖你的映射项会以特定的顺序排列。
• 为 .proto 生成文本格式时，映射按键排序。数字键按数值排序。
• 从线路解析或合并时，如果存在重复的映射键，则使用最后看到的键。从文本格式解析映射时，如果存在重复的键，解析可能会失败。
• 如果你为一个 map 字段提供了键但没有提供值，该字段被序列化时的行为取决于语言。在 C++、Java、Kotlin 和 Python 中，会序列化该类型的默认值，而在其他语言中则什么也不序列化。
• 符号 FooEntry 不能与 map foo 存在于同一作用域，因为 FooEntry 已经被 map 的实现使用了。

生成的 map API 目前可用于所有支持的语言。你可以在相关的 API 参考中找到更多关于你所选语言的 map API 的信息。

向后兼容性

map 语法在线路上等同于以下内容，因此不支持 map 的 protocol buffers 实现仍然可以处理你的数据：

message MapFieldEntry {
  key_type key = 1;
  value_type value = 2;
}

repeated MapFieldEntry map_field = N;

任何支持映射的 protocol buffers 实现都必须既能生成也能接受可被先前定义接受的数据。

包

你可以向 .proto 文件添加一个可选的 package 说明符，以防止协议消息类型之间的名称冲突。

package foo.bar;
message Open { ... }

然后你可以在定义你的消息类型的字段时使用包说明符：

message Foo {
  ...
  foo.bar.Open open = 1;
  ...
}

包说明符影响生成代码的方式取决于你选择的语言：

• 在 C++ 中，生成的类被包裹在一个 C++ 命名空间内。例如，Open 会在命名空间 foo::bar 中。
• 在 Java 和 Kotlin 中，除非你在你的 .proto 文件中明确提供一个 option java_package，否则该包将用作 Java 包。
• 在 Python 中，package 指令被忽略，因为 Python 模块是根据它们在文件系统中的位置来组织的。
• 在 Go 中，package 指令被忽略，生成的 .pb.go 文件位于以相应 go_proto_library Bazel 规则命名的包中。对于开源项目，你必须提供一个 go_package 选项或设置 Bazel -M 标志。
• 在 Ruby 中，生成的类被包裹在嵌套的 Ruby 命名空间内，并转换为所需的 Ruby 大写风格（首字母大写；如果第一个字符不是字母，则前缀为 PB_）。例如，Open 会在命名空间 Foo::Bar 中。
• 在 PHP 中，该包在转换为 PascalCase 后被用作命名空间，除非你在你的 .proto 文件中明确提供一个 option php_namespace。例如，Open 将在命名空间 Foo\Bar 中。
• 在 C# 中，除非你在 .proto 文件中明确提供 option csharp_namespace，否则包名在转换为 PascalCase 后将作为命名空间使用。例如，Open 将位于命名空间 Foo.Bar 中。

请注意，即使 package 指令不直接影响生成的代码（例如在 Python 中），仍然强烈建议为 .proto 文件指定包，否则可能导致描述符中的命名冲突，并使 proto 对其他语言不可移植。

包和名称解析

protocol buffer 语言中的类型名称解析方式类似于 C++：首先搜索最内层的作用域，然后是次内层，以此类推，每个包都被认为是其父包的“内层”。一个前导的‘.’（例如，.foo.bar.Baz）意味着从最外层作用域开始。

protocol buffer 编译器通过解析导入的 .proto 文件来解析所有类型名称。每种语言的代码生成器都知道如何在该语言中引用每种类型，即使它有不同的作用域规则。

定义服务

如果你想将你的消息类型与 RPC（远程过程调用）系统一起使用，你可以在 .proto 文件中定义一个 RPC 服务接口，protocol buffer 编译器将用你选择的语言生成服务接口代码和存根。因此，例如，如果你想定义一个 RPC 服务，其中有一个方法接受你的 SearchRequest 并返回一个 SearchResponse，你可以在你的 .proto 文件中这样定义它：

service SearchService {
  rpc Search(SearchRequest) returns (SearchResponse);
}

与 protocol buffers 一起使用的最直接的 RPC 系统是 gRPC：一个由 Google 开发的、语言和平台中立的开源 RPC 系统。gRPC 与 protocol buffers 配合得特别好，并允许你使用一个特殊的 protocol buffer 编译器插件直接从你的 .proto 文件生成相关的 RPC 代码。

如果你不想使用 gRPC，也可以将 protocol buffers 与你自己的 RPC 实现一起使用。你可以在Proto2 语言指南中找到更多相关信息。

还有一些正在进行的第三方项目，旨在为 Protocol Buffers 开发 RPC 实现。有关我们所知项目的链接列表，请参阅第三方附加组件维基页面。

JSON 映射

标准的 protobuf 二进制线路格式是两个使用 protobufs 的系统之间通信的首选序列化格式。为了与使用 JSON 而非 protobuf 线路格式的系统通信，Protobuf 支持在 JSON 中的规范编码。

选项

在 .proto 文件中的各个声明可以用多个选项来注解。选项不会改变声明的整体含义，但可能会影响它在特定上下文中的处理方式。可用选项的完整列表定义在 /google/protobuf/descriptor.proto 中。

一些选项是文件级选项，意味着它们应该写在顶层作用域，而不是任何消息、枚举或服务定义内部。一些选项是消息级选项，意味着它们应该写在消息定义内部。一些选项是字段级选项，意味着它们应该写在字段定义内部。选项也可以写在枚举类型、枚举值、oneof 字段、服务类型和服务方法上；然而，目前对于这些没有任何有用的选项存在。

以下是一些最常用的选项：

• java_package (文件选项): 你希望用于生成的 Java/Kotlin 类的包。如果在 .proto 文件中没有明确给出 java_package 选项，那么默认将使用 proto 包（在 .proto 文件中使用“package”关键字指定）。然而，proto 包通常不适合作为 Java 包，因为 proto 包不期望以反向域名开头。如果不生成 Java 或 Kotlin 代码，此选项无效。

  option java_package = "com.example.foo";
  

• java_outer_classname（文件选项）：你想要生成的包装 Java 类的类名（因此也是文件名）。如果在 .proto 文件中没有明确指定 java_outer_classname，类名将通过将 .proto 文件名转换为驼峰式来构造（所以 foo_bar.proto 变为 FooBar.java）。如果 java_multiple_files 选项被禁用，那么为 .proto 文件生成的所有其他类/枚举等都将作为嵌套类/枚举等生成在此外层包装 Java 类内部。如果不生成 Java 代码，此选项无效。

  option java_outer_classname = "Ponycopter";
  

• java_multiple_files (文件选项): 如果为 false，则只会为此 .proto 文件生成单个 .java 文件，并且为顶级消息、服务和枚举生成的所有 Java 类/枚举/等都将嵌套在一个外部类中（参见 java_outer_classname）。如果为 true，则会为顶级消息、服务和枚举生成的每个 Java 类/枚举/等生成单独的 .java 文件，并且为此 .proto 文件生成的包装器 Java 类将不包含任何嵌套的类/枚举/等。这是一个布尔选项，默认为 false。如果不生成 Java 代码，此选项无效。

  option java_multiple_files = true;
  

• optimize_for（文件选项）：可以设置为 SPEED、CODE_SIZE 或 LITE_RUNTIME。这会以下列方式影响 C++ 和 Java 代码生成器（以及可能的第三方生成器）：

  • SPEED (默认): protocol buffer 编译器将生成用于序列化、解析以及对你的消息类型执行其他常见操作的代码。此代码经过高度优化。
  • CODE_SIZE: protocol buffer 编译器将生成最小的类，并依赖于共享的、基于反射的代码来实现序列化、解析和各种其他操作。因此，生成的代码将比使用 SPEED 时小得多，但操作会更慢。类仍将实现与 SPEED 模式下完全相同的公共 API。此模式最适用于包含大量 .proto 文件且不需要所有文件都快如闪电的应用程序。
  • LITE_RUNTIME：protocol buffer 编译器将生成仅依赖于“lite”运行时库（libprotobuf-lite 而非 libprotobuf）的类。lite 运行时比完整库小得多（大约小一个数量级），但省略了描述符和反射等某些功能。这对于在像手机这样的受限平台上运行的应用程序特别有用。编译器仍将像在 SPEED 模式下一样生成所有方法的快速实现。生成的类在每种语言中将只实现 MessageLite 接口，该接口只提供完整 Message 接口方法的一个子集。

  option optimize_for = CODE_SIZE;
  

• cc_generic_services, java_generic_services, py_generic_services (文件选项): 通用服务已被弃用。 protocol buffer 编译器是否应该分别在 C++、Java 和 Python 中基于服务定义生成抽象服务代码。由于历史原因，这些默认为 true。然而，自版本 2.3.0（2010 年 1 月）起，RPC 实现更倾向于提供代码生成器插件来生成更特定于每个系统的代码，而不是依赖于“抽象”服务。

  // This file relies on plugins to generate service code.
  option cc_generic_services = false;
  option java_generic_services = false;
  option py_generic_services = false;
  

• cc_enable_arenas (文件选项): 为 C++ 生成的代码启用 arena 分配。

• objc_class_prefix (文件选项): 设置 Objective-C 类前缀，该前缀会添加到此 .proto 生成的所有 Objective-C 类和枚举的前面。没有默认值。你应该使用长度为 3-5 个大写字符的前缀，如 Apple 推荐。请注意，所有 2 个字母的前缀都由 Apple 保留。

• packed（字段选项）：对于基本数值类型的重复字段，默认为 true，导致使用更紧凑的编码。要使用未打包的线路格式，可以将其设置为 false。这提供了与 2.3.0 版本之前的解析器的兼容性（很少需要），如下例所示：

  repeated int32 samples = 4 [packed = false];
  

• deprecated (字段选项): 如果设置为 true，表示该字段已被弃用，新代码不应使用。在大多数语言中，这没有实际效果。在 Java 中，这会成为一个 @Deprecated 注解。对于 C++，clang-tidy 会在每次使用已弃用字段时生成警告。将来，其他特定语言的代码生成器可能会在该字段的访问器上生成弃用注解，这反过来会导致在编译试图使用该字段的代码时发出警告。如果该字段无人使用，并且你想阻止新用户使用它，可以考虑用一个保留语句替换该字段声明。

  int32 old_field = 6 [deprecated = true];
  

枚举值选项

支持枚举值选项。你可以使用 deprecated 选项来指示某个值不应再使用。你还可以使用扩展创建自定义选项。

下面的例子展示了添加这些选项的语法：

import "google/protobuf/descriptor.proto";

extend google.protobuf.EnumValueOptions {
  optional string string_name = 123456789;
}

enum Data {
  DATA_UNSPECIFIED = 0;
  DATA_SEARCH = 1 [deprecated = true];
  DATA_DISPLAY = 2 [
    (string_name) = "display_value"
  ];
}

读取 string_name 选项的 C++ 代码可能看起来像这样：

const absl::string_view foo = proto2::GetEnumDescriptor<Data>()
    ->FindValueByName("DATA_DISPLAY")->options().GetExtension(string_name);

请参阅自定义选项，了解如何将自定义选项应用于枚举值和字段。

自定义选项

Protocol Buffers 还允许你定义和使用自己的选项。请注意，这是一个高级功能，大多数人不需要。如果你确实认为需要创建自己的选项，请参阅Proto2 语言指南了解详情。请注意，创建自定义选项使用扩展，在 proto3 中仅允许用于自定义选项。

选项保留

选项具有保留的概念，它控制选项是否在生成的代码中保留。选项默认具有运行时保留，这意味着它们在生成的代码中被保留，因此在运行时在生成的描述符池中可见。但是，你可以设置 retention = RETENTION_SOURCE 来指定一个选项（或选项中的字段）在运行时不得保留。这称为源保留。

选项保留是一个高级功能，大多数用户无需担心，但如果你想使用某些选项而不想在二进制文件中为保留它们付出代码大小的代价，它可能会很有用。具有源保留的选项对 protoc 和 protoc 插件仍然可见，因此代码生成器可以使用它们来自定义其行为。

保留可以直接在选项上设置，如下所示：

extend google.protobuf.FileOptions {
  optional int32 source_retention_option = 1234
      [retention = RETENTION_SOURCE];
}

它也可以设置在一个普通字段上，在这种情况下，它仅在该字段出现在选项内部时生效：

message OptionsMessage {
  int32 source_retention_field = 1 [retention = RETENTION_SOURCE];
}

你可以设置 retention = RETENTION_RUNTIME，但这没有效果，因为这是默认行为。当一个消息字段被标记为 RETENTION_SOURCE 时，它的全部内容都会被丢弃；其内部的字段不能通过尝试设置 RETENTION_RUNTIME 来覆盖它。

选项目标

字段有一个 targets 选项，它控制了该字段在作为选项使用时可以应用于的实体类型。例如，如果一个字段有 targets = TARGET_TYPE_MESSAGE，那么该字段就不能在一个枚举（或任何其他非消息实体）的自定义选项中设置。Protoc 会强制执行这一点，如果违反了目标约束，将会引发错误。

乍一看，这个功能似乎没有必要，因为每个自定义选项都是特定实体的选项消息的扩展，这已经将选项限制在该一个实体上。然而，当您有一个应用于多个实体类型的共享选项消息，并且您想控制该消息中各个字段的使用时，选项目标就很有用了。例如：

message MyOptions {
  string file_only_option = 1 [targets = TARGET_TYPE_FILE];
  int32 message_and_enum_option = 2 [targets = TARGET_TYPE_MESSAGE,
                                     targets = TARGET_TYPE_ENUM];
}

extend google.protobuf.FileOptions {
  optional MyOptions file_options = 50000;
}

extend google.protobuf.MessageOptions {
  optional MyOptions message_options = 50000;
}

extend google.protobuf.EnumOptions {
  optional MyOptions enum_options = 50000;
}

// OK: this field is allowed on file options
option (file_options).file_only_option = "abc";

message MyMessage {
  // OK: this field is allowed on both message and enum options
  option (message_options).message_and_enum_option = 42;
}

enum MyEnum {
  MY_ENUM_UNSPECIFIED = 0;
  // Error: file_only_option cannot be set on an enum.
  option (enum_options).file_only_option = "xyz";
}

生成你的类

要生成你需要用来处理 .proto 文件中定义的消息类型的 Java、Kotlin、Python、C++、Go、Ruby、Objective-C 或 C# 代码，你需要在 .proto 文件上运行 protocol buffer 编译器 protoc。如果你还没有安装编译器，请下载软件包并按照 README 中的说明操作。对于 Go，你还需要为编译器安装一个特殊的代码生成器插件；你可以在 GitHub 上的 golang/protobuf 仓库中找到它和安装说明。

协议编译器的调用方式如下：

protoc --proto_path=IMPORT_PATH --cpp_out=DST_DIR --java_out=DST_DIR --python_out=DST_DIR --go_out=DST_DIR --ruby_out=DST_DIR --objc_out=DST_DIR --csharp_out=DST_DIR path/to/file.proto

• IMPORT_PATH 指定了在解析 import 指令时查找 .proto 文件的目录。如果省略，则使用当前目录。可以通过多次传递 --proto_path 选项来指定多个导入目录。-I=_IMPORT_PATH_ 可以作为 --proto_path 的缩写形式使用。

注意： 相对于其 proto_path 的文件路径在给定的二进制文件中必须是全局唯一的。例如，如果你有 proto/lib1/data.proto 和 proto/lib2/data.proto，这两个文件不能与 -I=proto/lib1 -I=proto/lib2 一起使用，因为 import "data.proto" 的含义会不明确。相反，应该使用 -Iproto/，全局名称将是 lib1/data.proto 和 lib2/data.proto。

如果你正在发布一个库，并且其他用户可能会直接使用你的消息，你应该在他们预期使用的路径中包含一个唯一的库名，以避免文件名冲突。如果一个项目中有多个目录，最好的做法是倾向于将一个 -I 设置为项目的顶层目录。

• 你可以提供一个或多个输出指令：

  • --cpp_out 在 DST_DIR 中生成 C++ 代码。更多信息请参阅 C++ 生成代码参考。
  • --java_out 在 DST_DIR 中生成 Java 代码。更多信息请参阅 Java 生成代码参考。
  • --kotlin_out 在 DST_DIR 中生成额外的 Kotlin 代码。更多信息请参阅Kotlin 生成代码参考。
  • --python_out 在 DST_DIR 中生成 Python 代码。更多信息请参阅 Python 生成代码参考。
  • --go_out 在 DST_DIR 中生成 Go 代码。更多信息请参阅Go 生成代码参考。
  • --ruby_out 在 DST_DIR 中生成 Ruby 代码。更多信息请参阅 Ruby 生成代码参考。
  • --objc_out 在 DST_DIR 中生成 Objective-C 代码。更多信息请参阅 Objective-C 生成代码参考。
  • --csharp_out 在 DST_DIR 中生成 C# 代码。更多信息请参阅 C# 生成代码参考。
  • --php_out 在 DST_DIR 中生成 PHP 代码。更多信息请参阅 PHP 生成代码参考。

  为了更加方便，如果 DST_DIR 以 .zip 或 .jar 结尾，编译器将把输出写入一个以给定名称命名的 ZIP 格式的单个存档文件。.jar 输出还将根据 Java JAR 规范的要求提供一个清单文件。请注意，如果输出存档已存在，它将被覆盖。

• 你必须提供一个或多个 .proto 文件作为输入。可以一次指定多个 .proto 文件。虽然文件是相对于当前目录命名的，但每个文件必须位于其中一个 IMPORT_PATH 中，以便编译器可以确定其规范名称。

文件位置

最好不要将 .proto 文件与其他语言的源文件放在同一个目录中。考虑在你的项目根包下为 .proto 文件创建一个子包 proto。

位置应与语言无关

在处理 Java 代码时，将相关的 .proto 文件放在与 Java 源文件相同的目录中会很方便。但是，如果有任何非 Java 代码使用相同的 protos，路径前缀将不再有意义。因此，通常情况下，将 protos 放在一个相关的、与语言无关的目录中，例如 //myteam/mypackage。

这条规则的例外是当很明显 protos 只会在 Java 上下文中使用时，例如用于测试。

支持的平台

有关信息

• 支持的操作系统、编译器、构建系统和 C++ 版本，请参阅 基础 C++ 支持政策。
• 支持的 PHP 版本，请参阅支持的 PHP 版本。