分塊傳輸編碼（chunked transfer encoding）是超文字傳輸協議http中的一種資料傳輸機制，允許http由網頁伺服器傳送給客戶端應用的資料可以分成多個部分。分塊傳輸編碼只在http協議1.1中提供。
原理：http 1.1引入分塊傳輸編碼提供了以下幾點好處：
http分塊傳輸編碼允許伺服器為動態生成的內容維持http持久鏈結。通常，持久鏈結需要伺服器在開始傳送訊息體前傳送content-length訊息頭欄位，但是對於動態生成的內容來說，在內容建立完之前是不可知的。[1]
分塊傳輸編碼允許伺服器在最後傳送訊息頭欄位。對於那些頭字段值在內容被生成之前無法知道的情形非常重要，例如訊息的內容要使用雜湊進行簽名，雜湊的結果通過http訊息頭欄位進行傳輸。沒有分塊傳輸編碼時，伺服器必須緩衝內容直到完成後計算頭字段的值並在傳送內容前傳送這些頭字段的值。
http伺服器有時使用壓縮 （gzip或deflate）以縮短傳輸花費的時間。分塊傳輸編碼可以用來分隔壓縮物件的多個部分。在這種情況下，塊不是分別壓縮的，而是整個負載進行壓縮，壓縮的輸出使用本文描述的方案進行分塊傳輸。在壓縮的情形中，分塊編碼有利於一邊進行壓縮一邊傳送資料，而不是先完成壓縮過程以得知壓縮後資料的大小。
例子：
0最後是以
如果乙個http訊息（請求訊息或應答訊息）的transfer-encoding訊息頭的值為chunked，那麼，訊息體由數量未定的塊組成，並以最後乙個大小為0的塊為結束。
每乙個非空的塊都以該塊包含資料的位元組數（位元組數以十六進製制表示）開始，跟隨乙個crlf （回車及換行），然後是資料本身，最後塊crlf結束。在一些實現中，塊大小和crlf之間填充有白空格（0x20）。
最後一塊是單行，由塊大小（0），一些可選的填充白空格，以及crlf。最後一塊不再包含任何資料，但是可以傳送可選的尾部，包括訊息頭欄位。
訊息最後以crlf結尾。
HTTP響應Chunked編碼
最近公司有個應用要為第3方系統提供介面，大概要求就是對方向我方系統傳送乙個xml報文，我方根據請求報文響應資料，並以xml格式進行返回.測試的時候發現乙個比較詭異的問題，有時候請求響應會無故多生成一些沒有規律的字串，並且這些字串都在響應的body頭部，由於響應是xml格式的，這些多餘字串在xml檔案...
HTTP響應Chunked編碼
最近公司有個應用要為第3方系統提供介面，大概要求就是對方向我方系統傳送乙個xml報文，我方根據請求報文響應資料，並以xml格式進行返回.測試的時候發現乙個比較詭異的問題，有時候請求響應會無故多生成一些沒有規律的字串，並且這些字串都在響應的body頭部，由於響應是xml格式的，這些多餘字串在xml檔案...
HTTP協議chunked編碼
當不能預先確定報文體的長度時，不可能在頭中包含content length域來指明報文體長度，此時就需要通過transfer encoding域來確定報文體長度。此時，transfer encoding域的值應當為chunked，表明採用chunked編碼方式來進行報文體的傳輸。chunked編碼是...