編碼規(guī)范就是我們通常所說的編解碼，序列化。不光是用在通信工作上，在存儲工作上我們也經(jīng)常用到。如我們經(jīng)常想把內(nèi)存中對象存放到磁盤上，就需要對對象進行數(shù)據(jù)序列化工作。

本文采用先循序漸進，先舉一個例子，然后不斷提出問題-解決完善，這樣一個迭代進化的方式，介紹一個協(xié)議逐步進化和完善，最后總結(jié)?？赐曛?，大家以后在工作就很容易制定和選擇自己的編碼協(xié)議。

一、緊湊模式

本文例子是A和B通信，獲取或設置基本資料，一般開發(fā)人員第一步就是定義一個協(xié)議結(jié)構(gòu):

struct userbase

{

unsigned short cmd;//1-get, 2-set, 定義一個short，為了擴展更多命令(理想那么豐滿)

unsigned char gender; //1 – man , 2-woman, 3 - ??

char name[8]; //當然這里可以定義為 string name；或len + value 組合，為了敘述方便，就使用簡單定長數(shù)據(jù)

}

在這種方式下，A基本不用編碼，直接從內(nèi)存copy出來，再把cmd做一下網(wǎng)絡字節(jié)序變換，發(fā)送給B。B也能解析，一切都很和諧愉快。

這時候編碼結(jié)果可以用圖表示為(1格一個字節(jié))

這種編碼方式，我稱之為緊湊模式，意思是除了數(shù)據(jù)本身外，沒有一點額外冗余信息，可以看成是Raw Data。在dos年代，這種使用方式非常普遍，那時候可是內(nèi)存和網(wǎng)絡都是按K計算，cpu還沒有到1G。如果添加額外信息，不光耗費捉襟見肘的cpu，連內(nèi)存和帶寬都傷不起。

二、可擴展性

有一天，A在基本資料里面加一個生日字段，然后告訴B

struct userbase

{

unsigned short cmd;

unsigned char gender;

unsigned int birthday;

char name[8];

}

這是B就犯愁了，收到A的數(shù)據(jù)包，不知道第3個字段到底是舊協(xié)議中的name字段，還是新協(xié)議中birthday。這是后A，和B終于從教訓中認識到一個協(xié)議重要特性——兼容性和可擴展性。

于是乎，A和B決定廢掉舊的協(xié)議，從新開始，制定一個以后每個版本兼容的協(xié)議。方法很簡單，就是加一個version字段。

struct userbase

{

unsigned short version;

unsigned short cmd;

unsigned char gender;

unsigned int birthday;

char name[8];

}

這樣，A和B就松一口氣，以后就可以很方便的擴展。增加字段也很方便。這種方法即使在現(xiàn)在，應該還有不少人使用。

二、更好的可擴展性

過了一段較長時間，A和B發(fā)現(xiàn)又有新的問題，就是沒增加一個字段就改變一下版本號，這還不是重點，重點是這樣代碼維護起來相當麻煩，每個版本一個case分支，到了最好，代碼里面case 幾十個分支，看起來丑陋而且維護起來成本高。

A 和 B仔細思考了一下，覺得光靠一個version維護整個協(xié)議，不夠細，于是覺得為每個字段增加一個額外信息——tag,雖然增加內(nèi)存和帶寬，但是現(xiàn)在已經(jīng)不像當年那樣，可以容許這些冗余，換取易用性。

struct userbase

{

1 unsigned short version;

2 unsigned short cmd;

3 unsigned char gender;

4 unsigned int birthday;

5 char name[8];

}

制定完這些協(xié)議后，A和B很得意，覺得這個協(xié)議不錯，可以自由的增加和減少字段。隨便擴展。

現(xiàn)實總是很殘酷的，不久就有新的需求，name使用8個字節(jié)不夠，最大長度可能會達到100個字節(jié)，A和B就愁懷了，總不能即使叫“steven”的人，每次都按照100個字節(jié)打包，雖然不差錢，也不能這樣浪費。

于是A和B尋找各方資料，找到了ANS.1編碼規(guī)范，好東西啊.. ASN.1是一種ISO/ITU-T 標準。其中一種編碼BER（Basic Encoding Rules）簡單好用，它使用三元組編碼，簡稱TLV編碼。

每個字段編碼后內(nèi)存組織如下

字段可以是結(jié)構(gòu)，即可以嵌套

A和B使用TLV打包協(xié)議后，數(shù)據(jù)內(nèi)存組織大概如下:

