為什麼google protobuf不支持map的序列化和反序列化?

是因為把線性結構恢復為樹狀結構的複雜度和直接使用線性結構相同么?


ProtoBuf 3.0 pre-release已經支持了:

Release Protocol Buffers v3.0.0-alpha-2 · google/protobuf · GitHub


1. protobuf的競爭對手是xml,json等,要支持map的序列化,哪就和json之類沒有什麼區別

2. protobuf dsl定義各種schema,其實用一個map也能表達,如果再實現map,哪就是自我否定


protobuf 用二進位序列化的優勢,與文本序列化競爭,本質上是一種作弊,但因為它是牛逼公司的牛神發明的,所以它就牛逼大了。因為它牛逼大了,所以只要是它的設計決策,就是正當的


現在它是支持的。

proto2的文檔就已經提到了Maps(Language Guide),但我用protoc2.6編譯的時候,map關鍵字無法通過編譯,protoc3.0編譯正常,proto舉例:

message Person {
required int32 id = 1;
required string name = 2;
optional string email = 3;
map& values= 4;
}

另外,

官方文檔(https://developers.google.com/protocol-buffers/docs/proto#Maps)說了:

The map syntax is equivalent to the following on the wire, so protocol buffers implementations that do not support maps can still handle your data:

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

repeated MapFieldEntry map_field = N;


3.0里已經支持了,就是還沒release


1.支持map就要把key都加入到最終序列化的結果中去,並且效率也會更差(時間空間都損失了),這會削減二進位的優勢(跟文本序列化相比),

2.map傳輸之後,對端一樣需要scheme才能解析數據,跟現有方法相比沒啥優勢,proto文件里的欄位相當於是key

3.現有的序列化方法相當於key為整型的嵌套map,利用反射等特性也是能當map用的


3.0已經支持了,不過3.0語法變了一些...


map,在序列化的過程中傳輸到遠端也是要轉換為list的。所以沒有必要。使用repeated嵌套消息即可解決。


我的理解是,PB可以使用一個鍵值對的repetead欄位模擬Map,也就沒有必要在語言層面上做。


推薦閱讀:

美國谷歌臉書面試最看重什麼?
是否可以認為 EverMemo 抄襲了 Keep ?
目前國內可以訪問的搜索引擎中,英文搜索質量較高的有哪些?
谷歌的產品為什麼看不到更多的整合?
谷歌閱讀器(Google reader)將於七月一日關閉,有哪些原因?同時有哪些優秀的替代產品?

TAG:protobuf | 谷歌Google |