[TOC] ## 概述 本章中將介紹幾種編碼數據的格式，包括 JSON，XML，Protocol Buffers，Thrift和Avro 在Web服務中，具象狀態傳輸（REST）和遠程過程調用（RPC），以及消息傳遞系統（如Actor和消息隊列） ## 編碼數據的格式 程序通常（至少）使用兩種形式的數據： 1. 在內存中，數據保存在對象，結構體，列表，數組，哈希表，樹等中。 這些數據結構針對CPU的高效訪問和操作進行了優化（通常使用指針）。 2. 如果要將數據寫入文件，或通過網絡發送，則必須將其**編碼（encode）**為某種自包含的字節序列（例如，JSON文檔）。 由于每個進程都有自己獨立的地址空間，一個進程中的指針對任何其他進程都沒有意義，所以這個字節序列表示會與通常在內存中使用的數據結構完全不同 從內存中表示到字節序列的轉換稱為**編碼（Encoding）**（也稱為**序列化（serialization）**或**編組（marshalling）**），反過來稱為**解碼（Decoding）**[ii](https://vonng.gitbooks.io/ddia-cn/content/ch4.html#fn_ii)（**解析（Parsing）**，**反序列化（deserialization）**，**反編組( unmarshalling）**） ## 語言特定的格式 許多編程語言都內建了將內存對象編碼為字節序列的支持。例如，Java有java.io.Serializable ，Ruby有Marshal，Python有pickle 等等 * 內置編程語言都與其語言深度綁定,不能被其他語言反序列化。 * 為了恢復相同對象類型的數據，解碼過程需要**實例化任意類**的能力，這通常是安全問題的一個來源：如果攻擊者可以讓應用程序解碼任意的字節序列，他們就能實例化任意的類，這會允許他們做可怕的事情，如遠程執行任意代碼。 * 在這些庫中，數據版本控制通常是事后才考慮的。因為它們旨在快速簡便地對數據進行編碼，所以往往忽略了前向后向兼容性帶來的麻煩問題。 * 效率（編碼或解碼所花費的CPU時間，以及編碼結構的大小）往往也是事后才考慮的。 例如，Java的內置序列化由于其糟糕的性能和臃腫的編碼而臭名昭著。 總結:因此，除非臨時使用，采用語言內置編碼通常是一個壞主意 ## JSON，XML和二進制變體 1. 數字的編碼多有歧義之處。XML和CSV不能區分數字和字符串（除非引用外部模式）。 JSON雖然區分字符串和數字，但不區分整數和浮點數，而且不能指定精度 2. 當處理大量數據時，這個問題更嚴重了。例如，大于$2^{53}$的整數不能在IEEE 754雙精度浮點數中精確表示,Twitter API返回的JSON包含了兩種推特ID，一個JSON數字，另一個是十進制字符串，以此避免JavaScript程序無法正確解析數字的問題 3. JSON 有與 XML 不支持二進制,需要使用base64,但它有點hacky，并增加了33％的數據大小 4. CSV沒有任何模式，因此應用程序需要定義每行和每列的含義 ## 二進制編碼 對于僅在組織內部使用的數據，使用最小公分母編碼格式的壓力較小。例如，可以選擇更緊湊或更快的解析格式。雖然對小數據集來說，收益可以忽略不計，但一旦達到TB級別，數據格式的選擇就會產生巨大的影響 這一事實導致大量二進制編碼版本JSON & XML的出現（MessagePack，BSON，BJSON，UBJSON，BISON和Smile等）（例如WBXML和Fast Infoset）。這些格式已經被各種各樣的領域所采用，但是沒有一個像JSON和XML的文本版本那樣被廣泛采用