高效的數據壓縮編碼方式 Protobuf

github地址

目錄

• ProtocolBuffers 是什么
• 為什么要發明 ProtocolBuffers
• proto3 定義 Message
  • 分配字段編號
  • 保留字段
  • 默認字段規則
  • 各個語言標量類型對應關系
  • 枚舉
  • 枚舉中的保留值
  • 允許嵌套
  • 枚舉不兼容性
  • 更新 Message
  • 未知字段
  • Map 類型
  • JsonMapping
• proto3 定義 Services
• ProtocolBuffer 命名規范
• ProtocolBuffer 編碼原理
  • MessageStructure 編碼
  • SignedIntegers 編碼
  • Non-varint Numbers
  • 字符串
  • 嵌套式 Message
  • Optional 和 Repeated 的編碼
  • PackedRepeatedFields
  • MessageStructure 編碼
  • FieldOrder
• protocolBuffers 的優缺點
• 最后

ProtocolBuffers是什么

Protocol buffers 是一種語言中立，平臺無關，可擴展的序列化數據的格式，可用于通信協議，數據存儲等。

Protocol buffers 在序列化數據方面，它是靈活的，高效的。相比于 XML 來說，Protocol buffers 更加小巧，更加快速，更加簡單。一旦定義了要處理的數據的數據結構之后，就可以利用 Protocol buffers 的代碼生成工具生成相關的代碼。甚至可以在無需重新部署程序的情況下更新數據結構。只需使用 Protobuf 對數據結構進行一次描述，即可利用各種不同語言或從各種不同數據流中對你的結構化數據輕松讀寫。

Protocol buffers 很適合做數據存儲或 RPC 數據交換格式。可用于通訊協議、數據存儲等領域的語言無關、平臺無關、可擴展的序列化結構數據格式。

為什么要發明ProtocolBuffers

大家可能會覺得 Google 發明 protocol buffers 是為了解決序列化速度的，其實真實的原因并不是這樣的。

protocol buffers 最先開始是 google 用來解決索引服務器 request/response 協議的。沒有 protocol buffers 之前，google 已經存在了一種 request/response 格式，用于手動處理 request/response 的編組和反編組。它也能支持多版本協議，不過代碼比較丑陋：

if (version == 3) {...} else if (version > 4) {if (version == 5) {...}...}

如果非常明確的格式化協議，會使新協議變得非常復雜。因為開發人員必須確保請求發起者與處理請求的實際服務器之間的所有服務器都能理解新協議，然后才能切換開關以開始使用新協議。

這也就是每個服務器開發人員都遇到過的低版本兼容、新舊協議兼容相關的問題。

protocol buffers 為了解決這些問題，于是就誕生了。protocol buffers 被寄予一下 2 個特點：

• 可以很容易地引入新的字段，并且不需要檢查數據的中間服務器可以簡單地解析并傳遞數據，而無需了解所有字段。
• 數據格式更加具有自我描述性，可以用各種語言來處理(C++, Java 等各種語言)
  這個版本的 protocol buffers 仍需要自己手寫解析的代碼。

不過隨著系統慢慢發展，演進，protocol buffers 目前具有了更多的特性：

• 自動生成的序列化和反序列化代碼避免了手動解析的需要。（官方提供自動生成代碼工具，各個語言平臺的基本都有）
• 除了用于 RPC（遠程過程調用）請求之外，人們開始將 protocol buffers 用作持久存儲數據的便捷自描述格式（例如，在Bigtable中）。
• 服務器的 RPC 接口可以先聲明為協議的一部分，然后用 protocol compiler 生成基類，用戶可以使用服務器接口的實際實現來覆蓋它們。

protocol buffers 現在是 Google 用于數據的通用語言。在撰寫本文時，谷歌代碼樹中定義了 48162 種不同的消息類型，包括 12183 個 .proto 文件。它們既用于 RPC 系統，也用于在各種存儲系統中持久存儲數據。

小結：
protocol buffers 誕生之初是為了解決服務器端新舊協議(高低版本)兼容性問題，名字也很體貼，“協議緩沖區”。只不過后期慢慢發展成用于傳輸數據。

Protocol Buffers 命名由來：

Why the name “Protocol Buffers”?
The name originates from the early days of the format, before we had the protocol buffer compiler to generate classes for us. At the time, there was a class called ProtocolBuffer which actually acted as a buffer for an individual method. Users would add tag/value pairs to this buffer individually by calling methods like AddValue(tag, value). The raw bytes were stored in a buffer which could then be written out once the message had been constructed.

Since that time, the “buffers” part of the name has lost its meaning, but it is still the name we use. Today, people usually use the term “protocol message” to refer to a message in an abstract sense, “protocol buffer” to refer to a serialized copy of a message, and “protocol message object” to refer to an in-memory object representing the parsed message.

