自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

HTTP協(xié)議中你必須知道的三種數(shù)據(jù)格式

開發(fā) 前端
實(shí)習(xí)中的一個(gè)主要工作就是分析 HTTP 中的協(xié)議,自己也用 Python 寫過正則表達(dá)式對(duì) HTTP 請(qǐng)求和響應(yīng)的內(nèi)容進(jìn)行匹配,然后把關(guān)鍵字段抽離出來放到一個(gè)字典中以備使用(可以稍微改造一下就是一個(gè)爬蟲工具)。HTTP 協(xié)議中的很多坑,自己都遇到過,我就針對(duì)自己遇到的幾種 HTTP 常見的數(shù)據(jù)格式,來做一個(gè)總結(jié)。

[[175875]]

實(shí)習(xí)中的一個(gè)主要工作就是分析 HTTP 中的協(xié)議,自己也用 Python 寫過正則表達(dá)式對(duì) HTTP 請(qǐng)求和響應(yīng)的內(nèi)容進(jìn)行匹配,然后把關(guān)鍵字段抽離出來放到一個(gè)字典中以備使用(可以稍微改造一下就是一個(gè)爬蟲工具)。

HTTP 協(xié)議中的很多坑,自己都遇到過,我就針對(duì)自己遇到的幾種 HTTP 常見的數(shù)據(jù)格式,來做一個(gè)總結(jié)。

Zlib 壓縮數(shù)據(jù)

對(duì)于 Zlib,一點(diǎn)也不陌生,我們平時(shí)用它來壓縮文件,常見類型有 zip、rar 和 7z 等。Zlib 是一種流行的文件壓縮算法,應(yīng)用十分廣泛,尤其是在 Linux 平臺(tái)。當(dāng)應(yīng)用 Zlib 壓縮到一個(gè)純文本文件時(shí),效果是非常明顯的,大約可以減少70%以上的文件大小,這取決于文件中的內(nèi)容。

Zlib 也適用于 Web 數(shù)據(jù)傳輸,比如利用 Apache 中的 Gzip (后面會(huì)提到,一種壓縮算法) 模塊,我們可以使用 Gzip 壓縮算法來對(duì) Apache 服務(wù)器發(fā)布的網(wǎng)頁內(nèi)容進(jìn)行壓縮后再傳輸?shù)娇蛻舳藶g覽器。這樣經(jīng)過壓縮后實(shí)際上降低了網(wǎng)絡(luò)傳輸?shù)淖止?jié)數(shù),最明顯的好處就是可以加快網(wǎng)頁加載的速度。

網(wǎng)頁加載速度加快的好處不言而喻,節(jié)省流量,改善用戶的瀏覽體驗(yàn)。而這些好處并不僅僅限于靜態(tài)內(nèi)容,PHP 動(dòng)態(tài)頁面和其他動(dòng)態(tài)生成的內(nèi)容均可以通過使用 Apache 壓縮模塊壓縮,加上其他的性能調(diào)整機(jī)制和相應(yīng)的服務(wù)器端 緩存規(guī)則,這可以大大提高網(wǎng)站的性能。因此,對(duì)于部署在 Linux 服務(wù)器上的 PHP 程序,在服務(wù)器支持的情況下,建議你開啟使用 Gzip Web 壓縮。

Gzip 壓縮兩種類型

壓縮算法不同,可以產(chǎn)生不同的壓縮數(shù)據(jù)(目的都是為了減小文件大小)。目前 Web 端流行的壓縮格式有兩種,分別是 Gzip 和 Defalte。

Apache 中的就是 Gzip 模塊,Deflate 是同時(shí)使用了 LZ77 算法與哈夫曼編碼(Huffman Coding)的一個(gè)無損數(shù)據(jù)壓縮算法。Deflate 壓縮與解壓的源代碼可以在自由、通用的壓縮庫 zlib 上找到。

