簡(jiǎn)介面向PowerBuilder PB-183版本開發(fā)者的HTTP下載示例包聚焦C/S程序中通過內(nèi)置Internet Toolkit或第三方庫(kù)實(shí)現(xiàn)文件與圖片的遠(yuǎn)程獲取覆蓋狀態(tài)碼校驗(yàn)、超時(shí)設(shè)置、請(qǐng)求頭配置、異常處理、下載進(jìn)度與本地落盤等完整鏈路。壓縮包共23個(gè)文件大小僅50KB包含pbt/pbl/pbw工程與源碼、pbd/exe編譯產(chǎn)物、cs輔助腳本、config配置、log日志等其中工程與源碼便于直接打開修改exe可快速驗(yàn)證效果日志則記錄了構(gòu)建與遷移過程整體目錄結(jié)構(gòu)清晰。已有674人瀏覽學(xué)習(xí)。借助該示例可掌握HTTPClient對(duì)象與DLL調(diào)用兩種下載方式理解將響應(yīng)流保存為本地文件或直接加載到Image控件顯示圖片的差異并能參考其錯(cuò)誤處理和斷點(diǎn)續(xù)傳等擴(kuò)展思路適合需要為PB應(yīng)用增添在線資源獲取能力的初中級(jí)開發(fā)人員直接借鑒與二次開發(fā)。1. PowerBuilder 的 HTTP 下載為什么一個(gè)老需求能難住一批人先說(shuō)明一下標(biāo)題里的 PB 是 PowerBuilder不是 TensorFlow 的 pb 模型文件。搜索“PB下載HTTP文件”“pb http下載圖片”的人十有八九是在維護(hù)老系統(tǒng)EAS 上跑著 PB 9 或 PB 12.5 寫的數(shù)據(jù)采集程序要從內(nèi)網(wǎng)服務(wù)器拉報(bào)表、拉圖片、拉加密包或者對(duì)接一個(gè)只給 HTTP 接口的新平臺(tái)。PowerBuilder 這套老框架里沒有內(nèi)置的 HttpClient很多版本連 URLDownloadToFile 都調(diào)不明白于是大家只能去網(wǎng)上找現(xiàn)成的 rar 工具包比如標(biāo)題里這種“PB-183下載”的資源包。這類包解壓后通常是幾個(gè) DLL 加一段示例代碼版本不匹配時(shí)照樣跑不起來(lái)。這篇把一條我自己驗(yàn)證過、能直接照抄的路徑講透先用 WinHttp 組件做 OLE 調(diào)用配合 ADODB.Stream 處理二進(jìn)制把文本、圖片、壓縮包的下載都跑通再把超時(shí)、文件名、HTTPS 證書這些高頻坑一個(gè)個(gè)排掉。適合正在維護(hù)老 PB 項(xiàng)目、或者要把 PowerBuilder 接進(jìn) HTTP 接口體系的工程師照步驟走完你可以在自己代碼里寫一個(gè)穩(wěn)定的下載函數(shù)不再依賴來(lái)路不明的第三方包。2. 三條路先想清楚PB 里調(diào) HTTP 的選型決定了你后面少踩多少坑2.1 OLE 組件、API 直調(diào)、.NET 封裝各自適用什么人PowerBuilder 里做 HTTP 下載常見做法無(wú)非三條路用 OLEObject 調(diào) WinHttp 組件、用外部函數(shù)直接聲明 WinHTTP API、以及 PB 12.2 以上調(diào)用 .NET WebClient。我給老項(xiàng)目做技術(shù)方案時(shí)默認(rèn)優(yōu)先 OLE 方案理由很直白代碼量少運(yùn)行依賴少Windows 7 及以上系統(tǒng)都自帶 WinHttp.dll不需要安裝額外運(yùn)行時(shí)。直接聲明 WinHTTP API 的路線適合對(duì)請(qǐng)求過程控制要求極高的場(chǎng)景比如要自己處理連接復(fù)用、要拿到 TLS 握手細(xì)節(jié)、要做底層流量統(tǒng)計(jì)。代價(jià)是代碼量大PB 里聲明 ref char、ref long 這類參數(shù)很容易出類型錯(cuò)配調(diào)試起來(lái)像在跟黑匣子搏斗。.NET WebClient 的方案在新版本 PB 里確實(shí)一行代碼就能下載但有個(gè)現(xiàn)實(shí)問題老補(bǔ)丁包環(huán)境下運(yùn)行時(shí)加載程序集經(jīng)常失敗。我手頭一個(gè)客戶環(huán)境就是 PB-183 這種老 build跑 WebClient 時(shí)斷時(shí)續(xù)地報(bào) System.IO.FileNotFoundException最后統(tǒng)一退回 WinHttp世界安靜了。所以選型結(jié)論不復(fù)雜如果你的 PB 版本在 9 到 12.5 之間直接走 OLE WinHttp如果版本新、運(yùn)行環(huán)境干凈、且你能確認(rèn) .NET 運(yùn)行時(shí)沒問題再考慮 WebClient。新手別一上來(lái)就抄 API 直調(diào)的代碼很容易被指針和緩沖區(qū)繞暈。2.2 為什么不推薦 MSXML2.XMLHTTP以及 WinHttp 的優(yōu)勢(shì)在搜索“pb http”的時(shí)候很多老帖會(huì)推薦用 MSXML2.XMLHTTP 組件。這個(gè)組件確實(shí)能做 HTTP 請(qǐng)求但實(shí)際用下來(lái)有兩個(gè)煩心事第一MSXML 在系統(tǒng)里有 3.0、4.0、6.0 多個(gè)版本共存Office 或系統(tǒng)更新可能改變默認(rèn)版本代碼里寫死 “MSXML2.XMLHTTP” 可能在升級(jí)后連不上第二有些精簡(jiǎn)版系統(tǒng)或離線內(nèi)網(wǎng)機(jī)器沒有正確注冊(cè) MSXMLConnectToNewObject 直接返回 -1。WinHttp.WinHttpRequest.5.1 沒這么多幺蛾子。它從 Windows 7 開始就是系統(tǒng)組件不依賴 Office也不會(huì)被其他軟件隨意改版本行為上接近 WinINet但更適合服務(wù)端和后臺(tái)任務(wù)重定向、代理、HTTPS 證書都有獨(dú)立可控的屬性。用它做 PB 下載遇到最多的問題反而是 PB 自身對(duì) VARIANT 字節(jié)數(shù)組的處理限制這個(gè)下文細(xì)說(shuō)。順帶提一句很多朋友搜索時(shí)看到“winform之http客戶端實(shí)現(xiàn)”其實(shí)思路是相通的不管外面包的是 WinForm 還是 PB底層都是同一個(gè) WinHTTP 協(xié)議棧理解了組件調(diào)用方式換語(yǔ)言只是換殼。2.3 動(dòng)手之前先分清兩件事文本和二進(jìn)制、GET 和 POST這是很多人翻車的第一步。HTTP 下載文本和下載圖片、壓縮包看似都是“發(fā)請(qǐng)求、收數(shù)據(jù)”代碼結(jié)構(gòu)卻完全不同。文本可以走 ResponseText拿到的是字符串圖片和 zip 必須走 ResponseBody拿到的是字節(jié)數(shù)組PB 里不能直接把 ResponseBody 賦給 blob 變量常見做法是把它作為參數(shù)傳給 ADODB.Stream 的 Write 方法由 Stream 完成二進(jìn)制落地。這個(gè)坑在下面章節(jié)的具體代碼里會(huì)反復(fù)強(qiáng)調(diào)。另外要分清楚請(qǐng)求方法。下載文件 90% 是 GET但有些內(nèi)部系統(tǒng)把下載地址包裝成了 POST 接口參數(shù)放在請(qǐng)求體里響應(yīng)體里返回文件流。WinHttp 的 Open 方法第一個(gè)參數(shù)就是方法名寫 GET 還是 POST會(huì)直接影響服務(wù)端的處理邏輯。實(shí)現(xiàn)下載函數(shù)時(shí)最好把請(qǐng)求方法也做成參數(shù)別寫死。3. 用 WinHttp 跑通最小下載文本文件、圖片的完整代碼3.1 先驗(yàn)證組件ConnectToNewObject 的返回值不是擺設(shè)寫代碼之前先確認(rèn)運(yùn)行環(huán)境能創(chuàng)建 WinHttp 對(duì)象。這個(gè)檢查不是走形式我遇到過不止一次程序在一臺(tái)機(jī)器上跑得好好的換到離線內(nèi)網(wǎng)機(jī)就報(bào)錯(cuò)排查半天才發(fā)現(xiàn)是組件創(chuàng)建失敗。下面的代碼放在下載函數(shù)入口處作為第一道防線// 創(chuàng)建 OLEObject 對(duì)象 OLEObject lole_http lole_http CREATE OLEObject // 連接 WinHttp 組件返回值為 0 表示成功 IF lole_http.ConnectToNewObject(WinHttp.WinHttpRequest.5.1) 0 THEN DESTROY lole_http MessageBox(提示, 當(dāng)前系統(tǒng)不支持 WinHttp 組件無(wú)法執(zhí)行下載) RETURN false END IF這里的關(guān)鍵是 ConnectToNewObject 的返回值0 代表成功非 0 代表創(chuàng)建失敗。失敗可能的原因包括系統(tǒng)精簡(jiǎn)掉了 WinHttp.dll、組件未注冊(cè)、或者當(dāng)前進(jìn)程是 64 位而組件注冊(cè)在 32 位分支里。判斷失敗后要立即釋放對(duì)象避免內(nèi)存占用。這一步過了后面的事才談得上。3.2 文本文件下載ResponseText 到 UTF-8 文件文本下載的最小完整函數(shù)如下方代碼。這個(gè)函數(shù)接收 URL 和保存路徑成功返回文件內(nèi)容字符串失敗返回空串// 函數(shù)of_download_text // 入?yún)s_url 完整HTTP地址as_save_path 本地保存路徑 // 返回文件內(nèi)容字符串失敗為空串 string ls_text OLEObject lole_http, lole_stream lole_http CREATE OLEObject IF lole_http.ConnectToNewObject(WinHttp.WinHttpRequest.5.1) 0 THEN DESTROY lole_http RETURN END IF // SetTimeouts 四個(gè)參數(shù)依次是解析超時(shí)、連接超時(shí)、發(fā)送超時(shí)、接收超時(shí)單位毫秒 lole_http.SetTimeouts(5000, 5000, 10000, 30000) lole_http.Open(GET, as_url, false) // 部分服務(wù)器對(duì)空 User-Agent 直接返回 403這里偽裝成瀏覽器 lole_http.SetRequestHeader(User-Agent, Mozilla/5.0) lole_http.Send() // Status 為 HTTP 狀態(tài)碼200 才繼續(xù)302 由 WinHttp 自動(dòng)跟隨 IF lole_http.Status 200 THEN DESTROY lole_http RETURN END IF // 取文本內(nèi)容 ls_text lole_http.ResponseText DESTROY lole_http // 保存為 UTF-8 文件用 ADODB.Stream 保持編碼一致 lole_stream CREATE OLEObject IF lole_stream.ConnectToNewObject(ADODB.Stream) 0 THEN lole_stream.Type 2 // adTypeText文本模式 lole_stream.Charset UTF-8 // 指定編碼 lole_stream.Open() lole_stream.WriteText(ls_text) lole_stream.SaveToFile(as_save_path, 2) // 2 adSaveCreateOverWrite lole_stream.Close() END IF DESTROY lole_stream RETURN ls_text邏輯說(shuō)明很直接先創(chuàng)建 WinHttp設(shè)置超時(shí)發(fā) GET校驗(yàn)狀態(tài)碼再取文本。這里要注意兩個(gè)參數(shù)SetTimeouts 的第二個(gè)值 5000 是連接超時(shí)如果服務(wù)器在內(nèi)網(wǎng)但路由不通這個(gè)值決定了程序卡多久才報(bào)錯(cuò)SaveToFile 的第二個(gè)參數(shù) 2 表示覆蓋寫如果你希望文件已存在時(shí)不覆蓋要改成 1adSaveCreateNotExist。還有一個(gè)容易忽略的點(diǎn)直接 FileWrite 保存文本會(huì)丟失編碼信息尤其服務(wù)端返回 UTF-8 而 PB 字符串內(nèi)部是 ANSI 時(shí)寫出來(lái)的文件在瀏覽器里打開就是亂碼。用 ADODB.Stream 指定 Charset 再落盤是目前我試過最穩(wěn)的做法。3.3 圖片下載ResponseBody 配合 ADODB.Stream 落盤下載圖片或二進(jìn)制文件的函數(shù)如下。核心差異在第 20 行附近不再取 ResponseText而是把 ResponseBody 交給 Stream 的 Write 方法// 函數(shù)of_download_binary // 入?yún)s_url 文件地址as_save_path 保存路徑 // 返回boolean是否成功 boolean lb_ok OLEObject lole_http, lole_stream long ll_status lole_http CREATE OLEObject lb_ok (lole_http.ConnectToNewObject(WinHttp.WinHttpRequest.5.1) 0) IF NOT lb_ok THEN DESTROY lole_http RETURN false END IF lole_http.SetTimeouts(5000, 5000, 10000, 60000) lole_http.Open(GET, as_url, false) lole_http.SetRequestHeader(User-Agent, Mozilla/5.0) lole_http.Send() ll_status lole_http.Status IF ll_status 200 THEN DESTROY lole_http RETURN false END IF lole_stream CREATE OLEObject lb_ok (lole_stream.ConnectToNewObject(ADODB.Stream) 0) IF NOT lb_ok THEN DESTROY lole_http DESTROY lole_stream RETURN false END IF // Type1 表示二進(jìn)制模式Mode3 表示可讀可寫 lole_stream.Type 1 lole_stream.Mode 3 lole_stream.Open() // ResponseBody 是 VARIANT 字節(jié)數(shù)組不要賦給 blob直接交給 Stream lole_stream.Write(lole_http.ResponseBody) // 保存到文件2 表示覆蓋已有文件 lole_stream.SaveToFile(as_save_path, 2) lole_stream.Close() DESTROY lole_http DESTROY lole_stream RETURN true參數(shù)說(shuō)明lole_stream.Type 1 是關(guān)鍵這是二進(jìn)制流如果漏了這句圖片寫出來(lái)會(huì)變成文本內(nèi)容。Mode 3 表示讀和寫都允許有的環(huán)境默認(rèn) Mode 不對(duì)寫入時(shí)會(huì)報(bào)“對(duì)象關(guān)閉時(shí)不允許操作”。ResponseBody 的處理邏輯要重點(diǎn)理解PB 的 OLEObject 對(duì) VARIANT 類型的字節(jié)數(shù)組支持有限直接寫blob lblb lole_http.ResponseBody在 PB 9 到 12.5 上大概率報(bào)類型轉(zhuǎn)換錯(cuò)誤。繞開的方法是讓 Stream 的 Write 方法來(lái)接收它本身就是設(shè)計(jì)來(lái)吃 VARIANT 的。圖片下載成功后建議立刻做一次文件頭校驗(yàn)比如 JPEG 的 FF D8 FFPNG 的 89 50 4E 47。這個(gè)校驗(yàn)可以幫助區(qū)分“下載成功”和“下載成功但是個(gè)錯(cuò)誤頁(yè)”后面避坑章會(huì)細(xì)說(shuō)。4. 下載場(chǎng)景里最容易看走眼的細(xì)節(jié)ContentType、文件名和超時(shí)4.1 ContentType 不等于文件類型HTTP 下載的響應(yīng)頭別亂信很多人在寫下載邏輯時(shí)喜歡先讀 ContentType 再?zèng)Q定怎么保存比如看到image/jpeg就加 .jpg 后綴。這個(gè)思路在瀏覽器里沒問題在 PB 下載場(chǎng)景里經(jīng)常翻車。原因很簡(jiǎn)單第一部分內(nèi)網(wǎng)服務(wù)器是拿靜態(tài)文件服務(wù)軟件搭的會(huì)把所有文件都標(biāo)成application/octet-stream你根本從 ContentType 判斷不出真實(shí)類型第二有些接口是程序生成的下載流比如報(bào)表系統(tǒng)導(dǎo)出 PDF 時(shí)ContentType 寫的是text/html但內(nèi)容實(shí)際上是個(gè) PDF 二進(jìn)制流。正確做法是不要依賴 ContentType 決定文件類型而是依賴 URL 后綴和 Content-Disposition 頭的 filename 字段。ContentType 可以打印到日志里做參考但不能作為唯一判斷依據(jù)。在 PB 里獲取響應(yīng)頭的代碼是string ls_content_type ls_content_type lole_http.GetResponseHeader(Content-Type) // 只做日志記錄用不要據(jù)此判斷文件格式另一點(diǎn)要注意如果服務(wù)端返回的是application/json; charsetutf-8這種帶參數(shù)的 ContentTypePB 字符串解析時(shí)別只找application/json用 Pos 函數(shù)匹配到;之前的部分再判斷。4.2 文件名怎么取Content-Disposition 和 URL 的兜底解析下載保存到本地時(shí)文件名來(lái)源有三個(gè)優(yōu)先級(jí)Content-Disposition 的 filename 字段最權(quán)威其次 URL 最后一段最后是調(diào)用方顯式傳入。Content-Disposition 常見格式有兩種attachment; filenamereport.pdf attachment; filename*UTF-8%E6%9C%88%E6%8A%A5.pdf第一種是普通 ASCII 文件名第二種是 RFC 5987 的編碼格式其中%E6%9C%88%E6%8A%A5是 UTF-8 編碼后的“月報(bào)”。PB 里沒有內(nèi)置的 URLDecode 函數(shù)需要自己寫解析先用Pos找到filename*再找到之后的內(nèi)容然后循環(huán)把%xx轉(zhuǎn)成字符。偽代碼如下// 取 Content-Disposition 頭 string ls_disposition ls_disposition lole_http.GetResponseHeader(Content-Disposition) // 若包含 filename*取單引號(hào)后面的部分 IF Pos(ls_disposition, filename*) 0 THEN ls_disposition Mid(ls_disposition, Pos(ls_disposition, ) 2) // 此處還需要將 %E6%9C%88 之類的編碼轉(zhuǎn)成真實(shí)字符 END IF實(shí)操里有個(gè)捷徑如果下載地址是內(nèi)網(wǎng)系統(tǒng)生成的文件URL 里通常已經(jīng)帶了原始文件名比如/download?id123namereport.pdf直接用正則從 URL 截取 name 參數(shù)最省事。我的習(xí)慣是優(yōu)先取 Content-Disposition取不到就取 URL 截取都取不到才落到一層默認(rèn)命名規(guī)則。文件名解析失敗時(shí)千萬(wàn)別用時(shí)間戳命名否則用戶根本不知道下載的是什么。4.3 超時(shí)參數(shù)怎么設(shè)以及 HTTP 連接復(fù)用為什么影響下載速度SetTimeouts 四個(gè)參數(shù)里接收超時(shí)是下載大文件的關(guān)鍵。默認(rèn) 30 秒對(duì)幾 MB 的圖片夠用下載幾十 MB 的壓縮包時(shí)如果接收超時(shí)設(shè)得太短下載中途會(huì)報(bào) 12002 超時(shí)錯(cuò)誤。我的經(jīng)驗(yàn)值文本類接口連接超時(shí) 5 秒、接收超時(shí) 30 秒圖片和壓縮包下載接收超時(shí)至少放寬到 60 秒甚至 120 秒。網(wǎng)絡(luò)不好時(shí)單位時(shí)間下載量小超時(shí)時(shí)間要按文件大小除以最低期望速率來(lái)估算。HTTP 連接復(fù)用是另一個(gè)影響下載速度的隱藏點(diǎn)。WinHttp.WinHttpRequest 每次新建組件實(shí)例、執(zhí)行完 Send 后連接默認(rèn)是斷開的。如果循環(huán)下載 100 個(gè)小文件每次都重新創(chuàng)建對(duì)象抓包看就是持續(xù)不斷的三次握手和揮手整體時(shí)間會(huì)被連接建立耗掉一大截。優(yōu)化做法是把 WinHttp 對(duì)象做成窗口級(jí)實(shí)例在 Main 窗口定義的實(shí)例變量循環(huán)里重復(fù)使用只改變 URL減少連接重建的開銷。能顯著改善批量下載場(chǎng)景的耗時(shí)特別是下載小圖標(biāo)、小附件這種高頻低數(shù)據(jù)量的任務(wù)。5. 這幾個(gè)坑我基本都踩過PB 下載 HTTP 文件的常見問題與排查5.1 現(xiàn)象ConnectToNewObject 返回 -1WinHttp 組件在離線內(nèi)網(wǎng)機(jī)上失效程序在開發(fā)機(jī)正常部署到客戶內(nèi)網(wǎng)機(jī)器后第一次調(diào)用下載就彈“當(dāng)前系統(tǒng)不支持 WinHttp 組件”。原因多半不是系統(tǒng)精簡(jiǎn)掉了 WinHttp而是目標(biāo)機(jī)器是 Windows Server Core 或國(guó)產(chǎn)化系統(tǒng)定制版缺少組件注冊(cè)信息。解決先檢查C:\Windows\SysWOW64\winhttp.dll是否存在確認(rèn)文件在的情況下不要嘗試regsvr32 winhttp.dllWinHttp 不是可注冊(cè)的 COM 組件。更快的兜底方案是改用 MSXML6.0 創(chuàng)建對(duì)象把組件名換成MSXML2.ServerXMLHTTP.6.0代碼其余部分不用動(dòng)。我一般會(huì)在公共函數(shù)里做兩層降級(jí)先連 WinHttp失敗自動(dòng)嘗試 ServerXMLHTTP再不行才報(bào)錯(cuò)。5.2 現(xiàn)象圖片下載下來(lái)無(wú)法打開文件大小比瀏覽器里看到的大用瀏覽器訪問同一張圖片只有 20KBPB 下載保存后卻有 80KB而且畫圖工具打不開。原因大概率是服務(wù)端返回了錯(cuò)誤頁(yè)或登錄跳轉(zhuǎn)頁(yè)HTTP 狀態(tài)碼雖然 200但內(nèi)容不是圖片。另一個(gè)常見情況是把 ResponseText 硬轉(zhuǎn)成 blob 寫文件導(dǎo)致 UTF-8 文本被按 ANSI 存儲(chǔ)文件字節(jié)數(shù)膨脹。解決下載后立刻比對(duì) Content-Length 與本地文件大小不相等就刪除重下同時(shí)對(duì)文件頭做魔數(shù)校驗(yàn)JPEG 應(yīng)以FF D8 FF開頭。我慣用的寫法是下載后讀文件前兩個(gè)字節(jié)用FileRead或者 API 讀入判斷魔數(shù)。校驗(yàn)失敗時(shí)建議打印響應(yīng)頭全文到日志能快速看出服務(wù)端返回的到底是什么。5.3 現(xiàn)象HTTPS 地址報(bào) 12175 證書錯(cuò)誤而瀏覽器能正常打開HTTP 下載正常換 HTTPS 就報(bào) 12175 或 12038 證書錯(cuò)誤。原因通常是服務(wù)器證書鏈不完整或者內(nèi)部系統(tǒng)用自簽名證書WinHttp 組件默認(rèn)要求完整證書鏈校驗(yàn)不信任自簽名證書。處理時(shí)不要為了省事關(guān)閉證書校驗(yàn)尤其是生產(chǎn)環(huán)境。正確的做法有兩步第一步把服務(wù)器根證書導(dǎo)入 Windows 受信任證書存儲(chǔ)區(qū)用certmgr.msc操作這個(gè)最干凈第二步如果系統(tǒng)里有多級(jí)證書鏈且中間證書缺失找網(wǎng)絡(luò)管理員補(bǔ)全。只在聯(lián)調(diào)階段可以臨時(shí)用 WinHttp.SetOption 調(diào)整安全選項(xiàng)跳過校驗(yàn)上線前必須改回。5.4 現(xiàn)象中文文件名保存后全是亂碼保存文件名里帶中文落盤后變成“錕斤拷”或問號(hào)。原因在 URL 編碼和本地編碼不一致HTTP 路徑中的中文通常按 UTF-8 編碼PB 字符串內(nèi)部是 GBK 或 ANSI直接拼接后文件系統(tǒng)按 ANSI 解析亂碼是必然。解決思路文件名拆成編碼前和解碼后兩步URL 里的%xx先還原成 UTF-8 字節(jié)再轉(zhuǎn)成 GBKContent-Disposition 里的filename*UTF-8也按同樣方式處理。轉(zhuǎn)碼函數(shù)在 PB 里可以利用System.Text.Encoding相關(guān)調(diào)用老版本 PB 則借助 API 或 ADODB.Stream 做中轉(zhuǎn)。我的習(xí)慣是盡量在服務(wù)端把文件名改成 ASCII實(shí)在要支持中文文件名解析邏輯里就做兩層兼容先試 UTF-8 解碼失敗再試 GBK。5.5 現(xiàn)象大批量下載越跑越慢抓包發(fā)現(xiàn)連接一直在重建下載 100 個(gè)文件時(shí)前 10 個(gè)速度正常后面每個(gè)都要等 1 到 2 秒才開始。用抓包工具看每個(gè)文件請(qǐng)求前都有完整的 TCP 握手和揮手。原因就是前面講的連接復(fù)用沒做每次下載都CREATE新的 OLEObject下載完就DESTROY連接自然無(wú)法復(fù)用。解決把 WinHttp 對(duì)象提升為窗口或應(yīng)用的實(shí)例變量下載循環(huán)里只調(diào)用Open和Send不要反復(fù)創(chuàng)建銷毀如果目標(biāo)服務(wù)器支持 HTTP/1.1 keep-alive這樣做了之后批量下載耗時(shí)能下降一半。另一個(gè)關(guān)聯(lián)問題并發(fā)下載時(shí)開太多線程會(huì)觸發(fā)服務(wù)器連接數(shù)限制表現(xiàn)為部分請(qǐng)求返回 503建議控制并發(fā)數(shù)在 5 以內(nèi)。6. 再進(jìn)一步斷點(diǎn)續(xù)傳、完整性校驗(yàn)和驗(yàn)證下載結(jié)果的三個(gè)手段6.1 Range 頭實(shí)現(xiàn)斷點(diǎn)續(xù)傳的代碼骨架大文件下載中斷后重新下載整個(gè)文件浪費(fèi)帶寬。WinHttp 支持 Range 頭可以讓服務(wù)端只返回文件剩余部分// in 參數(shù) ll_start 表示已下載的字節(jié)數(shù) lole_http.Open(GET, as_url, false) lole_http.SetRequestHeader(Range, bytes String(ll_start) -) lole_http.Send() // 服務(wù)端返回 206 Partial Content 才說(shuō)明續(xù)傳生效 IF lole_http.Status 206 THEN // 打開本地文件流把位置定位到末尾再寫入后續(xù)內(nèi)容 END IF這里注意兩點(diǎn)一是斷點(diǎn)續(xù)傳要配合文件追加寫入用 ADODB.Stream 打開文件后要調(diào)整 Position 到文件末尾二是服務(wù)端不支持 Range 時(shí)返回 200 和完整內(nèi)容代碼要有兜底邏輯直接覆蓋寫。6.2 用 Content-Length 校驗(yàn)下載完整性下載完成后從響應(yīng)頭取 Content-Length和本地文件實(shí)際大小對(duì)比。一致基本說(shuō)明數(shù)據(jù)完整如果不一致說(shuō)明傳輸中途出了問題但 WinHttp 的流式接口可能沒報(bào)錯(cuò)。校驗(yàn)邏輯放下載函數(shù)內(nèi)部失敗時(shí)自動(dòng)重試一次避免調(diào)用方在不知道的情況下拿到殘缺文件。6.3 收尾建議封裝、日志與抓包驗(yàn)證落地時(shí)把下載函數(shù)統(tǒng)一封裝成of_http_download(url, save_path, method, timeout, ref file_size)的結(jié)構(gòu)返回成功失敗之外把文件大小、狀態(tài)碼、耗時(shí)都填出來(lái)。日志里記錄 URL、HTTP 狀態(tài)碼、Content-Type、Content-Length、耗時(shí)這五個(gè)字段問題發(fā)生后基本不用猜。調(diào)通之后再用 Fiddler 或 Wireshark 抓一次包確認(rèn)請(qǐng)求頭里有預(yù)期的 User-Agent 和 Range響應(yīng)碼符合預(yù)期。多嘮叨一句我曾經(jīng)在下載函數(shù)里圖省事跳過校驗(yàn)結(jié)果生產(chǎn)環(huán)境把一份殘缺的 Excel 報(bào)表寫進(jìn)了業(yè)務(wù)庫(kù)事后排查了兩天才定位到是傳輸不完整。從那以后我的下載函數(shù)里永遠(yuǎn)把完整性和狀態(tài)碼校驗(yàn)放在第一步。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取