這個名字起源于 format 早期，在我們有 protocol buffer 編譯器為我們生成類之前。當時，有一個名為 ProtocolBuffer 的類，它實際上充當了單個方法的緩沖區。用戶可以通過調用像 AddValue(tag,value) 這樣的方法分別將標簽/值對添加到此緩沖區。原始字節存儲在一個緩沖區中，一旦構建消息就可以將其寫出。

從那時起，名為“緩沖”的部分已經失去了意義，但它仍然是我們使用的名稱。今天，人們通常使用術語“protocol message”來指代抽象意義上的消息，“protocol buffer”指的是消息的序列化副本，而“protocol message object”指的是代表內存中對象解析的消息。

回到頂部

proto3定義Message

目前 protocol buffers 最新版本是 proto3，與老的版本 proto2 還是有些區別的。這兩個版本的 API 不完全兼容。

proto2 和 proto3 的名字看起來有點撲朔迷離，那是因為當我們最初開源的 protocol buffers 時，它實際上是 Google 的第二個版本了，所以被稱為 proto2，這也是我們的開源版本號從 v2 開始的原因。初始版名為 proto1，從 2001 年初開始在谷歌開發的。

在 proto 中，所有結構化的數據都被稱為 message。

message helloworld {required int32 id = 1; // IDrequired string str = 2; // stroptional int32 opt = 3; //optional field }

上面這幾行語句，定義了一個消息 helloworld，該消息有三個成員，類型為 int32 的 id，另一個為類型為 string 的成員 str。opt 是一個可選的成員，即消息中可以不包含該成員。

接下來說明一些 proto3 中需要注意的地方。

syntax = "proto3";message SearchRequest {string query = 1;int32 page_number = 2;int32 result_per_page = 3; }

如果開頭第一行不聲明 syntax = "proto3";，則默認使用 proto2 進行解析。

分配字段編號

每個消息定義中的每個字段都有唯一的編號。這些字段編號用于標識消息二進制格式中的字段，并且在使用消息類型后不應更改。請注意，范圍 1 到 15 中的字段編號需要一個字節進行編碼，包括字段編號和字段類型（具體原因見 Protocol Buffer 編碼原理 這一章節）。范圍 16 至 2047 中的字段編號需要兩個字節。所以你應該保留數字 1 到 15 作為非常頻繁出現的消息元素。請記住為將來可能添加的頻繁出現的元素留出一些空間。

可以指定的最小字段編號為1，最大字段編號為 2²⁹-1 或 536, 870, 911。也不能使用數字 19000 到 19999 (FieldDescriptor :: kFirstReservedNumber 到 FieldDescriptor :: kLastReservedNumber)，因為它們是為 Protocol Buffers 實現保留的。

如果在 .proto 中使用這些保留數字中的一個， Protocol Buffers 編譯的時候會報錯。

同樣，您不能使用任何以前 Protocol Buffers 保留的一些字段號碼。保留字段是什么，下一節詳細說明。

保留字段

如果您通過完全刪除某個字段或將其注釋掉來更新消息類型，那么未來的用戶可以在對該類型進行自己的更新時重新使用該字段號。如果稍后加載到了的舊版本 .proto 文件，則會導致服務器出現嚴重問題，例如數據混亂，隱私錯誤等等。確保這種情況不會發生的一種方法是指定刪除字段的字段編號（或名稱，這也可能會導致 JSON 序列化問題）為 reserved 。如果將來的任何用戶試圖使用這些字段標識符， Protocol Buffers 編譯器將會報錯。

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

注意，不能在同一個 reserved 語句中混合字段名稱和字段編號。 如有需要需要像上面這個例子這樣寫。

默認字段規則

• 字段名不能重復，必須唯一。
• repeated 字段：可以在一個 message 中重復任何數字多次(包括 0 )，不過這些重復值的順序被保留。

在 proto3 中，純數字類型的 repeated 字段編碼時候默認采用 packed 編碼（具體原因見 Protocol Buffer 編碼原理 這一章節）

各個語言標量類型對應關系

枚舉

在 message 中可以嵌入枚舉類型。

message SearchRequest {string query = 1;int32 page_number = 2;int32 result_per_page = 3;enum Corpus {UNIVERSAL = 0;WEB = 1;IMAGES = 2;LOCAL = 3;NEWS = 4;PRODUCTS = 5;VIDEO = 6;}Corpus corpus = 4; }

枚舉類型需要注意的是，一定要有 0 值。

• 枚舉為 0 的是作為零值，當不賦值的時候，就會是零值。
• 為了和 proto2 兼容。在 proto2 中，零值必須是第一個值。

另外在反序列化的過程中，無法被識別的枚舉值，將會被保留在 messaage 中。因為消息反序列化時如何表示是依賴于語言的。在支持指定符號范圍之外的值的開放枚舉類型的語言中，例如 C++ 和 Go ，未知的枚舉值只是存儲為其基礎整數表示。在諸如 Java 之類的封閉枚舉類型的語言中，枚舉值會被用來標識未識別的值，并且特殊的訪問器可以訪問到底層整數。

在其他情況下，如果消息被序列化，則無法識別的值仍將與消息一起序列化。

枚舉中的保留值

如果您通過完全刪除枚舉條目或將其注釋掉來更新枚舉類型，未來的用戶可以在對該類型進行自己的更新時重新使用數值。

如果稍后加載到了的舊版本 .proto 文件，則會導致服務器出現嚴重問題，例如數據混亂，隱私錯誤等等。確保這種情況不會發生的一種方法是指定已刪除條目的數字值（或名稱，這也可能會導致 JSON 序列化問題）為 reserved 。

如果將來的任何用戶試圖使用這些字段標識符， Protocol Buffers 編譯器將會報錯。您可以使用 max 關鍵字指定您的保留數值范圍上升到最大可能值。

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

注意，不能在同一個 reserved 語句中混合字段名稱和字段編號。 如有需要需要像上面這個例子這樣寫。

允許嵌套

Protocol Buffers 定義 message 允許嵌套組合成更加復雜的消息。

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

上面的例子中，SearchResponse 中嵌套使用了 Result 。

更多的例子：

message SearchResponse {message Result {string url = 1;string title = 2;repeated string snippets = 3;}repeated Result results = 1; }message SomeOtherMessage {SearchResponse.Result result = 1; } message Outer { // Level 0message MiddleAA { // Level 1message Inner { // Level 2int64 ival = 1;bool booly = 2;}}message MiddleBB { // Level 1message Inner { // Level 2int32 ival = 1;bool booly = 2;}} }

枚舉不兼容性

可以導入 proto2 消息類型并在 proto3 消息中使用它們，反之亦然。然而， proto2 枚舉不能直接用在 proto3 語法中（但是如果導入的 proto2 消息使用它們，這是可以的）。

更新Message

如果后面發現之前定義 message 需要增加字段了，這個時候就體現出 Protocol Buffer 的優勢了，不需要改動之前的代碼。不過需要滿足以下 10 條規則：

• 不要改動原有字段的數據結構。

• 如果您添加新字段，則任何由代碼使用“舊”消息格式序列化的消息仍然可以通過新生成的代碼進行分析。您應該記住這些元素的默認值，以便新代碼可以正確地與舊代碼生成的消息進行交互。同樣，由新代碼創建的消息可以由舊代碼解析：舊的二進制文件在解析時會簡單地忽略新字段。（具體原因見 未知字段 這一章節）

• 只要字段號在更新的消息類型中不再使用，字段可以被刪除。您可能需要重命名該字段，可能會添加前綴 “OBSOLETE_” ，或者標記成保留字段號 reserved ，以便將來的 .proto 用戶不會意外重復使用該號碼。

• int32 ， uint32 ，int64 ，uint64 和 bool 全都兼容。這意味著您可以將字段從這些類型之一更改為另一個字段而不破壞向前或向后兼容性。如果一個數字從不適合相應類型的線路中解析出來，則會得到與在 C++ 中將該數字轉換為該類型相同的效果（例如，如果將 64 位數字讀為 int32 ，它將被截斷為 32 位）。

• sint32 和 sint64 相互兼容，但與其他整數類型不兼容。

• 只要字節是有效的 UTF-8 ，string 和 bytes 是兼容的。

• 嵌套式 message 與 bytes 兼容，如果 bytes 包含 message 的 encoded version。

• fixed32 與 sfixed32 兼容，而 fixed64 與 sfixed64 兼容。

• enum 就數組而言，是可以與 int32 ， uint32 ， int64 和 uint64 兼容（請注意，如果它們不適合，值將被截斷）。但是請注意，當消息反序列化時，客戶端代碼可能會以不同的方式對待它們：例如，未識別的 proto3 枚舉類型將保留在消息中，但消息反序列化時如何表示是與語言相關的。（這點和語言相關，上面提到過了） Int 域始終只保留它們的值。

• 將單個值更改為新的成員是安全和二進制兼容的。如果您確定一次沒有代碼設置多個字段，則將多個字段移至新的字段可能是安全的。將任何字段移到現有字段中都是不安全的。（注意字段和值的區別，字段是 field ，值是 value ）

未知字段

未知數字段是 protocol buffers 序列化的數據，表示解析器無法識別的字段。例如，當一個舊的二進制文件解析由新的二進制文件發送的新數據的數據時，這些新的字段將成為舊的二進制文件中的未知字段。

Proto3 實現可以成功解析未知字段的消息，但是，實現可能會或可能不會支持保留這些未知字段。你不應該依賴保存或刪除未知域。對于大多數 Google protocol buffers 實現，未知字段在 proto3 中無法通過相應的 proto 運行時訪問，并且在反序列化時被丟棄和遺忘。這是與 proto2 的不同行為，其中未知字段總是與消息一起保存并序列化。

Map類型

repeated 類型可以用來表示數組， Map 類型則可以用來表示字典。

map<key_type, value_type> map_field = N;map<string, Project> projects = 3;

key_type 可以是任何 int 或者 string 類型(任何的標量類型，具體可以見上面標量類型對應表格，但是要除去 float、double 和 bytes )

枚舉值也不能作為 key。

key_type 可以是除去 map 以外的任何類型。

需要特別注意的是 ：

• map 是不能用 repeated 修飾的。

• 線性數組和 map 迭代順序的是不確定的，所以你不能依靠你的 map 是在一個特定的順序。

• 為 .proto 生成文本格式時， map 按 key 排序。數字的 key 按數字排序。

• 從數組中解析或合并時，如果有重復的 key ，則使用所看到的最后一個 key（覆蓋原則）。從文本格式解析映射時，如果有重復的 key ，解析可能會失敗。

Protocol Buffer 雖然不支持 map 類型的數組，但是可以轉換一下，用以下思路實現 maps 數組：

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

上述寫法和 map 數組是完全等價的，所以用 repeated 巧妙的實現了 maps 數組的需求。

JsonMapping

Proto3 支持 JSON 中的規范編碼，使系統之間共享數據變得更加容易。編碼在下表中按類型逐個描述。

如果 JSON 編碼數據中缺少值或其值為空，則在解析為 protocol buffer 時，它將被解釋為適當的默認值。如果一個字段在協議緩沖區中具有默認值，默認情況下它將在 JSON 編碼數據中省略以節省空間。具體 Mapping 的實現可以提供選項決定是否在 JSON 編碼的輸出中發送具有默認值的字段。

proto3 的 JSON 實現中提供了以下 4 中 options :

• 使用默認值發送字段：在默認情況下，默認值的字段在 proto3 JSON 輸出中被忽略。一個實現可以提供一個選項來覆蓋這個行為，并使用它們的默認值輸出字段。

• 忽略未知字段：默認情況下， Proto3 JSON 解析器應拒絕未知字段，但可能提供一個選項來忽略解析中的未知字段。

• 使用 proto 字段名稱而不是 lowerCamelCase 名稱：默認情況下， proto3 JSON 的 printer 將字段名稱轉換為 lowerCamelCase 并將其用作 JSON 名稱。實現可能會提供一個選項，將原始字段名稱用作 JSON 名稱。 Proto3 JSON 解析器需要接受轉換后的 lowerCamelCase 名稱和原始字段名稱。

• 發送枚舉形式的枚舉值而不是字符串：在 JSON 輸出中默認使用枚舉值的名稱。可以提供一個選項來使用枚舉值的數值。

回到頂部

proto3定義Services

如果要使用 RPC （遠程過程調用）系統的消息類型，可以在 .proto 文件中定義 RPC 服務接口， protocol buffer 編譯器將使用所選語言生成服務接口代碼和 stubs 。所以，例如，如果你定義一個 RPC 服務，入參是 SearchRequest 返回值是 SearchResponse ，你可以在你的 .proto 文件中定義它，如下所示：

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

與 protocol buffer 一起使用的最直接的 RPC 系統是 gRPC ：在谷歌開發的語言和平臺中立的開源 RPC 系統。 gRPC 在 protocol buffer 中工作得非常好，并且允許你通過使用特殊的 protocol buffer 編譯插件，直接從 .proto 文件中生成 RPC 相關的代碼。

如果你不想使用 gRPC ，也可以在你自己的 RPC 實現中使用 protocol buffers 。您可以在 Proto2 語言指南中找到更多關于這些相關的信息。

還有一些正在進行的第三方項目為 Protocol Buffers 開發 RPC 實現。

回到頂部

ProtocolBuffer命名規范

message 采用駝峰命名法。message 首字母大寫開頭。字段名采用下劃線分隔法命名。

message SongServerRequest {required string song_name = 1; }

枚舉類型采用駝峰命名法。枚舉類型首字母大寫開頭。每個枚舉值全部大寫，并且采用下劃線分隔法命名。

enum Foo {FIRST_VALUE = 0;SECOND_VALUE = 1; }

每個枚舉值用分號結束，不是逗號。

服務名和方法名都采用駝峰命名法。并且首字母都大寫開頭。

service FooService {rpc GetSomething(FooRequest) returns (FooResponse); }

回到頂部

ProtocolBuffer編碼原理

在討論 Protocol Buffer 編碼原理之前，必須先談談 Varints 編碼。

Base 128 Varints 編碼
Varint 是一種緊湊的表示數字的方法。它用一個或多個字節來表示一個數字，值越小的數字使用越少的字節數。這能減少用來表示數字的字節數。

Varint 中的每個字節（最后一個字節除外）都設置了最高有效位(msb)，這一位表示還會有更多字節出現。每個字節的低 7 位用于以 7 位組的形式存儲數字的二進制補碼表示，最低有效組首位。

如果用不到 1 個字節，那么最高有效位設為 0 ，如下面這個例子，1 用一個字節就可以表示，所以 msb 為 0.

0000 0001

如果需要多個字節表示，msb 就應該設置為 1 。例如 300，如果用 Varint 表示的話：

1010 1100 0000 0010

如果按照正常的二進制計算的話，這個表示的是 88068(65536 + 16384 + 4096 + 2048 + 4)。

那 Varint 是怎么編碼的呢？

下面代碼是 Varint int 32 的編碼計算方法。

// *號后加了空格，強迫癥 0.0 char * EncodeVarint32(char * dst, uint32_t v) {// Operate on characters as unsignedsunsigned char* ptr = reinterpret_cast<unsigned char*>(dst);static const int B = 128;if (v < (1<<7)) {* (ptr++) = v;} else if (v < (1<<14)) {* (ptr++) = v | B;* (ptr++) = v>>7;} else if (v < (1<<21)) {* (ptr++) = v | B;* (ptr++) = (v>>7) | B;* (ptr++) = v>>14;} else if (v < (1<<28)) {* (ptr++) = v | B;* (ptr++) = (v>>7) | B;* (ptr++) = (v>>14) | B;* (ptr++) = v>>21;} else {* (ptr++) = v | B;* (ptr++) = (v>>7) | B;* (ptr++) = (v>>14) | B;* (ptr++) = (v>>21) | B;* (ptr++) = v>>28;}return reinterpret_cast<char*>(ptr); } 300 = 100101100

由于 300 超過了 7 位（ Varint 一個字節只有 7 位能用來表示數字，最高位 msb 用來表示后面是否有更多字節），所以 300 需要用 2 個字節來表示。

Varint 的編碼，以 300 舉例：

if (v < (1<<14)) {* (ptr++) = v | B;* (ptr++) = v>>7; }1. 100101100 | 10000000 = 1 1010 1100 2. 110101100 取出末尾 7 位 = 010 1100 3. 100101100 >> 7 = 10 = 0000 0010 4. 1010 1100 0000 0010 (最終 Varint 結果)

Varint 的解碼算法應該是這樣的：（實際就是編碼的逆過程）

如果是多個字節，先去掉每個字節的 msb（通過邏輯或運算），每個字節只留下 7 位。
逆序整個結果，最多是 5 個字節，排序是 1-2-3-4-5，逆序之后就是 5-4-3-2-1，字節內部的二進制位的順序不變，變的是字節的相對位置。
解碼過程調用 GetVarint32Ptr 函數，如果是大于一個字節的情況，會調用 GetVarint32PtrFallback 來處理。

inline const char* GetVarint32Ptr(const char* p,const char* limit,uint32_t* value) {if (p < limit) {uint32_t result = * (reinterpret_cast<const unsigned char*>(p));if ((result & 128) == 0) {* value = result;return p + 1;}}return GetVarint32PtrFallback(p, limit, value); }const char* GetVarint32PtrFallback(const char* p,const char* limit,uint32_t* value) {uint32_t result = 0;for (uint32_t shift = 0; shift <= 28 && p < limit; shift += 7) {uint32_t byte = * (reinterpret_cast<const unsigned char*>(p));p++;if (byte & 128) {// More bytes are presentresult |= ((byte & 127) << shift);} else {result |= (byte << shift);* value = result;return reinterpret_cast<const char*>(p);}}return NULL; }

至此，Varint 處理過程讀者應該都熟悉了。上面列舉出了 Varint 32 的算法，64 位的同理，只不過不再用 10 個分支來寫代碼了，太丑了。（32位 是 5 個 字節，64位 是 10 個字節）

64 位 Varint 編碼實現：

const char* GetVarint64Ptr(const char* p, const char* limit, uint64_t* value) {uint64_t result = 0;for (uint32_t shift = 0; shift <= 63 && p < limit; shift += 7) {uint64_t byte = * (reinterpret_cast<const unsigned char*>(p));p++;if (byte & 128) {// More bytes are presentresult |= ((byte & 127) << shift);} else {result |= (byte << shift);* value = result;return reinterpret_cast<const char*>(p);}}return NULL; }

讀到這里可能有讀者會問了， Varint 不是為了緊湊 int 的么？那 300 本來可以用 2 個字節表示，現在還是 2 個字節了，哪里緊湊了，花費的空間沒有變啊？！

Varint 確實是一種緊湊的表示數字的方法。它用一個或多個字節來表示一個數字，值越小的數字使用越少的字節數。這能減少用來表示數字的字節數。比如對于 int32 類型的數字，一般需要 4 個 byte 來表示。但是采用 Varint ，對于很小的 int32 類型的數字，則可以用 1 個 byte 來表示。當然凡事都有好的也有不好的一面，采用 Varint 表示法，大的數字則需要 5 個 byte 來表示。從統計的角度來說，一般不會所有的消息中的數字都是大數，因此大多數情況下，采用 Varint 后，可以用更少的字節數來表示數字信息。

300 如果用 int32 表示，需要 4 個字節，現在用 Varint 表示，只需要 2 個字節了。縮小了一半！

MessageStructure編碼

protocol buffer 中 message 是一系列鍵值對。message 的二進制版本只是使用字段號(field's number 和 wire_type )作為 key 。每個字段的名稱和聲明類型只能在解碼端通過引用消息類型的定義（即 .proto 文件）來確定。這一點也是人們常常說的 protocol buffer 比 JSON ，XML 安全一點的原因，如果沒有數據結構描述 .proto 文件，拿到數據以后是無法解釋成正常的數據的。

由于采用了 tag-value 的形式，所以 option 的 field 如果有，就存在在這個 message buffer 中，如果沒有，就不會在這里，這一點也算是壓縮了 message 的大小了。

當消息編碼時，鍵和值被連接成一個字節流。當消息被解碼時，解析器需要能夠跳過它無法識別的字段。這樣，可以將新字段添加到消息中，而不會破壞不知道它們的舊程序。這就是所謂的 “向后”兼容性。

為此，線性的格式消息中每對的 key 實際上是兩個值，其中一個是來自 .proto 文件的字段編號，加上提供正好足夠的信息來查找下一個值的長度。在大多數語言實現中，這個 key 被稱為 tag 。

注意上圖中，3 和 4 已經被廢棄了，所以 wire_type 取值目前只有 0、1、2、5。

key 的計算方法是 (field_number << 3) | wire_type ，換句話說，key 的最后 3 位表示的就是 wire_type 。

舉例，一般 message 的字段號都是 1 開始的，所以對應的 tag 可能是這樣的：

000 1000

末尾 3 位表示的是 value 的類型，這里是 000，即 0 ，代表的是 varint 值。右移 3 位，即 0001，這代表的就是字段號 (field number) 。tag 的例子就舉這么多，接下來舉一個 value 的例子，還是用 varint 來舉例：

96 01 = 1001 0110 0000 0001→ 000 0001 ++ 001 0110 (drop the msb and reverse the groups of 7 bits)→ 10010110→ 128 + 16 + 4 + 2 = 150

可以 96 01 代表的數據就是 150 。

message Test1 {required int32 a = 1; }

如果存在上面這樣的一個 message 的結構，如果存入 150，在 Protocol Buffer 中顯示的二進制應該為 08 96 01 。

額外說一句，type 需要注意的是 type = 2 的情況，tag 里面除了包含 field number 和 wire_type ，還需要再包含一個 length ，決定 value 從那一段取出來。（具體原因見 Protocol Buffer 字符串 這一章節）

SignedIntegers編碼

從上面的表格里面可以看到 wire_type = 0 中包含了無符號的 varints ，但是如果是一個無符號數呢？

一個負數一般會被表示為一個很大的整數，因為計算機定義負數的符號位為數字的最高位。如果采用 Varint 表示一個負數，那么一定需要 10 個 byte 長度。

為何 32 位和 64 位的負數都需要 10 個 byte 長度呢？

inline void CodedOutputStream::WriteVarint32SignExtended(int32 value) {WriteVarint64(static_cast<uint64>(value)); }

因為源碼里面是這么規定的。32 位的有符號數都會轉換成 64 位無符號來處理。至于源碼為什么要這么規定呢，猜想可能是怕 32 位的負數轉換會有溢出的可能。(只是猜想)

為此 Google Protocol Buffer 定義了 sint32 這種類型，采用 zigzag 編碼。將所有整數映射成無符號整數，然后再采用 varint 編碼方式編碼，這樣，絕對值小的整數，編碼后也會有一個較小的 varint 編碼值。

Zigzag 映射函數為：

Zigzag(n) = (n << 1) ^ (n >> 31), n 為 sint32 時Zigzag(n) = (n << 1) ^ (n >> 63), n 為 sint64 時

按照這種方法，-1 將會被編碼成 1，1 將會被編碼成 2，-2 會被編碼成 3，如下表所示：

需要注意的是，第二個轉換 (n >> 31) 部分，是一個算術轉換。所以，換句話說，移位的結果要么是一個全為0（如果n是正數），要么是全部1（如果n是負數）。

當 sint32 或 sint64 被解析時，它的值被解碼回原始的帶符號的版本。

Non-varintNumbers

Non-varint 數字比較簡單，double 、fixed64 的 wire_type 為 1，在解析時告訴解析器，該類型的數據需要一個 64 位大小的數據塊即可。同理，float 和 fixed32 的 wire_type 為5，給其 32 位數據塊即可。兩種情況下，都是高位在后，低位在前。

說 Protocol Buffer 壓縮數據沒有到極限，原因就在這里，因為并沒有壓縮 float、double 這些浮點類型。

字符串

wire_type 類型為 2 的數據，是一種指定長度的編碼方式：key + length + content ， key 的編碼方式是統一的， length 采用 varints 編碼方式， content 就是由 length 指定長度的 Bytes 。

舉例，假設定義如下的 message 格式：

message Test2 {optional string b = 2; }

設置該值為 testing ，二進制格式查看：

12 07 74 65 73 74 69 6e 67

74 65 73 74 69 6e 67 是 testing 的 UTF8 代碼。

此處， key 是16進制表示的，所以展開是：

12 -> 0001 0010 ，后三位 010 為 wire type = 2 ，0001 0010 右移三位為 0000 0010 ，即 tag = 2 。

length 此處為 7，后邊跟著 7 個 bytes ，即我們的字符串 testing 。

所以 wire_type 類型為 2 的數據，編碼的時候會默認轉換為 T-L-V (Tag - Length - Value) 的形式。

嵌套式Message

假設，定義如下嵌套消息：

message Test3 {optional Test1 c = 3; }

設置字段為整數150，編碼后的字節為：

1a 03 08 96 01

08 96 01 這三個代表的是 150，上面講解過，這里就不再贅述了。

1a -> 0001 1010 ，后三位 010 為 wire type = 2，0001 1010 右移三位為 0000 0011 ，即 tag = 3 。

length 為 3，代表后面有 3 個字節，即 08 96 01 。

需要轉變為 T - L - V 形式的還有 string , bytes , embedded messages , packed repeated fields （即 wire_type 為 2 的形式都會轉變成 T - L - V 形式）

Optional和Repeated的編碼

在 proto2 中定義成 repeated 的字段，（沒有加上 [packed=true] option ），編碼后的 message 有一個或者多個包含相同 tag 數字的 key-value 對。這些重復的 value 不需要連續的出現；他們可能與其他的字段間隔的出現。盡管他們是無序的，但是在解析時，他們是需要有序的。在 proto3 中 repeated 字段默認采用 packed 編碼（具體原因見 Packed Repeated Fields 這一章節）

對于 proto3 中的任何非重復字段或 proto2 中的可選字段，編碼的 message 可能有也可能沒有包含該字段號的鍵值對。

通常，編碼后的 message ，其 required 字段和 optional 字段最多只有一個實例。但是解析器卻需要處理多對一的情況。對于數字類型和 string 類型，如果同一值出現多次，解析器接受最后一個它收到的值。對于內嵌字段，解析器合并 (merge) 它接收到的同一字段的多個實例。就如 MergeFrom 方法一樣，所有單數的字段，后來的會替換先前的，所有單數的內嵌 message 都會被合并 (merge) ，所有的 repeated 字段，都會串聯起來。這樣的規則的結果是，解析兩個串聯的編碼后的 message ，與分別解析兩個 message 然后 merge ，結果是一樣的。例如：

MyMessage message; message.ParseFromString(str1 + str2);

等價于

MyMessage message, message2; message.ParseFromString(str1); message2.ParseFromString(str2); message.MergeFrom(message2);

這種方法有時是非常有用的。比如，即使不知道 message 的類型，也能夠將其合并。

PackedRepeatedFields

在 2.1.0 版本以后，protocol buffers 引入了該種類型，其與 repeated 字段一樣，只是在末尾聲明了 [packed=true] 。類似 repeated 字段卻又不同。在 proto3 中 Repeated 字段默認就是以這種方式處理。對于 packed repeated 字段，如果 message 中沒有賦值，則不會出現在編碼后的數據中。否則的話，該字段所有的元素會被打包到單一一個 key-value 對中，且它的 wire_type=2 ，長度確定。每個元素正常編碼，只不過其前沒有標簽 tag 。例如有如下 message 類型：

message Test4 {repeated int32 d = 4 [packed=true]; }

構造一個 Test4 字段，并且設置 repeated 字段 d 3個值：3，270 和 86942，編碼后：

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

形成了 Tag - Length - Value - Value - Value …… 對。
只有原始數字類型（使用 varint ，32位或64位）的重復字段才可以聲明為 "packed" 。

有一點需要注意，對于 packed 的 repeated 字段，盡管通常沒有理由將其編碼為多個 key-value 對，編碼器必須有接收多個 key-pair 對的準備。這種情況下，payload 必須是串聯的，每個 pair 必須包含完整的元素。

Protocol Buffer 解析器必須能夠解析被重新編譯為 packed 的字段，就像它們未被 packed 一樣，反之亦然。這允許以正向和反向兼容的方式將 [packed = true] 添加到現有字段。

FieldOrder

編碼/解碼與字段順序無關，這一點由 key-value 機制保證。

如果消息具有未知字段，則當前的 Java 和 C++ 實現在按順序排序的已知字段之后以任意順序寫入它們。當前的 Python 實現不會跟蹤未知字段。

回到頂部

protocolBuffers的優缺點

protocol buffers 在序列化方面，與 XML 相比，有諸多優點：

• 更加簡單

• 數據體積小 3- 10 倍

• 更快的反序列化速度，提高 20 - 100 倍

• 可以自動化生成更易于編碼方式使用的數據訪問類

舉個例子：

如果要編碼一個用戶的名字和 email 信息，用 XML 的方式如下：

<person><name>John Doe</name><email>jdoe@example.com</email></person>

相同需求，如果換成 protocol buffers 來實現，定義文件如下：

# Textual representation of a protocol buffer. # This is *not* the binary format used on the wire. person {name: "John Doe"email: "jdoe@example.com" }

protocol buffers 通過編碼以后，以二進制的方式進行數據傳輸，最多只需要 28 bytes 空間和 100-200 ns 的反序列化時間。但是 XML 則至少需要 69 bytes 空間（經過壓縮以后，去掉所有空格）和 5000-10000 的反序列化時間。

上面說的是性能方面的優勢。接下來說說編碼方面的優勢。

protocol buffers 自帶代碼生成工具，可以生成友好的數據訪問存儲接口。從而開發人員使用它來編碼更加方便。例如上面的例子，如果用 C++ 的方式去讀取用戶的名字和 email ，直接調用對應的 get 方法即可（所有屬性的 get 和 set 方法的代碼都自動生成好了，只需要調用即可）

cout << "Name: " << person.name() << endl;cout << "E-mail: " << person.email() << endl;

而 XML 讀取數據會麻煩一些：

cout << "Name: "<< person.getElementsByTagName("name")->item(0)->innerText()<< endl;cout << "E-mail: "<< person.getElementsByTagName("email")->item(0)->innerText()<< endl;

Protobuf 語義更清晰，無需類似 XML 解析器的東西（因為 Protobuf 編譯器會將 .proto 文件編譯生成對應的數據訪問類以對 Protobuf 數據進行序列化、反序列化操作）。

使用 Protobuf 無需學習復雜的文檔對象模型，Protobuf 的編程模式比較友好，簡單易學，同時它擁有良好的文檔和示例，對于喜歡簡單事物的人們而言， Protobuf 比其他的技術更加有吸引力。

protocol buffers 最后一個非常棒的特性是，即“向后”兼容性好，人們不必破壞已部署的、依靠“老”數據格式的程序就可以對數據結構進行升級。這樣您的程序就可以不必擔心因為消息結構的改變而造成的大規模的代碼重構或者遷移的問題。因為添加新的消息中的 field 并不會引起已經發布的程序的任何改變(因為存儲方式本來就是無序的，k-v 形式)。

當然 protocol buffers 也并不是完美的，在使用上存在一些局限性。

由于文本并不適合用來描述數據結構，所以 Protobuf 也不適合用來對基于文本的標記文檔（如 HTML ）建模。另外，由于 XML 具有某種程度上的自解釋性，它可以被人直接讀取編輯，在這一點上 Protobuf 不行，它以二進制的方式存儲，除非你有 .proto 定義，否則你沒法直接讀出 Protobuf 的任何內容。

回到頂部

最后

讀完本篇 Protocol Buffer 編碼原理以后，讀者應該能明白以下幾點：

Protocol Buffer 利用 varint 原理壓縮數據以后，二進制數據非常緊湊， option 也算是壓縮體積的一個舉措。所以 pb 體積更小，如果選用它作為網絡數據傳輸，勢必相同數據，消耗的網絡流量更少。但是并沒有壓縮到極限，float、double 浮點型都沒有壓縮。

Protocol Buffer 比 JSON 和 XML 少了 {、}、 : 這些符號，體積也減少一些。再加上 varint 壓縮，gzip 壓縮以后體積更小！

Protocol Buffer 是 Tag - Value (Tag - Length - Value) 的編碼方式的實現，減少了分隔符的使用，數據存儲更加緊湊。

Protocol Buffer 另外一個核心價值在于提供了一套工具，一個編譯工具，自動化生成 get/set 代碼。簡化了多語言交互的復雜度，使得編碼解碼工作有了生產力。

Protocol Buffer 不是自我描述的，離開了數據描述 .proto 文件，就無法理解二進制數據流。這點即是優點，使數據具有一定的“加密性”，也是缺點，數據可讀性極差。所以 Protocol Buffer 非常適合內部服務之間 RPC 調用和傳遞數據。

Protocol Buffer 具有向后兼容的特性，更新數據結構以后，老版本依舊可以兼容，這也是 Protocol Buffer 誕生之初被寄予解決的問題。因為編譯器對不識別的新增字段會跳過不處理。

Protocol Buffer 編碼原理篇到此結束，下篇來講講 Protocol Buffer 反序列化解包性能快的原因。

回到頂部

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的高效的数据压缩编码方式 Protobuf的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。