更高壓縮率的 Deflate 是 7-zip 所實(shí)現(xiàn)的。AdvanceCOMP 也使用這種實(shí)現(xiàn),它可以對(duì) gzip、PNG、MNG 以及 ZIP 文件進(jìn)行壓縮從而得到比 zlib 更小的文件大小。在 Ken Silverman的 KZIP 與 PNGOUT 中使用了一種更加高效同時(shí)要求更多用戶輸入的 Deflate 程序。

deflate 使用 inflateInit(),而 gzip 使用 inflateInit2() 進(jìn)行初始化,比 inflateInit() 多一個(gè)參數(shù): -MAX_WBITS,表示處理 raw deflate 數(shù)據(jù)。因?yàn)?gzip 數(shù)據(jù)中的 zlib 壓縮數(shù)據(jù)塊沒有 zlib header 的兩個(gè)字節(jié)。使用 inflateInit2 時(shí)要求 zlib 庫忽略 zlib header。在 zlib 手冊(cè)中要求 windowBits 為 8..15,但是實(shí)際上其它范圍的數(shù)據(jù)有特殊作用,如負(fù)數(shù)表示 raw deflate。

其實(shí)說這么多,總結(jié)一句話,Deflate 是一種壓縮算法,是 huffman 編碼的一種加強(qiáng)。 deflate 與 gzip 解壓的代碼幾乎相同,可以合成一塊代碼。

更多知識(shí)請(qǐng)見 維基百科 zlib。

Web 服務(wù)器處理數(shù)據(jù)壓縮的過程

Web服務(wù)器接收到瀏覽器的HTTP請(qǐng)求后,檢查瀏覽器是否支持HTTP壓縮(Accept-Encoding 信息);

如果瀏覽器支持HTTP壓縮,Web服務(wù)器檢查請(qǐng)求文件的后綴名;

如果請(qǐng)求文件是HTML、CSS等靜態(tài)文件,Web服務(wù)器到壓縮緩沖目錄中檢查是否已經(jīng)存在請(qǐng)求文件的***壓縮文件;

如果請(qǐng)求文件的壓縮文件不存在,Web服務(wù)器向?yàn)g覽器返回未壓縮的請(qǐng)求文件,并在壓縮緩沖目錄中存放請(qǐng)求文件的壓縮文件;

如果請(qǐng)求文件的***壓縮文件已經(jīng)存在,則直接返回請(qǐng)求文件的壓縮文件;

如果請(qǐng)求文件是動(dòng)態(tài)文件,Web服務(wù)器動(dòng)態(tài)壓縮內(nèi)容并返回瀏覽器,壓縮內(nèi)容不存放到壓縮緩存目錄中。

舉個(gè)栗子

