分塊傳輸編碼（chunked transfer encoding）是只在http協議1.1版本（http/1.1）中提供的一種資料傳送機制。以往http的應答中資料是整個一起傳送的，並在應答頭里content-length欄位標識了資料的長度，以便客戶端知道應答訊息的結束。
對於動態生成的應答內容來說，內容在未生成完成前總長度是不可知的。因此需要先快取生成的內容，再計算總長度填充到content-length，再傳送整個資料內容。這樣顯得不太靈活，而使用分塊編碼則能得到改觀。
分塊傳輸編碼允許伺服器在最後傳送訊息頭欄位。例如在頭中新增雜湊簽名。
對於壓縮傳輸傳輸而言，可以一邊壓縮一邊傳輸。
如果在http的訊息頭里transfer-encoding為chunked，那麼就是使用此種編碼方式。接下來會傳送數量未知的塊，每乙個塊的開頭都有乙個十六進製制的數,表明這個塊的大小，然後接crlf("\r\n")。然後是資料本身，資料結束後，還會有crlf兩個字元。有一些實現中，塊大小的十六進製制數和crlf之間可以有空格。
最後一塊的塊大小為0，表明資料傳送結束。最後一塊不再包含任何資料，但是可以傳送可選的尾部，包括訊息頭欄位。訊息最後以crlf結尾。 參考
維基百科：
HTTP協議chunked編碼
當不能預先確定報文體的長度時，不可能在頭中包含content length域來指明報文體長度，此時就需要通過transfer encoding域來確定報文體長度。此時，transfer encoding域的值應當為chunked，表明採用chunked編碼方式來進行報文體的傳輸。chunked編碼是...
HTTP響應Chunked編碼
最近公司有個應用要為第3方系統提供介面，大概要求就是對方向我方系統傳送乙個xml報文，我方根據請求報文響應資料，並以xml格式進行返回.測試的時候發現乙個比較詭異的問題，有時候請求響應會無故多生成一些沒有規律的字串，並且這些字串都在響應的body頭部，由於響應是xml格式的，這些多餘字串在xml檔案...
HTTP響應Chunked編碼
最近公司有個應用要為第3方系統提供介面，大概要求就是對方向我方系統傳送乙個xml報文，我方根據請求報文響應資料，並以xml格式進行返回.測試的時候發現乙個比較詭異的問題，有時候請求響應會無故多生成一些沒有規律的字串，並且這些字串都在響應的body頭部，由於響應是xml格式的，這些多餘字串在xml檔案...