TLV具備了很好可擴展性，很簡單易學。同時也具備了缺點，因為其增加了2個額外的冗余信息，tag 和len，特別是如果協(xié)議大部分是基本數(shù)據(jù)類型int ,short, byte. 會浪費幾倍存儲空間。另外Value具體是什么含義，需要通信雙方事先得到描述文檔，即TLV不具備結(jié)構(gòu)化和自解釋特性。

三、自解釋性

當A和B采用TLV協(xié)議后，似乎問題都解決了。但是還是覺得不是很完美，決定增加自解釋特性，這樣抓包就能知道各個字段類型，不用看協(xié)議描述文檔。 這種改進的類型就是 TT[L]V（tag，type，length，value），其中L在type是定長的基本數(shù)據(jù)類型如int,short, long, byte時候，因為其長度是已知的，所以L不需要。

于是定義了一些type值如下

按照ttlv序列化后，內(nèi)存組織如下

改完后，A和B發(fā)現(xiàn)，的確帶來很多好處，不光可以隨心所以的增刪字段，還可以修改數(shù)據(jù)類型，例如把cmd改成int cmd；可以無縫兼容。真是太給力了。

三、跨語言特性

有一天來了一個新的同事C，他寫一個新的服務，需要和A通信，但是C是用java或PHP的語言，沒有無符號類型，導致負數(shù)解析失敗。為了解決這個問題，A重新規(guī)劃一下協(xié)議類型，做了有些剝離語言特性，定義一些共性。對使用類型做了強制性約束。雖然帶來了約束，但是帶來通用型和簡潔性，和跨語言性，大家表示都很贊同，于是有了一個類型(type)規(guī)范。

四、代碼自動化——IDL語言的產(chǎn)生

但是A和B發(fā)現(xiàn)了新的煩惱，就是每搞一套新的協(xié)議，都要從頭編解碼，調(diào)試，雖然TLV很簡單，但是寫編解碼是一個毫無技術含量的枯燥體力活，一個非 常明顯的問題是，由于大量copy/past,不管是對新手還是老手，非常容易犯錯，一犯錯，定位排錯非常耗時。于是A想到使用工具自動生成代碼。

IDL（Interface Description Language），它是一種描述語言，也是一個中間語言，IDL一個使命就是規(guī)范和約束，就像前面提到，規(guī)范使用類型，提供跨語言特性。通過工具分析idl文件，生成各種語言代碼

Gencpp.exe sample.idl 輸出 sample.cpp sample.h

Genphp.exe sample.idl 輸出 sample.php

Genjava.exe sample.idl 輸出 sample.java

是不是簡單高效J

四、總結(jié)

大家看到這里，是不是覺得很面熟。是的，協(xié)議講到最后，其實就是和facebook的thrift和google protocol buffer協(xié)議大同小異了。包括公司無線使用的jce協(xié)議。咋一看這些協(xié)議的idl文件，發(fā)現(xiàn)幾乎是一樣的。只是有些細小差異化。

這些協(xié)議在一些細節(jié)上增加了一些特性：

1、壓縮，這里壓縮不是指gzip之類通用壓縮，是指針對整數(shù)壓縮，如int類型，很多情況下值是小于127（值為0的情況特別多），就不需要占用4個字節(jié)，所以這些協(xié)議做了一些細化處理，把int類型按照情況，只使用1/2/3/4字節(jié)，實際上還是一種ttlv協(xié)議。

2、reuire/option 特性: 這個特性有兩個作用，1、還是壓縮，有時候一個協(xié)議很多字段，有些字段可以帶上也可以不帶上，不賦值的時候不是也要帶一個缺省值打包，這樣很浪費，如果字 段是option特性，沒有賦值的話，就不用打包。2、有點邏輯上約束功能，規(guī)定哪些字段必須有，加強校驗。

序列化是通信協(xié)議的基礎，不管是信令通道還是數(shù)據(jù)通道，還是rpc，都需要使用到。在設計協(xié)議早期就考慮到擴展性和跨語言特性。會為以后省去不少麻煩。

Ps

本篇主要介紹二進制通信協(xié)議序列化，沒有講文本協(xié)議。從某種意義來講，文本協(xié)議天生具有兼容和可擴展性。不像二進制需要考慮那么多問題。文本協(xié)議易于調(diào)試（如抓包就是可見字符，telnet即可調(diào)試，數(shù)據(jù)包可以手工生成不借助特殊工具），簡單易學是其最強大的優(yōu)勢。

二進制協(xié)議優(yōu)勢就是性能和安全性。但是調(diào)試麻煩。

兩者各有千秋，按需選擇。(stevenrao)