1 encoding

Protocol Buffers Encoding This document describes the binary wire format for protocol buffer messages. You don't need to understand this to use protocol buffers in your applications, but it can be very useful to know how different protocol buffer formats affect the size of your encoded messages.

1.1 A Simple Message

1.2 Base 128 Varints

key message
most significant bit(msb)

1.3 Message Structure

key message
wire-format The available wire types are as follows:
| Type | Meaning | Used For | | :---- | :-------- | | | 0 | Varint | int32, int64, uint32, uint64, sint32, sint64, bool, enum | | 1 | 64-bit | fixed64, sfixed64, double | | 2 | Length-delimited | string, bytes, embedded messages, packed repeated fields | | 3 | Start group | groups (deprecated) | | 4 | End group | groups (deprecated) | | 5 | 32-bit | fixed32, sfixed32, float |
Each key in the streamed message is a varint with the value (field_number << 3) | wire_type – in other words, the last three bits of the number store the wire type.

1.4 More Value Types

1.4.1 Signed Integers

key message
If you useint32orint64as the type for a negative number, the resulting varint isalways ten bytes long– it is, effectively, treated like a very large unsigned integer. If you use one of the signed types, the resulting varint uses ZigZag encoding, which is much more efficient.
In other words, each value n is encoded using

 (n << 1) ^ (n >> 31)

for sint32s, or

 (n << 1) ^ (n >> 63)

for the 64-bit version.

1.4.2 Non-varint Numbers

1.4.3 Strings

1.5 Embedded Messages

1.6 Optional And Repeated Elements

1.6.1 Packed Repeated Fields

Version 2.1.0 introduced packed repeated fields, which in proto2 are declared like repeated fields but with the special [packed=true] option. In proto3, repeated fields are packed by default.
For example, imagine you have the message type:

message Test4 {
 repeated int32 d = 4 [packed=true];
}```
> * * *
> Now let's say you construct a Test4, providing the values 3, 270, and 86942 for the repeated field d. Then, the encoded form would be:

22//tag (field number 4, wire type 2) 06//payload size (6 bytes) 03//first element (varint 3) 8E 02//second element (varint 270) 9E A7 05//third element (varint 86942)

> Only repeated fields of primitive numeric types (types which use the varint, 32-bit, or 64-bit wire types) can be declared "packed".

##1.7 Field Order

 
[ ]Protocol Buffers Encoding
http://blog.csdn.net/andyelvis/article/details/7315464
Google Protocol Buffers  (Encoding) -   -  .html
http://www.cnblogs.com/shitouer/archive/2013/04/12/google-protocol-buffers-encoding.html
 Protobuf  - zxh  -   - CSDN.NET.html http://blog.csdn.net/zxhoo/article/details/53228303
primitive - Is there ever a good time to use int32 instead of sint32 in Google Protocol Buffers_ - Stack Overflow.html
http://stackoverflow.com/questions/765916/is-there-ever-a-good-time-to-use-int32-instead-of-sint32-in-google-protocol-buff
Missing value_null support for scalar value types in proto 3 · Issue #1606 · google_protobuf · GitHub.html
https://github.com/google/protobuf/issues/1606