JSON 和 Protocol Buffers 之间是否有标准映射？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2544580/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is there a standard mapping between JSON and Protocol Buffers?
提问by Daniel Earwicker
From a comment on the announcement blog post:
来自对公告博客文章的评论：
Regarding JSON: JSON is structured similarly to Protocol Buffers, but protocol buffer binary format is still smaller and faster to encode. JSON makes a great text encoding for protocol buffers, though -- it's trivial to write an encoder/decoder that converts arbitrary protocol messages to and from JSON, using protobuf reflection. This is a good way to communicate with AJAX apps, since making the user download a full protobuf decoder when they visit your page might be too much.
关于 JSON：JSON 的结构与 Protocol Buffers 类似，但 Protocol Buffers 二进制格式仍然更小，编码速度更快。然而，JSON 为协议缓冲区提供了一种很好的文本编码——编写一个编码器/解码器来将任意协议消息与 JSON 相互转换，使用 protobuf 反射是微不足道的。这是与 AJAX 应用程序通信的好方法，因为让用户在访问您的页面时下载完整的 protobuf 解码器可能太多了。
It may be trivial to cook up amapping, but is there a single "obvious" mapping between the two that any two separate dev teams would naturally settle on? If two products supported PB data and could interoperate because they shared the same .proto spec, I wonder if they would still be able to interoperate if they independently introduced a JSON reflection of the same spec. There might be some arbitrary decisions to be made, e.g. should enum values be represented by a string (to be human-readable a la typical JSON) or by their integer value?
制作一个映射可能是微不足道的，但是两者之间是否存在任何两个独立的开发团队自然会选择的单一“明显”映射？如果两个产品都支持 PB 数据并且可以互操作，因为它们共享相同的 .proto 规范，我想知道如果它们独立引入相同规范的 JSON 反射，它们是否仍然能够互操作。可能需要做出一些任意的决定，例如枚举值应该由字符串表示（为了人类可读的典型 JSON）还是由它们的整数值表示？
So is there an established mapping, and any open source implementations for generating JSON encoder/decoders from .proto specs?
那么是否有一个既定的映射，以及任何用于从 .proto 规范生成 JSON 编码器/解码器的开源实现？
采纳答案by Erik Sj?lund
Yes, since Protocol Buffers version 3.0.0 (released July 28, 2016) there is "A well-defined encoding in JSON as an alternative to binary proto encoding"as mentioned in the release notes
是的，自 Protocol Buffers 3.0.0 版（2016 年 7 月 28 日发布）以来，发行说明中提到了“JSON 中定义明确的编码作为二进制 proto 编码的替代方案”
回答by Aravind Yarram
May be this is helpful http://code.google.com/p/protobuf-java-format/
回答by StaxMan
From what I have seen, Protostuffis the project to use for any PB work on Java, including serializing it as JSON, based on protocol definition. I have not used it myself, just heard good things.
据我所知，Protostuff是用于 Java 上任何 PB 工作的项目，包括根据协议定义将其序列化为 JSON。我自己没用过，只是听说好东西。
回答by Kirby
I needed to marshal from GeneratedMessageLite to a JSON object but did not need to unmarshal. I couldn't use the protobuf library in Pangea's answer because it doesn't work with the LITE_RUNTIME option. I also didn't want to burden our already large legacy system with generating more compiled code for the existing protocol buffers. For mashalling to JSON, I went with this simple solution to marshal
我需要从 GeneratedMessageLite 编组到 JSON 对象，但不需要解组。我无法在 Pangea 的答案中使用 protobuf 库，因为它不适用于 LITE_RUNTIME 选项。我也不想为现有的协议缓冲区生成更多的编译代码给我们已经很大的遗留系统带来负担。为了将 JSON 混编，我使用了这个简单的解决方案来编组
final Person gpb = Person.newBuilder().setName("Bill Monroe").build();
final Gson gson = new Gson();
final String jsonString = gson.toJson(gpb);
回答by StaxMan
One further thought: if protobuf objects have getters/setters, or appropriately named fields, one could simply use HymansonJSON processor's data binding. By default it handles public getters, any setters and public fields, but these are just default visibility levels and can be changed. If so, Hymanson can serialize/deserialize protobuf generated POJOs without problems.
进一步的想法：如果 protobuf 对象具有 getter/setter 或适当命名的字段，则可以简单地使用HymansonJSON 处理器的数据绑定。默认情况下，它处理公共 getter、任何 setter 和公共字段，但这些只是默认可见性级别，可以更改。如果是这样，Hymanson 可以毫无问题地序列化/反序列化 protobuf 生成的 POJO。
I have actually used this approach with Thrift-generated objects; the only thing I had to configure there was to disable serialization of various "isXXX()" methods that Thrift adds for checking if a field has been explicitly assigned or not.
我实际上已经将这种方法用于 Thrift 生成的对象；我必须在那里配置的唯一一件事是禁用 Thrift 添加的各种“isXXX()”方法的序列化，以检查是否已显式分配字段。
回答by Pramit
First of all I think one should reason very carefully on putting an effort into converting a dataset to protobuffs. Here my reasons to convert a data-set to protobuffs
首先，我认为在努力将数据集转换为 protobuff 时应该非常仔细地推理。这是我将数据集转换为 protobuffs 的原因
- Type Safety: guarantee on the format of the data being considered.
- uncompressed memory foot-print of the data. The reason I mention un-compressed is because post compression there isn't much of a difference in the size of JSON compressed and proto compressed but compression has a cost associated with it. Also, the serialization/de-serialization speed is almost similar, infact Hymanson json is faster than protobuffs. Please checkout the following link for more information http://technicalrex.com/2014/06/23/performance-playground-Hymanson-vs-protocol-buffers/
- The protobuffs needs to be transferred over the network a lot.
- 类型安全：对所考虑数据格式的保证。
- 数据的未压缩内存占用。我提到未压缩的原因是因为压缩后的 JSON 压缩和 proto 压缩的大小没有太大区别，但压缩有与之相关的成本。此外，序列化/反序列化速度几乎相似，事实上 Hymanson json 比 protobuffs 快。请查看以下链接以获取更多信息 http://technicalrex.com/2014/06/23/performance-playground-Hymanson-vs-protocol-buffers/
- protobuff 需要通过网络进行大量传输。
Saying that once you convert your data-set to Hymanson JSON format in the way that the ProtoBuff definition is defined then it can very easily be directly mapped to ProtoBuff format using the Protostuff:JsonIoUtil:mergeFrom function. Signature of the function :
说一旦你以定义 ProtoBuff 定义的方式将你的数据集转换为 Hymanson JSON 格式，那么它可以很容易地使用 Protostuff:JsonIoUtil:mergeFrom 函数直接映射到 ProtoBuff 格式。函数签名：
public static <T> void mergeFrom(JsonParser parser, T message, Schema<T> schema, boolean numeric)
Reference to protostuff
