轉載自：https://zh.wikipedia.org/wiki/%E5%88%86%E5%9D%97%E4%BC%A0%E8%BE%93%E7%BC%96%E7%A0%81

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

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

目錄

• 1原理
• 2格式
• 3例子
  • 3.1編碼的應答
  • 3.2編碼應答的解釋
  • 3.3解碼的資料
• 4參見
• 5參考文獻

原理[編輯]

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

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

格式[編輯]

如果一個HTTP訊息（請求訊息或應答訊息）的Transfer-Encoding訊息頭的值為chunked，那麼，訊息體由數量未定的塊組成，並以最後一個大小為0的塊為結束。

每一個非空的塊都以該塊包含資料的位元組數（位元組數以十六進位制

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

訊息最後以CRLF結尾。

例子[編輯]

編碼的應答[編輯]

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

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