分塊傳輸編碼

分塊傳輸編碼（英語：Chunked transfer encoding）是超文字傳輸協定（HTTP）中的一種數據傳輸機制，允許HTTP由網頁伺服器傳送給客戶端應用（ 通常是網頁瀏覽器）的數據可以分成多個部分。分塊傳輸編碼只在HTTP協定1.1版本（HTTP/1.1）中提供。

通常，HTTP應答訊息中傳送的數據是整個傳送的，Content-Length訊息頭欄位表示數據的長度。數據的長度很重要，因為客戶端需要知道哪裏是應答訊息的結束，以及後續應答訊息的開始。然而，使用分塊傳輸編碼，數據分解成一系列數據塊，並以一個或多個塊傳送，這樣伺服器可以傳送數據而不需要預先知道傳送內容的總大小。通常數據塊的大小是一致的，但也不總是這種情況。

原理

HTTP 1.1引入分塊傳輸編碼提供了以下幾點好處：

1. HTTP分塊傳輸編碼允許伺服器為動態生成的內容維持HTTP持久連結。通常，持久連結需要伺服器在開始傳送訊息體前傳送Content-Length訊息頭欄位，但是對於動態生成的內容來說，在內容建立完之前是不可知的。^[1]
2. 分塊傳輸編碼允許伺服器在最後傳送訊息頭欄位。對於那些頭欄位值在內容被生成之前無法知道的情形非常重要，例如訊息的內容要使用雜湊進行簽章，雜湊的結果通過HTTP訊息頭欄位進行傳輸。沒有分塊傳輸編碼時，伺服器必須緩衝內容直到完成後計算頭欄位的值並在傳送內容前傳送這些頭欄位的值。
3. HTTP伺服器有時使用壓縮 （gzip或deflate）以縮短傳輸花費的時間。分塊傳輸編碼可以用來分隔壓縮對象的多個部分。在這種情況下，塊不是分別壓縮的，而是整個負載進行壓縮，壓縮的輸出使用本文描述的方案進行分塊傳輸。在壓縮的情形中，分塊編碼有利於一邊進行壓縮一邊傳送數據，而不是先完成壓縮過程以得知壓縮後數據的大小。

格式

如果一個HTTP訊息（包括客戶端傳送的請求訊息或伺服器返回的應答訊息）的Transfer-Encoding訊息頭的值為chunked，那麼，訊息體由數量未定的塊組成，並以最後一個大小為0的塊為結束。

每一個非空的塊都以該塊包含數據的位元組數（位元組數以十六進制表示）開始，跟隨一個CRLF （Enter及換行），然後是數據本身，最後塊CRLF結束。在一些實現中，塊大小和CRLF之間填充有白空格（0x20）。

最後一塊是單行，由塊大小（0），一些可選的填充白空格，以及CRLF。最後一塊不再包含任何數據，但是可以傳送可選的尾部，包括訊息頭欄位。

訊息最後以CRLF結尾。

例子

編碼的數據

25
This is the data in the first chunk

1C
and this is the second one

3
con

8
sequence

0

編碼數據的解釋

前兩個塊的數據中包含有顯式的\r\n字元。

"This is the data in the first chunk\r\n"      (37 字符 => 十六进制: 0x25)
"and this is the second one\r\n"               (28 字符 => 十六进制: 0x1C)
"con"                                          (3  字符 => 十六进制: 0x03)
"sequence"                                     (8  字符 => 十六进制: 0x08)

編碼的數據需要以0長度的塊（ "0\r\n\r\n".）結束。

解碼的數據

This is the data in the first chunk
and this is the second one
consequence

參見

• HTTP

參考文獻

1. Roy T. Fielding. Keep-Alive Notes. HTTP Working Group (HTTP-WG) mailing list. 10 Oct 1995. （原始內容存檔於2010-07-05）.

• 更多細節請參見 RFC 2616 ,特別是3.6.1節。