protocol buffers的编码原理

protocol buffers使用二进制传输格式传递消息,因此相比于xml,json来说要轻便很多。

示例:假设定义了一个Message

message Test1 {
  required int32 a = 1;
}

实际使用的时候将a设置为150,然后将其序列化到输出流,查看编码后的message,可以看到如下3个byte

08 96 01

解析:

上述三个字节实际分为两部分: 08  96 01。第一部分(08)包含了message成员变量的field number(a=1)和变量类型(Varint),第二部分(96 01)为a的实际值150。

这里面涉及几个概念:

  Varint:这个可以理解为可变长的int类型,数值越小使用的byte越少;

  field number和type:protocol buffer消息为一系列的key-value对。二进制版本的消息使用field number作为key

.proto 说明 C++ Java Python Go Ruby C# PHP
double   double double float float64 Float double float
float   float float float float32 Float float float
int32 使用变长编码,对负数编码效率低,如果你的变量可能是负数,可以使用sint32 int32 int int int32 Fixnum or Bignum (as required) int integer
int64 使用变长编码,对负数编码效率低,如果你的变量可能是负数,可以使用sint64 int64 long int/long int64 Bignum long integer/string
uint32 使用变长编码 uint32 int int/long uint32 Fixnum or Bignum (as required) uint integer
uint64 使用变长编码 uint64 long int/long uint64 Bignum ulong integer/string
sint32 使用变长编码,带符号的int类型,对负数编码比int32高效 int32 int int int32 Fixnum or Bignum (as required) int integer
sint64 使用变长编码,带符号的int类型,对负数编码比int64高效 int64 long int/long int64 Bignum long integer/string
fixed32 4字节编码, 如果变量经常大于228228 的话,会比uint32高效 uint32 int int int32 Fixnum or Bignum (as required) uint integer
fixed64 8字节编码, 如果变量经常大于256256 的话,会比uint64高效 uint64 long int/long uint64 Bignum ulong integer/string
sfixed32 4字节编码 int32 int int int32 Fixnum or Bignum (as required) int integer
sfixed64 8字节编码 int64 long int/long int64 Bignum long integer/string
bool   bool boolean bool bool TrueClass/FalseClass bool boolean
string 必须包含utf-8编码或者7-bit ASCII text string String str/unicode string String (UTF-8) string string
bytes 任意的字节序列 string ByteString str []byte String (ASCII-8BIT) ByteString string

参考:Encoding

原文地址:https://www.cnblogs.com/charlieroro/p/9005033.html

时间: 2024-10-23 02:30:13

protocol buffers的编码原理的相关文章

理解netty对protocol buffers的编码解码

一,netty+protocol buffers简要说明 Netty是业界最流行的NIO框架之一优点:1)API使用简单,开发门槛低:2)功能强大,预置了多种编解码功能,支持多种主流协议:3)定制能力强,可以通过ChannelHandler对通信框架进行灵活的扩展:4)性能高,通过与其它业界主流的NIO框架对比,Netty的综合性能最优:5)成熟.稳定,Netty修复了已经发现的所有JDK NIO BUG,业务开发人员不需要再为NIO的BUG而烦恼:6)社区活跃,版本迭代周期短,发现的BUG可以

Google Protocol Buffers 编码(Encoding)

Google Protocol Buffers 编码(Encoding) 1. 概述 前三篇文章<Google Protocol Buffers 概述><Google Protocol Buffers 入门><Protocol Buffers 语法指南> 一步一步将大家带入Protocol Buffers的世界,我们已经基本能够使用Protocol Buffers生成代码,编码,解析,输出级读入序列化数据.该篇主要讲述PB message的底层二进制格式.不了解该部分内

Protocol Buffers(2):编码与解码

目录 Message Structure 解码代码一窥 varint Protobuf中的整数和浮点数 Length-delimited相关类型 小结 参考 博客:blog.shinelee.me | 博客园 | CSDN Message Structure 在上一篇文章中我们提到,对于序列化后字节流,需要回答的一个重要问题是"从哪里到哪里是哪个数据成员". message中每一个field的格式为: required/optional/repeated FieldType Field

Protocol Buffers官方文档(开发指南)

本文是对官方文档的翻译,然后截取了一篇非常优秀的文章片段来帮助理解,本人英文水平有限,基本都是直译,如果有不理解的地方请参考英文官方文档,参考的文章链接在文章末尾 protocol buffers简介 protocol buffer是google的一个开源项目,它是用于结构化数据串行化的灵活.高效.自动的方法,例如XML,不过它比xml更小.更快.也更简单.你可以定义自己的数据结构,然后使用代码生成器生成的代码来读写这个数据结构.你甚至可以在无需重新部署程序的情况下更新数据结构 protocol

Protocol Buffers(Protobuf)开发者指南---概览

Protocol Buffers(Protobuf)开发者指南---概览 欢迎来到protocol buffers的开发者指南文档,protocol buffers是一个与编程语言无关‘.系统平台无关.可扩展的结构化数据序列化/反序列化工具,适用于通讯协议,数据存储等场合. ps:为了方便拼写,下文的protobuf就是指protocol buffers. 本文档的面向读者是:希望使用protobuf的 Java.C++.Python的开发者.此概览将向您介绍如何开始使用protobuf,然后您

Protocol Buffers(Protobuf) 官方文档--Protobuf语言指南

Protocol Buffers(Protobuf) 官方文档--Protobuf语言指南 约定:为方便书写,ProtocolBuffers在下文中将已Protobuf代替. 本指南将向您描述如何使用protobuf定义i结构化Protobuf数据,包括.proto文件语法和如何使用.proto文件生成数据存取类. 作为一个参考指南,本文档将以示例的形式一步步向您介绍Protobuf的特点.您可以参考您所选择的语言的示例.tutorial ----------------------------

FlatBuffers vs Protocol Buffers

FlatBuffers去年发布,最近看了一下,与同是出自Google之手的Protocol Buffers非常类似.在官网上介绍,FlatBuffers(简称FB)主要针对game development和对性能有要求的应用.相对于Protocol Buffers(简称PB),FB不需要解析,只通过序列化后的二进制buffer即可完成数据访问. FB的主要特点有: 1)数据访问不需要解析 将数据序列化成二进制buffer,之后的数据访问直接读取这个buffer,所以读取的效率很高. 2)内存高效

使用 Protocol Buffers 代替 JSON 的五个原因

在Ruby和Rails开发者中,面向服务(Service-Oriented)架构有一个当之无愧的名声,它是一个缓解程序规模恶性增长的一个强有力的途径,可在大量应用程序中提取关注点.这些新生小巧的服务通常继续使用Rails或Sinatra,并使用JSON在HTTP上通信.尽管JSON作为一个数据相互交换格式,有很多优点:人类可读.可理解,并通常表现出色. 浏览器和JS并不直接处理数据--尤其是遇到内部服务时.我的观点是,结构化格式,例如谷歌的Protocol Buffers,是一个比JSON在编码

(转)Protocol Buffers for C

我一直不太满意 google protocol buffers 的默认设计.为每个 message type 生成一大坨 C++ 代码让我很难受.而且官方没有提供 C 版本,第三方的 C 版本 也不让我满意. 这种设计很难让人做动态语言的 binding ,而大多数动态语言往往又没有强类型检查,采用生成代码的方式并没有特别的好处,反而有很大的性能损失(和通常做一个 bingding 库的方式比较).比如官方的 Python 库,完全可以在运行时,根据协议,把那些函数生成出来,而不必用离线的工具生