說了這么多,下面舉一個(gè)例子,打開抓包軟件,訪問我們學(xué)校的官網(wǎng)( www.ecnu.edu.cn ),請(qǐng)求頭如下:

  1. GET /_css/tpl2/system.css HTTP/1.1 
  2. Host: www.ecnu.edu.cn 
  3. Connection: keep-alive 
  4. User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36 
  5. Accept: text/css,*/*;q=0.1 
  6. Referer: http://www.ecnu.edu.cn/ 
  7. Accept-Encoding: gzip, deflate 
  8. Accept-Language: zh-CN,zh;q=0.8 
  9. Cookie: a10-default-cookie-persist-20480-sg_bluecoat_a=AFFIHIMKFAAA  

在第七行, Accept-Encoding 顯示的是 gzip, deflate,這句話的意思是,瀏覽器告訴服務(wù)器支持 gzip 和 deflate 兩種數(shù)據(jù)格式,服務(wù)器收到這種請(qǐng)求之后,會(huì)進(jìn)行 gzip 或 deflate 壓縮(一般都是返回 gzip 格式的數(shù)據(jù))。

Python 的 urllib2 就可以設(shè)置這個(gè)參數(shù):

  1. request = urllib2.Request(url) 
  2. request.add_header('Accept-encoding''gzip'
  3. //或者設(shè)置成 deflate 
  4. request.add_header('Accept-encoding''deflate'
  5. //或者兩者都設(shè)置 
  6. request.add_header('Accept-encoding''gzip, deflate' 

服務(wù)器給的響應(yīng)一般如下:

  1. HTTP/1.1 200 OK 
  2. Date: Sat, 22 Oct 2016 11:41:19 GMT 
  3. Content-Type: text/javascript;charset=utf-8 
  4. Transfer-Encoding: chunked 
  5. Connectionclose 
  6. Vary: Accept-Encoding 
  7. tracecode: 24798560510951725578102219 
  8. Server: Apache 
  9. Content-Encoding: gzip 
  10.  
  11. 400a 
  12. ............ks#I. ...W...,....>..T..]..Z...Y..].MK..2..L..(略) 
  13. //響應(yīng)體為壓縮數(shù)據(jù)  

從響應(yīng)頭來看,Content-Encoding: gzip 這段話說明響應(yīng)體的壓縮方式是 gzip 壓縮,一般有幾種情況,字段為空表示明文無壓縮,還有 Content-Encoding: gzip 和 Content-Encoding: deflate 兩種。

實(shí)際上 Gzip 網(wǎng)站要遠(yuǎn)比 Deflate 多,之前寫過一個(gè)簡(jiǎn)單爬蟲從 hao123的主頁開始爬,爬幾千個(gè)網(wǎng)頁(基本涵蓋所有常用的),專門分析響應(yīng)體的壓縮類型,得到的結(jié)果是:

  1. Accept-Encoding 不設(shè)置參數(shù):會(huì)返回一個(gè)無壓縮的響應(yīng)體(瀏覽器比較特別,他們會(huì)自動(dòng)設(shè)置 Accept-Encoding: gzip: deflate 來提高傳輸速度);
  2. Accept-Encoding: gzip,100% 的網(wǎng)站都會(huì)返回 gzip 壓縮,但不保證互聯(lián)網(wǎng)所有網(wǎng)站都支持 gzip(萬一沒開啟);
  3. Accept-Encoding: deflate:只有不到 10% 的網(wǎng)站返回一個(gè) deflate 壓縮的響應(yīng),其他的則返回一個(gè)沒有壓縮的響應(yīng)體。
  4. Accept-Encoding: gzip, deflate:返回的結(jié)果也都是 gzip 格式的數(shù)據(jù),說明在優(yōu)先級(jí)上 gzip 更受歡迎。

響應(yīng)頭的 Encoding 字段很有幫助,比如我們寫個(gè)正則表達(dá)式匹配響應(yīng)頭是什么壓縮:

  1. (?<=Content-Encoding: ).+(?=\r\n) 

匹配到內(nèi)容為空說明沒有壓縮,為 gzip 說明響應(yīng)體要經(jīng)過 gzip 解壓,為 deflate 說明為 deflate 壓縮。

Python 中的 zlib 庫

在python中有zlib庫,它可以解決gzip、deflate和zlib壓縮。這三種對(duì)應(yīng)的壓縮方式分別是:

  1. RFC 1950 (zlib compressed format) 
  2. RFC 1951 (deflate compressed format) 
  3. RFC 1952 (gzip compressed format)  

雖說是 Python 庫,但是底層還是 C(C++) 來實(shí)現(xiàn)的,這個(gè) http-parser 也是 C 實(shí)現(xiàn)的源碼,Nodejs 的 http-parser 也是 C 實(shí)現(xiàn)的源碼,zlib 的 C 源碼在這里。C 真的好牛逼呀!

在解壓縮的過程中,需要選擇 windowBits 參數(shù):

  1. to (de-)compress deflate format, use wbits = -zlib.MAX_WBITS 
  2. to (de-)compress zlib format, use wbits = zlib.MAX_WBITS 
  3. to (de-)compress gzip format, use wbits = zli  

例如,解壓gzip數(shù)據(jù),就可以使用zlib.decompress(data, zlib.MAX_WBITS | 16),解壓deflate數(shù)據(jù)可以使用zlib.decompress(data,- zlib.MAX_WBITS)。

當(dāng)然,對(duì)于gzip文件,也可以使用python的gzip包來解決,可以參考下面的代碼:

  1. >>> import gzip 
  2. >>> import StringIO 
  3. >>> fio = StringIO.StringIO(gzip_data) 
  4. >>> f = gzip.GzipFile(fileobj=fio) 
  5. >>> f.read() 
  6. 'test' 
  7. >>> f.close()  

也可以在解壓的時(shí)候自動(dòng)加入頭檢測(cè),把32加入頭中就可以觸發(fā)頭檢測(cè),例如:

  1. >>> zlib.decompress(gzip_data, zlib.MAX_WBITS|32) 
  2. 'test' 
  3. >>> zlib.decompress(zlib_data, zlib.MAX_WBITS|32) 
  4. 'test'  

以上參考 stackoverflow How can I decompress a gzip stream with zlib?。

剛接觸這些東西的時(shí)候,每天都會(huì)稀奇古怪的報(bào)一些錯(cuò)誤,基本上 Google 一下都能解決。

分塊傳輸編碼 chunked

分塊傳輸編碼(Chunked transfer encoding)是超文本傳輸協(xié)議(HTTP)中的一種數(shù)據(jù)傳輸機(jī)制,允許 HTTP 由網(wǎng)頁服務(wù)器發(fā)送給客戶端應(yīng)用( 通常是網(wǎng)頁瀏覽器)的數(shù)據(jù)可以分成多個(gè)部分。分塊傳輸編碼只在 HTTP 協(xié)議 1.1 版本(HTTP/1.1)中提供。

通常,HTTP 應(yīng)答消息中發(fā)送的數(shù)據(jù)是整個(gè)發(fā)送的,Content-Length 消息頭字段表示數(shù)據(jù)的長(zhǎng)度。數(shù)據(jù)的長(zhǎng)度很重要,因?yàn)榭蛻舳诵枰滥睦锸菓?yīng)答消息的結(jié)束,以及后續(xù)應(yīng)答消息的開始。然而,使用分塊傳輸編碼,數(shù)據(jù)分解成一系列數(shù)據(jù)塊,并以一個(gè)或多個(gè)塊發(fā)送,這樣服務(wù)器可以發(fā)送數(shù)據(jù)而不需要預(yù)先知道發(fā)送內(nèi)容的總大小。通常數(shù)據(jù)塊的大小是一致的,但也不總是這種情況。

分塊傳輸?shù)膬?yōu)點(diǎn)

HTTP 1.1引入分塊傳輸編碼提供了以下幾點(diǎn)好處:

  • HTTP 分塊傳輸編碼允許服務(wù)器為動(dòng)態(tài)生成的內(nèi)容維持 HTTP 持久鏈接。通常,持久鏈接需要服務(wù)器在開始發(fā)送消息體前發(fā)送 Content-Length 消息頭字段,但是對(duì)于動(dòng)態(tài)生成的內(nèi)容來說,在內(nèi)容創(chuàng)建完之前是不可知的。
  • 分塊傳輸編碼允許服務(wù)器在***發(fā)送消息頭字段。對(duì)于那些頭字段值在內(nèi)容被生成之前無法知道的情形非常重要,例如消息的內(nèi)容要使用散列進(jìn)行簽名,散列的結(jié)果通過 HTTP 消息頭字段進(jìn)行傳輸。沒有分塊傳輸編碼時(shí),服務(wù)器必須緩沖內(nèi)容直到完成后計(jì)算頭字段的值并在發(fā)送內(nèi)容前發(fā)送這些頭字段的值。
  • HTTP 服務(wù)器有時(shí)使用壓縮 (gzip 或 deflate)以縮短傳輸花費(fèi)的時(shí)間。分塊傳輸編碼可以用來分隔壓縮對(duì)象的多個(gè)部分。在這種情況下,塊不是分別壓縮的,而是整個(gè)負(fù)載進(jìn)行壓縮,壓縮的輸出使用本文描述的方案進(jìn)行分塊傳輸。在壓縮的情形中,分塊編碼有利于一邊進(jìn)行壓縮一邊發(fā)送數(shù)據(jù),而不是先完成壓縮過程以得知壓縮后數(shù)據(jù)的大小。

注:以上內(nèi)容來自于維基百科。

分塊傳輸?shù)母袷?/strong>

如果一個(gè) HTTP 消息(請(qǐng)求消息或應(yīng)答消息)的 Transfer-Encoding 消息頭的值為 chunked,那么,消息體由數(shù)量未定的塊組成,并以***一個(gè)大小為 0 的塊為結(jié)束。每一個(gè)非空的塊都以該塊包含數(shù)據(jù)的字節(jié)數(shù)(字節(jié)數(shù)以十六進(jìn)制表示)開始,跟隨一個(gè) CRLF(回車及換行),然后是數(shù)據(jù)本身,***塊 CRLF 結(jié)束。在一些實(shí)現(xiàn)中,塊大小和 CRLF 之間填充有白空格(0x20)。

***一塊是單行,由塊大小(0),一些可選的填充白空格,以及 CRLF。***一塊不再包含任何數(shù)據(jù),但是可以發(fā)送可選的尾部,包括消息頭字段。

消息***以 CRLF 結(jié)尾。例如下面就是一個(gè) chunked 格式的響應(yīng)體。

  1. HTTP/1.1 200 OK 
  2. Date: Wed, 06 Jul 2016 06:59:55 GMT 
  3. Server: Apache 
  4. Accept-Ranges: bytes 
  5. Transfer-Encoding: chunked 
  6. Content-Type: text/html 
  7. Content-Encoding: gzip 
  8. Age: 35 
  9. X-Via: 1.1 daodianxinxiazai58:88 (Cdn Cache Server V2.0), 1.1 yzdx147:1 (Cdn  
  10. Cache Server V2.0) 
  11. Connection: keep-alive 
  12.  
  13. ....k.|W.. 
  14. 166 
  15. ..OO.0...&~..;........]..(F=V.A3.X..~z...-.l8......y....).?....,....j..h .6 
  16. ....s.~.>..mZ .8/..,.)B.G.`"Dq.P].f=0..Q..d.....h......8....F..y......q.....4 
  17. {F..M.A.*..a.rAra.... .n>.D 
  18. ..o@.`^.....!@ $...p...%a\D..K.. .d{2...UnF,C[....T.....c....V...."%.`U......? 
  19. D....#..K..<.....D.e....IFK0.<...)]K.V/eK.Qz...^....t...S6...m...^..CK.XRU?m.. 
  20. .........Z..#Uik...... 
  21.  

Transfer-Encoding: chunked字段可以看出響應(yīng)體是否為 chunked 壓縮,chunked 數(shù)據(jù)很有意思,采用的格式是 長(zhǎng)度\r\n內(nèi)容\r\n長(zhǎng)度\r\n..0\r\n,而且長(zhǎng)度還是十六進(jìn)制的,***以 0\r\n 結(jié)尾(不保證都有)。因?yàn)樯厦娴臄?shù)據(jù)是 gzip 壓縮,看起來不夠直觀,下面舉個(gè)簡(jiǎn)單的例子:

  1. 5\r\n 
  2. ababa\r\n 
  3. f\r\n 
  4. 123451234512345\r\n 
  5. 14\r\n 
  6. 12345123451234512345\r\n 
  7. 0\r\n  

上述例子 chunked 解碼后的數(shù)據(jù) ababa12345...,另外 \r\n 是不可見的,我手動(dòng)加的。

和 gzip 一樣,一樣可以寫一個(gè)正則表達(dá)式來匹配:

  1. (?<=Transfer-Encoding: ).+(?=\r\n) 

處理 chunked 數(shù)據(jù)

從前面的介紹可以知道,response-body 部分其實(shí)由 length(1) \r\n data(1) \r\n length(2) \r\n data(2)…… 循環(huán)組成,通過下面的函數(shù)進(jìn)行處理,再根據(jù)壓縮類型解壓出最終的數(shù)據(jù)。

Python 處理的過程如下:

  1. unchunked = b'' 
  2. pos = 0 
  3. while pos <= len(data): 
  4.     chunkNumLen = data.find(b'\r\n', pos)-pos 
  5.     //從***個(gè)元素開始,發(fā)現(xiàn)***個(gè)\r\n,計(jì)算length長(zhǎng)度 
  6.     chunkLen=int(data[pos:pos+chunkNumLen], 16) 
  7.     //把length的長(zhǎng)度轉(zhuǎn)換成int 
  8.     if chunkLen == 0: 
  9.         break 
  10.         //如果長(zhǎng)度為0,則說明到結(jié)尾 
  11.     chunk = data[pos+chunkNumLen+len('\r\n'):pos+chunkNumLen+len('\r\n')+chunkLen] 
  12.     unchunked += chunk 
  13.     //將壓縮數(shù)據(jù)拼接 
  14.     pos += chunkNumLen+len('\r\n')+chunkLen+len('\r\n'
  15.     //同時(shí)pos位置向后移動(dòng) 
  16.  
  17. return unchunked 
  18. //此時(shí)處理后unchunked就是普通的壓縮數(shù)據(jù),可以用zlib解壓函數(shù)進(jìn)行解壓  

實(shí)際中,我們會(huì)同時(shí)遇到既時(shí) chunked 又是壓縮數(shù)據(jù)的響應(yīng),這個(gè)時(shí)候處理的思路應(yīng)該是:先處理 chunked,在處理壓縮數(shù)據(jù),順序不能反。

MultiPart 數(shù)據(jù)

MultiPart 的本質(zhì)就是 Post 請(qǐng)求,MultiPart出現(xiàn)在請(qǐng)求中,用來對(duì)一些文件(圖片或文檔)進(jìn)行處理,在請(qǐng)求頭中出現(xiàn) Content-Type: multipart/form-data; boundary=::287032381131322 則表示為 MultiPart 格式數(shù)據(jù)包,下面這個(gè)是 multipart 數(shù)據(jù)包格式:

  1. POST /cgi-bin/qtest HTTP/1.1 
  2. Host: aram 
  3. User-Agent: Mozilla/5.0 Gecko/2009042316 Firefox/3.0.10 
  4. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
  5. Accept-Language: en-us,en;q=0.5 
  6. Accept-Encoding: gzip,deflate 
  7. Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 
  8. Keep-Alive: 300 
  9. Connection: keep-alive 
  10. Referer: http://aram/~martind/banner.htm 
  11. Content-Type: multipart/form-data; boundary=::287032381131322 
  12. Content-Length: 514 
  13.  
  14. --::287032381131322 
  15. Content-Disposition: form-data; name="datafile1"; filename="r.gif" 
  16. Content-Type: image/gif 
  17.  
  18. GIF87a.............,...........D..; 
  19. --::287032381131322 
  20. Content-Disposition: form-data; name="datafile2"; filename="g.gif" 
  21. Content-Type: image/gif 
  22.  
  23. GIF87a.............,...........D..; 
  24. --::287032381131322 
  25. Content-Disposition: form-data; name="datafile3"; filename="b.gif" 
  26. Content-Type: image/gif 
  27.  
  28. GIF87a.............,...........D..; 
  29. --::287032381131322—  

http 協(xié)議本身的原始方法不支持 multipart/form-data 請(qǐng)求,那這個(gè)請(qǐng)求自然就是由這些原始的方法演變而來的,具體如何演變且看下文:

  1. multipart/form-data 的基礎(chǔ)方法是 post,也就是說是由 post 方法來組合實(shí)現(xiàn)的
  2. multipart/form-data 與 post 方法的不同之處:請(qǐng)求頭,請(qǐng)求體。
  3. multipart/form-data 的請(qǐng)求頭必須包含一個(gè)特殊的頭信息:Content-Type,且其值也必須規(guī)定為 multipart/form-data,同時(shí)還需要規(guī)定一個(gè)內(nèi)容分割符用于分割請(qǐng)求體中的多個(gè) post 內(nèi)容,如文件內(nèi)容和文本內(nèi)容自然需要分割,不然接收方就無法正常解析和還原這個(gè)文件。具體的頭信息如:Content-Type: multipart/form-data; boundary=${bound},${bound} 代表分割符,可以任意規(guī)定,但為了避免和正常文本重復(fù),盡量使用復(fù)雜一點(diǎn)的內(nèi)容,如::287032381131322
  4. multipart/form-data 的請(qǐng)求體也是一個(gè)字符串,不過和 post 的請(qǐng)求體不同的是它的構(gòu)造方式,post 是簡(jiǎn)單的 name=value 值連接,而 multipart/form-data 則是添加了分隔符等內(nèi)容的構(gòu)造體。

維基百科上關(guān)于 multipart 的介紹。

multipart 的數(shù)據(jù)格式有一定的特點(diǎn),首先是頭部規(guī)定了一個(gè) ${bound},上面那個(gè)例子中的 ${bound} 為 ::287032381131322,由多個(gè)內(nèi)容相同的塊組成,每個(gè)塊的格式以--加 ${bound} 開始的,然后是該部分內(nèi)容的描述信息,然后一個(gè)\r\n,然后是描述信息的具體內(nèi)容。如果傳送的內(nèi)容是一個(gè)文件的話,那么還會(huì)包含文件名信息,以及文件內(nèi)容的類型。

小結(jié),要發(fā)送一個(gè) multipart/form-data 的請(qǐng)求,需要定義一個(gè)自己的 ${bound} ,按照格式來發(fā)請(qǐng)求就好,對(duì)于 multipart 的數(shù)據(jù)格式并沒有過多介紹,感覺和 chunked 很類似,不難理解。

總結(jié)

本文介紹的三種數(shù)據(jù)格式,都比較基礎(chǔ),一些框架自動(dòng)把它們處理,比如爬蟲。還有圖像上傳,對(duì)于 multipart/data 格式的請(qǐng)求頭,了解一些概念性的東西也非常有意思。共勉。

參考全列在文章中了

責(zé)任編輯:龐桂玉 來源: segmentfault
相關(guān)推薦

2021-11-08 09:33:07

JS 字符串數(shù)據(jù)類型

2020-04-02 15:37:58

數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)

2024-03-29 13:17:03

Docker數(shù)據(jù)卷Volume

2020-12-28 10:35:38

前端數(shù)據(jù)技術(shù)

2019-01-08 10:29:12

BeautifulSoPython第三庫

2019-11-12 14:18:56

PythonWord設(shè)計(jì)

2017-12-07 15:47:25

2020-02-28 14:05:00

Linuxshell命令

2012-09-29 09:22:24

.NETGC內(nèi)存分配

2012-09-29 10:29:56

.Net內(nèi)存分配繼承

2017-12-07 15:28:36

2023-09-19 08:01:33

數(shù)據(jù)格式化程序

2024-11-26 07:47:41

2015-10-27 10:22:47

Html5API調(diào)用

2021-10-29 08:44:22

推拉機(jī)制面試broker

2011-11-30 09:09:13

王濤Windows Pho移動(dòng)開發(fā)

2015-06-29 09:40:10

Rails新特性

2017-10-11 15:50:18

光纖通信傳輸

2021-03-03 00:01:30

Redis數(shù)據(jù)結(jié)雙向鏈表

2015-07-23 10:37:13

Linux命令
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)