進行Chunked編碼傳輸的HTTP Response會在消息頭部設置：
Transfer-Encoding: chunked
表示Content Body將用Chunked編碼傳輸內容。
Chunked編碼使用若干個Chunk串連而成，由一個標明長度為0的chunk標示結束。每個Chunk分為頭部和正文兩部分，頭部內容指定下一段正文的字符總數（十六進制的數字）和數量單位（一般不寫），正文部分就是指定長度的實際內容，兩部分之間用回車換行(CRLF)隔開。在最后一個長度為0的Chunk中的內容是稱為footer的內容，是一些附加的Header信息（通常可以直接忽略）。具體的Chunk編碼格式如下：
Chunked-Body = *chunk "0" CRLF footer CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
hex-no-zero = <HEX excluding "0">
chunk-size = hex-no-zero *HEX chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET)
footer = *entity-header
RFC文檔中的Chunked解碼過程如下： length := 0 read chunk-size, chunk-ext (if any) and CRLF while (chunk-size > 0) { read chunk-data and CRLF append chunk-data to entity-body length := length + chunk-size read chunk-size and CRLF } read entity-header while (entity-header not empty) { append entity-header to existing header fields read entity-header } Content-Length := length Remove "chunked" from Transfer-Encoding
最后提供一段PHP版本的chunked解碼代碼：
$chunk_size= (integer)hexdec(fgets( $socket_fd,4096 ) ); while(!feof($socket_fd) &&$chunk_size>0) { $bodyContent.=fread( $socket_fd,$chunk_size ); fread( $socket_fd,2 ); // skip /r/n $chunk_size= (integer)hexdec(fgets( $socket_fd,4096 ) ); }
HTTP協議中的TRANFER-ENCODING：CHUNKED編碼解析 通常情況下，Transfer-Encoding域的值應當為chunked,表明采用chunked編碼方式來進行報文體的傳輸。chunked編碼是HTTP/1.1 RFC里定義的一種編碼方式，因此所有的HTTP/1.1應用都應當支持此方式。 chunked編碼的基本方法是將大塊數據分解成多塊小數據，每塊都可以自指定長度，其具體格式如下（BNF文法）: Chunked-Body = *chunk //0至多個chunk last-chunk //最后一個chunk trailer //尾部 CRLF //結束標記符
chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer = *(entity-header CRLF) 解釋： Chunked-Body表示經過chunked編碼后的報文體。報文體可以分為chunk, last-chunk，trailer和結束符四部分。chunk的數量在報文體中最少可以為0，無上限；每個chunk的長度是自指定的，即，起始的數據必然是16進制數字的字符串，代表后面chunk-data的長度（字節數）。這個16進制的字符串第一個字符如果是“0”，則表示chunk-size為0，該chunk為last-chunk,無chunk-data部分。可選的chunk-extension由通信雙方自行確定，如果接收者不理解它的意義，可以忽略。 trailer是附加的在尾部的額外頭域，通常包含一些元數據（metadata, meta means "about information"），這些頭域可以在解碼后附加在現有頭域之后。 實例分析： 下面分析用ethereal抓包使用Firefox與某網站通信的結果（從頭域結束符后開始）： Address 0.......................... f 000c0 31 000d0 66 66 63 0d 0a ............... // ASCII碼:1ffc/r/n, chunk-data數據起始地址為000d5 很明顯，“1ffc”為第一個chunk的chunk-size,轉換為int為8188.由於1ffc后馬上就是 CRLF,因此沒有chunk-extension.chunk-data的起始地址為000d5, 計算可知下一塊chunk的起始 地址為000d5+1ffc + 2=020d3,如下： 020d0 .. 0d 0a 31 66 66 63 0d 0a .... // ASCII碼:/r/n1ffc/r/n 前一個0d0a是上一個chunk的結束標記符，后一個0d0a則是chunk-size和chunk-data的分隔符。 此塊chunk的長度同樣為8188, 依次類推，直到最后一塊 100e0 0d 0a 31 100f0 65 61 39 0d 0a...... //ASII碼：/r/n/1ea9/r/n 此塊長度為0x1ea9 = 7849, 下一塊起始為100f5 + 1ea9 + 2 = 11fa0,如下： 100a0 30 0d 0a 0d 0a //ASCII碼：0/r/n/r/n “0”說明當前chunk為last-chunk, 第一個0d 0a為chunk結束符。第二個0d0a說明沒有trailer部分，整個Chunk-body結束。 解碼流程： 對chunked編碼進行解碼的目的是將分塊的chunk-data整合恢復成一塊作為報文體，同時記錄此塊體的長度。 RFC2616中附帶的解碼流程如下：(偽代碼） length := 0 //長度計數器置0 read chunk-size, chunk-extension (if any) and CRLF //讀取chunk-size, chunk-extension //和CRLF while(chunk-size > 0 ) { //表明不是last-chunk read chunk-data and CRLF //讀chunk-size大小的chunk-data,skip CRLF append chunk-data to entity-body //將此塊chunk-data追加到entity-body后 read chunk-size and CRLF //讀取新chunk的chunk-size 和 CRLF } read entity-header //entity-header的格式為name:valueCRLF,如果為空即只有CRLF while （entity-header not empty) //即，不是只有CRLF的空行 { append entity-header to existing header fields read entity-header } Content-Length:=length //將整個解碼流程結束后計算得到的新報文體length //作為Content-Length域的值寫入報文中 Remove "chunked" from Transfer-Encoding //同時從Transfer-Encoding中域值去除chunked這個標記 length最后的值實際為所有chunk的chunk-size之和，在上面的抓包實例中，一共有八塊chunk-size為0x1ffc(8188)的chunk,剩下一塊為0x1ea9(7849),加起來一共73353字節。 注：對於上面例子中前幾個chunk的大小都是8188,可能是因為:"1ffc" 4字節，"/r/n"2字節，加上塊尾一個"/r/n"2字節一共8字節，因此一個chunk整體為8196,正好可能是發送端一次TCP發送的緩存大小。