本文為大家介紹了iOS開(kāi)發(fā)ASIHTTPRequest下載數(shù)據(jù)的內(nèi)容，其中包括設(shè)定將服務(wù)器響應(yīng)數(shù)據(jù)直接下載到文件，處理收到的服務(wù)器響應(yīng)數(shù)據(jù)，PUT請(qǐng)求、獲取HTTP狀態(tài)碼,讀取響應(yīng)頭,處理文本編碼,處理重定向等等內(nèi)容。

將服務(wù)器響應(yīng)數(shù)據(jù)直接下載到文件

如果你請(qǐng)求的資源很大，你可以直接將數(shù)據(jù)下載到文件中來(lái)節(jié)省內(nèi)存。此時(shí)，ASIHTTPRequest將不會(huì)一次將返回?cái)?shù)據(jù)全部保持在內(nèi)存中。

當(dāng)我們把數(shù)據(jù)下載到downloadDestinationPath時(shí)，數(shù)據(jù)將首先被存在臨時(shí)文件中。此時(shí)文件的路徑名存儲(chǔ)在 temporaryFileDownloadPath中(夢(mèng)維：如果不設(shè)置這個(gè)值，會(huì)自動(dòng)生成一個(gè)文件名，在模擬器中，文件被創(chuàng)建在$TMPDIR中)。

ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; 
[request setDownloadDestinationPath:@"/Users/ben/Desktop/my_file.txt"]; 

當(dāng)request完成時(shí)，會(huì)發(fā)生下面兩件事之一：

如果數(shù)據(jù)是被壓縮過(guò)（gzip）的，那么這個(gè)壓縮過(guò)的文件將被解壓到downloadDestinationPath，臨時(shí)文件會(huì)被刪除。

如果數(shù)據(jù)未被壓縮，那么這個(gè)文件將被移動(dòng)到downloadDestinationPath，沖突解決方式是：覆蓋已存在的文件。

注意：如果服務(wù)器響應(yīng)數(shù)據(jù)為空，那么文件是不會(huì)被創(chuàng)建的。如果你的返回?cái)?shù)據(jù)可能為空，那么你應(yīng)該先檢查下載文件是否存在，再對(duì)文件進(jìn)行操作。

處理收到的服務(wù)器響應(yīng)數(shù)據(jù)

如果你想處理服務(wù)器響應(yīng)的數(shù)據(jù)（例如，你想使用流解析器對(duì)正在下載的數(shù)據(jù)流進(jìn)行處理），你應(yīng)該實(shí)現(xiàn)代理函數(shù) request:didReceiveData:。注意如果你這么做了，ASIHTTPRequest將不會(huì)填充responseData到內(nèi)存，也不會(huì)將數(shù)據(jù)寫入文件（downloadDestinationPath ）——你必須自己搞定這兩件事（之一）。 

獲取HTTP狀態(tài)碼

ASIHTTPRequest并不對(duì)HTTP狀態(tài)碼做任何處理（除了重定向和授權(quán)狀態(tài)碼，下面會(huì)介紹到），所以你必須自己檢查狀態(tài)值并正確處理。

ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; 
[request startSynchronous]; 
int statusCode = [request responseStatusCode]; 
NSString *statusMessage = [request responseStatusMessage]; 

讀取響應(yīng)頭

ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; 
[request startSynchronous]; 
NSString *poweredBy = [[request responseHeaders] objectForKey:@"X-Powered-By"]; 
NSString *contentType = [[request responseHeaders] objectForKey:@"Content-Type"]; 

處理文本編碼

ASIHTTPRequest會(huì)試圖讀取返回?cái)?shù)據(jù)的編碼信息（Content-Type頭信息）。如果它發(fā)現(xiàn)了編碼信息，它會(huì)將編碼信息設(shè)定為合適的 NSStringEncoding.如果它沒(méi)有找到編碼信息，它會(huì)將編碼設(shè)定為默認(rèn)編碼（NSISOLatin1StringEncoding）。

當(dāng)你調(diào)用[request responseString]，ASIHTTPRequest會(huì)嘗試以responseEncoding將返回的Data轉(zhuǎn)換為NSString。

處理重定向

當(dāng)遇到以下HTTP狀態(tài)碼之一時(shí)，ASIHTTPRequest會(huì)自動(dòng)重定向到新的URL：

• 301 Moved Permanently
• 302 Found
• 303 See Other

當(dāng)發(fā)生重定向時(shí)，響應(yīng)數(shù)據(jù)的值（responseHeaders，responseCookies，responseData，responseString等等）將會(huì)映射為最終地址的相應(yīng)返回?cái)?shù)據(jù)。

當(dāng)URL發(fā)生循環(huán)重定向時(shí)，設(shè)置在這個(gè)URL上的cookie將被儲(chǔ)存到全局域中，并在適當(dāng)?shù)臅r(shí)候隨重定向的請(qǐng)求發(fā)送到服務(wù)器。

Cookies set on any of the urls encountered during a redirection cycle will be stored in the global cookie store, and will be represented to the server on the redirected request when appropriate.

你可以關(guān)閉自動(dòng)重定向：將shouldRedirect設(shè)置為NO。

默認(rèn)情況下，自動(dòng)重定向會(huì)使用GET請(qǐng)求（請(qǐng)求體為空）。這種行為符合大多數(shù)瀏覽器的行為，但是HTTP spec規(guī)定301和302重定向必須使用原有方法。

要對(duì)301、302重定向使用原方法（包含請(qǐng)求體），在發(fā)起請(qǐng)求之前，設(shè)置shouldUseRFC2616RedirectBehaviour 為YES。