簡(jiǎn)介面向PowerBuilder PB-183版本開發(fā)者的HTTP下載示例包聚焦C/S程序中通過內(nèi)置Internet Toolkit或第三方庫實(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è)老需求能難住一批人先說明一下標(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í)照樣跑不起來。這篇把一條我自己驗(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ù)不再依賴來路不明的第三方包。2. 三條路先想清楚PB 里調(diào) HTTP 的選型決定了你后面少踩多少坑2.1 OLE 組件、API 直調(diào)、.NET 封裝各自適用什么人PowerBuilder 里做 HTTP 下載常見做法無非三條路用 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)試起來像在跟黑匣子搏斗。.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。新手別一上來就抄 API 直調(diào)的代碼很容易被指針和緩沖區(qū)繞暈。2.2 為什么不推薦 MSXML2.XMLHTTP以及 WinHttp 的優(yōu)勢(shì)在搜索“pb http”的時(shí)候很多老帖會(huì)推薦用 MSXML2.XMLHTTP 組件。這個(gè)組件確實(shí)能做 HTTP 請(qǐng)求但實(shí)際用下來有兩個(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ì)說。順帶提一句很多朋友搜索時(shí)看到“winform之http客戶端實(shí)現(xiàn)”其實(shí)思路是相通的不管外面包的是 WinForm 還是 PB底層都是同一個(gè) WinHTTP 協(xié)議棧理解了組件調(diào)用方式換語言只是換殼。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 組件無法執(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邏輯說明很直接先創(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í)寫出來的文件在瀏覽器里打開就是亂碼。用 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ù)說明lole_stream.Type 1 是關(guān)鍵這是二進(jìn)制流如果漏了這句圖片寫出來會(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 方法來接收它本身就是設(shè)計(jì)來吃 VARIANT 的。圖片下載成功后建議立刻做一次文件頭校驗(yàn)比如 JPEG 的 FF D8 FFPNG 的 89 50 4E 47。這個(gè)校驗(yàn)可以幫助區(qū)分“下載成功”和“下載成功但是個(gè)錯(cuò)誤頁”后面避坑章會(huì)細(xì)說。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í)文件名來源有三個(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í)千萬別用時(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í)間要按文件大小除以最低期望速率來估算。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)象圖片下載下來無法打開文件大小比瀏覽器里看到的大用瀏覽器訪問同一張圖片只有 20KBPB 下載保存后卻有 80KB而且畫圖工具打不開。原因大概率是服務(wù)端返回了錯(cuò)誤頁或登錄跳轉(zhuǎn)頁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連接自然無法復(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 才說明續(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ì)比。一致基本說明數(shù)據(jù)完整如果不一致說明傳輸中途出了問題但 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í)都填出來。日志里記錄 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ù)庫事后排查了兩天才定位到是傳輸不完整。從那以后我的下載函數(shù)里永遠(yuǎn)把完整性和狀態(tài)碼校驗(yàn)放在第一步。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取