简介MFC框架下实现HTTP/HTTPS上传的完整示例工程面向需要基于WinInet进行网络文件传输的C开发人员重点解决文件选择、服务器地址配置和上传进度展示等界面与协议衔接问题。压缩包共49个文件以头文件h、源文件cpp、Visual Studio工程文件sln/vcxproj为主另含可运行的exe及调试所需的pdb、idb等文件整体大小约73.09MB便于直接打开工程查看代码和运行效果。该资源已有567人学习代码中封装了PostFormData等关键类演示了MFC对话框下调用WinInet接口实现POST上传的流程包括SSL设置、请求构造、错误处理及UI更新适合作为学习MFC网络编程和HTTP协议在实际项目中落地的参考。1. 打开文件、填上服务器地址、点上传MFC里最朴素的HTTP上传工具怎么做做过Windows桌面工具的人多半遇到过这种需求生产线上把报表传回服务器、终端机把日志文件定时上送、或者给一个十年前的MFC老程序加一个“把导出文件发给中心”的功能。这个标题其实就是一套已经标准化了的需求——文件选择、服务器地址配置、HTTP/HTTPS上传三者合一落到MFC界面上。它解决的是“不让使用方记任何命令行、不装额外运行时双击就能把文件传到指定服务端”这件事适合做内部工具、工控机客户端、遗留系统集成。技术路线很成熟WinINet/WinHTTP是系统自带接口CFileDialog选文件编辑框配地址一条主链路下来几乎没有第三方依赖。2. 先搭界面文件选择、服务器地址与配置记忆2.1 用CFileDialog做文件选择单文件与多文件的两种写法MFC里选文件的标准做法是CFileDialog这个封装直接走Windows通用对话框不需要自己画文件列表。标题里的“文件选择”看起来是个小功能但落地时有两个决策点只允许选一个文件还是多个文件以及选完文件之后路径怎么存、下次打开要不要记住上次的目录。先看单文件的选择写法// 单文件选择pFileName 接收完整路径 CString SelectSingleFile(const CString strTitle) { CFileDialog dlg(TRUE, // TRUE 打开文件 _T(*.*), // 默认扩展名仅作初始过滤 NULL, OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, _T(所有文件 (*.*)|*.*|日志文件 (*.log)|*.log||), AfxGetMainWnd()); dlg.m_ofn.lpstrTitle strTitle; // 对话框标题 if (dlg.DoModal() IDOK) { return dlg.GetPathName(); // 返回完整路径 } return _T(); }OFN_FILEMUSTEXIST强制用户只能选真实存在的文件适合上传场景避免选了路径之后读文件才报错。OFN_HIDEREADONLY隐藏“只读”复选框减少无意义输入。GetPathName()返回的是磁盘绝对路径后续传给上传函数直接使用即可。多文件选择会稍微绕一点。CFileDialog 构造后要手动加OFN_ALLOWMULTISELECT标志同时缓冲区大小默认只有_MAX_PATH文件多或者路径长时会截断这是个老坑。需要自己扩容缓冲区// 多文件选择返回 CStringArray元素为完整路径 CStringArray SelectMultiFiles(const CString strTitle) { CStringArray arrFiles; CFileDialog dlg(TRUE, NULL, NULL, OFN_FILEMUSTEXIST | OFN_HIDEREADONLY | OFN_ALLOWMULTISELECT, _T(所有文件 (*.*)|*.*||), AfxGetMainWnd()); // 关键扩容缓冲区否则文件多时静默截断 const UINT nBufSize 32768; dlg.m_ofn.lpstrFile new TCHAR[nBufSize]; dlg.m_ofn.nMaxFile nBufSize; dlg.m_ofn.lpstrFile[0] _T(\0); dlg.m_ofn.lpstrTitle strTitle; if (dlg.DoModal() IDOK) { POSITION pos dlg.GetStartPosition(); while (pos ! NULL) { arrFiles.Add(dlg.GetNextPathName(pos)); } } delete[] dlg.m_ofn.lpstrFile; return arrFiles; }GetNextPathName内部会处理“目录 多个文件名”两种返回格式不用自己解析这是MFC对比纯Win32 API的便利点。这里有个容易被忽视的细节lpstrFile指向的缓冲区在DoModal()期间必须保持有效所以不能直接在栈上构造后就释放我习惯用new[]分配并在对话框关闭后delete[]。多选模式下返回的文件在CStringArray里后续可以逐一遍历上传。2.2 服务器地址配置区编辑框、URL合法性校验与注册表记忆服务器地址配置是标题里另一个明确要求。通常做法是放一个静态文本加一个编辑框旁边留“保存配置”的按钮。控件排布可以直接在对话框资源编辑器里画运行起来就是标准的MFC窗口不需要额外代码。但地址本身必须校验否则用户填了个192.168.1.10:8080或者漏了协议头上传阶段才报错体验就很差。我在界面里一般放三个控件CComboBox用于协议选择HTTP / HTTPS一个CEdit用于填地址和端口一个“测试连接”按钮作为可选动作。地址框里让用户填完整URL比如http://192.168.1.10:8080/upload校验用 WinINet 自带的InternetCrackUrl最省事// 校验URL是否合法并拆出协议、主机、端口、路径 BOOL ValidateServerUrl(const CString strUrl, CString strHost, INTERNET_PORT nPort) { if (strUrl.IsEmpty()) { AfxMessageBox(_T(服务器地址不能为空)); return FALSE; } URL_COMPONENTS uc { 0 }; uc.dwStructSize sizeof(URL_COMPONENTS); uc.lpszHostName NULL; uc.dwHostNameLength 1; // 先探测需要多大缓冲区 uc.lpszUrlPath NULL; uc.dwUrlPathLength 1; // INTERNET_FLAG_NO_CANONICALIZE不自动转义保持原样 if (!InternetCrackUrl(strUrl, (DWORD)strUrl.GetLength(), INTERNET_FLAG_NO_CANONICALIZE, uc)) { AfxMessageBox(_T(URL格式不正确请检查是否缺少 http:// 或 https://)); return FALSE; } // 第二次调用获取真实数据 CString strHostBuf; CString strPathBuf; uc.lpszHostName strHostBuf.GetBuffer(uc.dwHostNameLength 1); uc.dwHostNameLength uc.dwHostNameLength 1; uc.lpszUrlPath strPathBuf.GetBuffer(uc.dwUrlPathLength 1); uc.dwUrlPathLength uc.dwUrlPathLength 1; if (!InternetCrackUrl(strUrl, (DWORD)strUrl.GetLength(), INTERNET_FLAG_NO_CANONICALIZE, uc)) { strHostBuf.ReleaseBuffer(); strPathBuf.ReleaseBuffer(); return FALSE; } strHostBuf.ReleaseBuffer(); strPathBuf.ReleaseBuffer(); strHost strHostBuf; nPort uc.nPort; return TRUE; }第一次InternetCrackUrl传空缓冲区是为了探测长度第二次才真正填充数据。uc.nPort在URL里没写明端口时WinINet 会自动补 80 或 443这个特性省得自己判断协议。校验通过后把完整地址保存到注册表下次启动直接带出来。保存位置用HKEY_CURRENT_USER\Software\你的程序名不需要管理员权限// 保存服务器地址到注册表key为HKEY_CURRENT_USER void SaveServerUrl(const CString strUrl) { HKEY hKey NULL; DWORD dwDisposition 0; LONG lRet RegCreateKeyEx(HKEY_CURRENT_USER, _T(Software\\FileUploadTool), 0, NULL, 0, KEY_WRITE, NULL, hKey, dwDisposition); if (lRet ERROR_SUCCESS hKey ! NULL) { // 以UTF-16写入REG_SZ即宽字符字符串 RegSetValueEx(hKey, _T(ServerUrl), 0, REG_SZ, (const BYTE*)(LPCTSTR)strUrl, (DWORD)(strUrl.GetLength() 1) * sizeof(TCHAR)); RegCloseKey(hKey); } } // 读取时用RegQueryValueEx注意先探测长度再读 CString LoadServerUrl() { CString strUrl; HKEY hKey NULL; if (RegOpenKeyEx(HKEY_CURRENT_USER, _T(Software\\FileUploadTool), 0, KEY_READ, hKey) ERROR_SUCCESS) { DWORD dwSize 0; RegQueryValueEx(hKey, _T(ServerUrl), NULL, NULL, NULL, dwSize); // 拿到大小 if (dwSize 0) { LPTSTR pBuf strUrl.GetBuffer(dwSize / sizeof(TCHAR)); RegQueryValueEx(hKey, _T(ServerUrl), NULL, NULL, (BYTE*)pBuf, dwSize); strUrl.ReleaseBuffer(); } RegCloseKey(hKey); } return strUrl; }GetBuffer分配的缓冲区大小严格按dwSize / sizeof(TCHAR)计算注册表返回的dwSize包含结尾的\0字节数。这个写法比用CString::LoadFile或自定义INI更稳而且注册表方案在域环境下还能跟随用户配置漫游。除了地址文件选择对话框的初始目录也可以存注册表下次打开直接定位到上次的目录省得一层层点进去。3. 传输层选型与multipart拼包3.1 为什么选WinINet而不是MFC的CInternetSession或libcurlMFC自带CInternetSession和CHttpFile老教程里常用来做HTTP GET/POST但标题需求是上传文件这就有个现实问题CHttpFile对 multipart/form-data 的支持基本为零要自己拼报文体而它又包了一层很厚的封装拼完数据还要受制于它的句柄管理方式。我试过用CInternetSession做文件上传最后为了控制超时和读取响应还是要拿底层HINTERNET句柄等于白绕一圈。所以干脆直接用WinINet API中间不做MFC封装。libcurl 功能确实强支持断点续传、连接复用、SSL各种细节但MFC工程引入它要把CURL源码或预编译库接进VS项目链接配置对新手是麻烦事。如果目标是“在MFC框架下快速做出一个自用的上传工具”WinINet是系统自带的不会有运行时分发问题。WinINet 在服务端API调用的场景下有一个天然好处默认集成IE的代理设置公司内网开了代理时InternetOpen传INTERNET_OPEN_TYPE_PRECONFIG就能自动走代理省一层配置。代价是它自带HTTP连接池长连接保持行为不完全由自己控制上传大文件时要留意连接被服务端回收的情况。3.2 手拼multipart/form-data格式、boundary与文件名编码HTTP上传文件绝大多数服务端接口比如Java的Servlet、Python的Flask/FastAPI、Nginx后端都按 multipart/form-data 解析。这个格式本身不复杂核心是一个随机boundary字符串把各部分分隔开。自己在MFC里拼包等于把浏览器的行为复刻一遍控制力最强。拼包前先明确两个参数name是服务端接口约定的表单字段名很多后端写死成file要跟对方确认filename是服务端保存收到的文件名如果不想让服务器看到本地磁盘路径这里可以只传文件名部分。正文长度需要精确计算否则服务端报文解析会错位。// 构造multipart/form-data报文体并上传 BOOL UploadViaWinINet(const CString strServerUrl, const CString strFilePath, CString strResponse) // 返回值服务端响应文本 { // 1. 读取文件内容文件不大时一次性读入 CFile file; if (!file.Open(strFilePath, CFile::modeRead | CFile::shareDenyWrite)) { AfxMessageBox(_T(无法打开文件可能被占用)); return FALSE; } ULONGLONG nFileSize file.GetLength(); BYTE* pFileData new BYTE[(size_t)nFileSize]; file.Read(pFileData, (UINT)nFileSize); file.Close(); // 2. 生成随机boundary CString strBoundary; strBoundary.Format(_T(----WebKitFormBoundary%04d%04d), rand() % 10000, rand() % 10000); // 3. 从完整路径里拆出文件名只取最后一段 CString strFileName strFilePath; int nPos strFileName.ReverseFind(_T(\\)); if (nPos 0) strFileName strFileName.Mid(nPos 1); // 4. 拼header段 CString strHeader; strHeader.Format(_T(--%s\r\n) _T(Content-Disposition: form-data; name\file\; filename\%s\\r\n) _T(Content-Type: application/octet-stream\r\n\r\n), strBoundary, strFileName); CStringA strHeaderA CStringA(strHeader); // 5. 拼结尾段 CString strTail; strTail.Format(_T(\r\n--%s--\r\n), strBoundary); CStringA strTailA CStringA(strTail); // 6. 总长度 header 文件 tail ULONGLONG nContentLength strHeaderA.GetLength() nFileSize strTailA.GetLength(); DWORD dwContentLength (DWORD)nContentLength; HINTERNET hInternet InternetOpen(_T(MFCUpload/1.0), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0); if (hInternet NULL) { delete[] pFileData; return FALSE; } // 7. 用INTERNET_FLAG_SECURE走https服务端要求http就传0 HINTERNET hConnect InternetConnect(hInternet, GetHostFromUrl(strServerUrl), GetPortFromUrl(strServerUrl), NULL, NULL, INTERNET_SERVICE_HTTP, 0, 0); if (hConnect NULL) { InternetCloseHandle(hInternet); delete[] pFileData; return FALSE; } // 8. 构造请求POST UploadPath HINTERNET hRequest HttpOpenRequest(hConnect, _T(POST), GetPathFromUrl(strServerUrl), NULL, NULL, NULL, INTERNET_FLAG_SECURE, 0); if (hRequest NULL) { InternetCloseHandle(hConnect); InternetCloseHandle(hInternet); delete[] pFileData; return FALSE; } // 9. 设置Content-Type和Content-Length CString strContentType; strContentType.Format(_T(multipart/form-data; boundary%s), strBoundary); HttpAddRequestHeaders(hRequest, _T(Content-Type: ) strContentType, (DWORD)-1L, HTTP_ADDREQ_FLAG_REPLACE | HTTP_ADDREQ_FLAG_ADD); // 10. 发送请求分块写body BOOL bSend HttpSendRequestEx(hRequest, NULL, 0, dwContentLength, 0); if (bSend) { DWORD dwWritten 0; // 先写header段 InternetWriteFile(hRequest, strHeaderA.GetBuffer(), strHeaderA.GetLength(), dwWritten); strHeaderA.ReleaseBuffer(); // 再写文件内容 DWORD dwFilePos 0; while (dwFilePos (DWORD)nFileSize) { DWORD dwChunk min(4096, (DWORD)nFileSize - dwFilePos); InternetWriteFile(hRequest, pFileData dwFilePos, dwChunk, dwWritten); dwFilePos dwWritten; } // 最后写tail段 InternetWriteFile(hRequest, strTailA.GetBuffer(), strTailA.GetLength(), dwWritten); strTailA.ReleaseBuffer(); } // 11. 结束请求并读取响应文本 BOOL bEnd HttpEndRequest(hRequest, NULL, 0, 0); if (bEnd) { CHAR szBuf[1025] { 0 }; DWORD dwRead 0; while (InternetReadFile(hRequest, szBuf, 1024, dwRead) dwRead 0) { szBuf[dwRead] 0; strResponse CString(szBuf); // 注意此处假定响应是文本 dwRead 0; } } InternetCloseHandle(hRequest); InternetCloseHandle(hConnect); InternetCloseHandle(hInternet); delete[] pFileData; return bEnd; }这个流程最容易翻车的地方是HttpSendRequestEx的dwContentLength参数。它必须等于整个包体长度header 文件 tail多一字节少一字节都会让服务端解析失败或超时等待。另一个是InternetWriteFile的返回值是“本次写入的字节数”不等于你要写入的字节数所以循环里必须用dwFilePos dwWritten不能假设一次写完。文件数据用min(4096, ...)分块避免一次性把整个大文件塞给底层网络栈。3.3 HTTPS上传与证书处理INTERNET_FLAG_SECURE和证书错误路径标题明确提到“http或者https”在设计上就是地址栏给用户两个选择。走HTTPS时HttpOpenRequest要带上INTERNET_FLAG_SECURE标志同时默认端口会变成443。这一步做了之后最常见的现象是内网自签名证书时报ERROR_INTERNET_SEC_CERT_DATE_INVALID12045或者ERROR_INTERNET_SEC_CERT_CN_INVALID12037程序直接弹错上传中断。这是因为WinINet默认对HTTPS证书做严格校验而内网服务器的证书往往是自签的、主机名对不上或已过期。生产环境我的处理原则是校验不能全关但内网工具可以容忍特定错误。做法是给HttpOpenRequest追加几个忽略标志// 自签名内网证书只在上传工具里加生产环境不要效仿 DWORD dwSecureFlags INTERNET_FLAG_SECURE; // 允许证书名称与主机名不一致 dwSecureFlags | INTERNET_FLAG_IGNORE_CERT_CN_INVALID; // 允许证书日期已过期 dwSecureFlags | INTERNET_FLAG_IGNORE_CERT_DATE_INVALID;命令行工具和无界面服务绝不建议这样写等于把HTTPS的边界撕掉一半。但在机房内网、设备证书常年不更新的场景下这是同事之间传文件的工具安全威胁模型远低于公网加了反而能正常干活。如果服务器证书确实有问题更体面的做法是让运维把证书导入Windows根证书存储区certmgr.msc→ 受信任的根证书颁发机构 → 导入这样代码里一点特殊标志都不用加。4. 让界面不卡工作线程、进度上报与取消4.1 上传为什么必须离开UI线程MFC程序的UI线程靠消息循环活着。如果直接在“上传”按钮的OnBnClicked里跑HttpSendRequestEx加InternetWriteFile那么从点击到最后传输完成整个窗口的消息泵被卡住拖动窗口、点取消按钮全部无效。文件小时只有一两秒的“假死”大文件时Windows会直接标注“未响应”用户第一反应是杀进程血泪经验。更麻烦的是WinINet的InternetOpen句柄和线程模型有限制同一个HINTERNET句柄不建议跨线程并发使用。常见做法是在工作线程里重新InternetOpen这样请求、连接、句柄都在线程内自洽主线程只通过消息接收结果。MFC里建工作线程的标准工具是AfxBeginThread。4.2 工作线程与PostMessage进度上报上传线程不需要返回线程句柄也不需要等待AfxBeginThread默认立即启动。启动后线程不能直接操作界面控件只能通过PostMessage向主窗口投递自定义消息让主窗口去更新进度条。#define WM_UPLOAD_PROGRESS (WM_USER 100) #define WM_UPLOAD_FINISHED (WM_USER 101) // 上传工作线程入口pParam 指向一个包含所有参数的上下文结构体 UINT UploadThreadProc(LPVOID pParam) { CUploadContext* pCtx (CUploadContext*)pParam; HWND hWnd pCtx-hWnd; // 主窗口句柄用于PostMessage CString strUrl pCtx-strUrl; CString strFile pCtx-strFile; // 内部重新打开Internet句柄避免跨线程复用 HINTERNET hInternet InternetOpen(_T(MFCUpload/1.0), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0); // ... 这里复用 3.2 节的上传主体逻辑 ... // 上传过程中每写完一块就上报一次进度 DWORD dwFilePos 0; while (dwFilePos nFileSize) { DWORD dwChunk min(4096, nFileSize - dwFilePos); InternetWriteFile(hRequest, pFileData dwFilePos, dwChunk, dwWritten); dwFilePos dwWritten; // 向主窗口投递进度消息进度百分比由主窗口计算 ::PostMessage(hWnd, WM_UPLOAD_PROGRESS, (WPARAM)dwFilePos, (LPARAM)nFileSize); } // 结束时通知主窗口 ::PostMessage(hWnd, WM_UPLOAD_FINISHED, (WPARAM)bSuccess, (LPARAM)strResponse); delete pCtx; return 0; } // 按钮事件里启动线程 void CFileUploadDlg::OnBnClickedBtnUpload() { // 收集界面参数到上下文结构体 CUploadContext* pCtx new CUploadContext; pCtx-hWnd m_hWnd; pCtx-strUrl m_strServerUrl; pCtx-strFile m_strFilePath; // 启用取消按钮禁用上传按钮防止二次点击 GetDlgItem(IDC_BTN_UPLOAD)-EnableWindow(FALSE); GetDlgItem(IDC_BTN_CANCEL)-EnableWindow(TRUE); AfxBeginThread(UploadThreadProc, pCtx); }进度消息的WPARAM传已上传字节数LPARAM传文件总大小主窗口在ON_MESSAGE(WM_UPLOAD_PROGRESS, ...)里相除得到百分比。这里有个性能问题4KB一块就发一条消息100MB文件要发两万多条消息进度条刷新不过来。实际做法是做个节流记录上次发送的当前进度只有变化超过1MB或者时间超过200ms才PostMessage。消息量降下来后进度条拖动和窗口重绘都不会抢上传线程的CPU。4.3 取消操作HttpEndRequest后的处理与标志位取消上传没那么简单不是设个m_bCancel TRUE线程就会停。WinINet的上传请求一旦发出InternetWriteFile会继续把数据塞给网络栈。真正的取消动作是关闭请求句柄但直接InternetCloseHandle会导致服务端收到一个不完整的请求体对某些后端来说会留下半截文件或占用一个连接不释放。更稳妥的顺序是把volatile BOOL取消标志传给线程线程在写文件循环的开始处判断一次如果置位就调用HttpEndRequest结束当前请求或者直接把请求句柄关闭然后再清理。有一种情况比较棘手服务端如果正在等待完整的包体HttpEndRequest会阻塞到超时。为了响应取消操作我一般在线程里再留一个隐藏的小技巧——设置较短的INTERNET_OPTION_RECEIVE_TIMEOUT让取消后的等待尽快返回。// 在循环入口处响应取消 if (pCtx-bCancel) { // 中断当前请求服务端会收到连接重置 InternetCloseHandle(hRequest); // 通知主窗口已取消 ::PostMessage(hWnd, WM_UPLOAD_FINISHED, (WPARAM)FALSE, (LPARAM)_T(用户取消)); break; }MFC里对取消按钮的响应不要粗暴地在线程里搞TerminateThread那会让网络句柄泄漏、内存来不及释放下次上传时系统可能报句柄不足。HttpEndRequest失败返回时读一下GetLastError如果是ERROR_INTERNET_CONNECTION_RESET基本可以认定是主动取消导致的不算真正意义上的网络异常日志里要区分开。5. MFC上传文件绕不开的5个坑现象、原因、处理5.1 点击上传后窗口白屏无响应现象点完“上传”窗口变白鼠标转圈等几秒甚至几十秒才弹结果。文件稍微大一点系统直接提示“此程序未响应”用户当场就想杀进程。原因按钮事件直接调了上传函数。HttpSendRequestEx和InternetWriteFile是阻塞调用期间UI线程的消息循环完全停摆。对话框的“确定”“取消”按钮全部失效连重绘都被卡住。处理上传逻辑必须放工作线程。按钮事件里只做三件事收集界面参数、禁掉上传按钮、AfxBeginThread创建线程。线程内部与主窗口交互一律走PostMessage不要用SendMessage因为后者是同步的等主窗口处理消息时如果主窗口正忙线程反而被卡住。5.2 中文文件名上传后服务器收到乱码或400现象文件名是“测试报告.pdf”上传后服务端日志里显示????.pdf或者接口直接返回400文件保存失败。原因multipart里filename的值按Unicode直接CStringA强转转成了系统当前代码页中文环境是GBK但服务端按UTF-8解析两边对不上。文件名里的中文在HTTP头里属于非ASCII字符有的框架严格要求RFC 2231编码有的则看你用什么格式塞进去。处理两个层面解决。第一filename放进header之前先转UTF-8CStringA strUtf8 CW2A(strFileName, CP_UTF8)保证字节序列是UTF-8第二如果服务端对非ASCII文件名仍然挑剔就约定好统一把文件名ASCII化——上传时把本地文件名替换成file_YYYYMMDD_HHMMSS.ext再放进multipart原始名写在额外一个表单字段里上报。后面这种做法在实际内网系统里最省心服务器端不用改编码逻辑。5.3 服务器地址可达但上传超时程序几分钟后才报错现象InternetWriteFile返回成功后程序卡在HttpEndRequest或InternetReadFile上最长要拖一两分钟才返回错误码12002。原因WinINet默认的接收超时时间很长而且请求失败后还有内部重试逻辑。服务器如果只收文件不返回响应比如某些老接口写死不吐内容客户端会一直挂在读响应那一步。处理给请求句柄显式设置超时。HttpOpenRequest返回后立刻调用InternetSetOption// 设置连接、发送、接收三组超时单位毫秒 DWORD dwTimeout 30000; InternetSetOption(hRequest, INTERNET_OPTION_CONNECT_TIMEOUT, dwTimeout, sizeof(dwTimeout)); InternetSetOption(hRequest, INTERNET_OPTION_SEND_TIMEOUT, dwTimeout, sizeof(dwTimeout)); InternetSetOption(hRequest, INTERNET_OPTION_RECEIVE_TIMEOUT, dwTimeout, sizeof(dwTimeout));30秒对常规内网足够文件特别大或跨公网时可以放宽到60秒。这里要区分连接超时和接收超时的现象连不上是立刻弹错误接收超时是“已经传完了但没有等到服务端回应”日志里看到12002就知道是哪一端的问题。5.4 HTTPS上传报错12037/12045证书明明是合法的现象同样的地址浏览器访问完全正常程序里一传就报12045再一查是SEC_CERT_DATE_INVALID。原因浏览器下载了系统根证书列表做了自动化信任而WinINet在校验时使用的根证书存储区可能没有包含新颁发的中间证书。另一种常见情况是服务器证书链里带了本地自签的根证书这台机器没装过。处理先让运维确认证书链完整缺中间证书就去服务器导出补装。如果就是为了让工具跑通在内网场景下可以把INTERNET_FLAG_IGNORE_CERT_DATE_INVALID和INTERNET_FLAG_IGNORE_CERT_CN_INVALID加上但要把这段逻辑用宏或配置项包起来防止别人误以为HTTPS的证书校验是摆设。日志里务必记录GetLastError()这样别人排查时立刻知道是证书问题而不是真的断网。5.5 传1GB大文件内存直接爆掉现象文件小于几百MB没问题超过1GB后new BYTE[nFileSize]抛异常或程序吃掉大量内存被系统强制终止。原因3.2节的示例里为了演示把整个文件读进了内存。大文件场景这个做法不成立——字节数组、CString里的header和tail同时驻留内存峰值接近文件两倍大小。处理改为流式上传。InternetWriteFile本身支持分块写完全可以把CFile的对象传给线程边读边写// 流式上传不一次性读入内存 CFile file; file.Open(strFilePath, CFile::modeRead | CFile::shareDenyWrite); BYTE buffer[8192]; ULONGLONG nRemain file.GetLength(); while (nRemain 0) { UINT nRead file.Read(buffer, sizeof(buffer)); DWORD dwWritten 0; InternetWriteFile(hRequest, buffer, nRead, dwWritten); nRemain - dwWritten; // 以实际写入为准 } file.Close();这里还要警惕32位程序的文件大小上限。MFC的CFile::GetLength()返回ULONGLONG但老代码里如果用了DWORD接收超过4GB后会溢出。做工具时如果没把握系统是64位的建议先查sizeof(void*)和文件大小上限或者干脆限制只传4GB以下文件。6. 上传完怎么确认真成功了抓包验证与日志习惯工具做完能跑通不代表它真的在正确地工作。我见过很多次“显示上传成功但服务器上文件是0字节”的情况原因五花八门服务端返回200但内容是空文件、multipart边界写得有误导致只解析出部分字段、或者进度条走完但HttpEndRequest失败被代码吞掉了。所以验证这一步我强烈建议装个Fiddler或Wireshark手动抓一次上传请求。Fiddler抓HTTPS需要装根证书内网测试机上直接跑还挺有效。抓到请求后重点看三类内容Content-Type里的boundary是否与包体一致文件内容的起始和结束位置是否有\r\n混淆Content-Length是否与包体实际长度吻合。这三处错一个服务端行为都会很奇怪。另外多看服务端日志比看客户端返回码靠谱。客户端HttpEndRequest成功只能说明“TCP层面的请求已经完整发完”服务端业务逻辑是否成功处理完全看HTTP状态码和响应体内容。我习惯在上传函数返回后统一记一条日志字段固定字段说明示例时间本地时间到秒2025-05-21 14:32:10文件名实际发送的文件名report_20250521.pdf大小文件字节数20488291耗时从开始传到响应返回的毫秒数1840返回码HTTP状态码200响应体服务端返回的文本前512字节upload success日志写进同目录下的upload.log追加模式不用数据库。出现“显示成功但文件不对”的情况先查返回码是200还是201再查响应体里服务端有没有把文件ID回传。进阶方向可以考虑做MD5秒传上传前先传文件哈希服务端比对已有文件就直接返回成功省大量带宽。这个思路在MFC里实现也不难多一次HTTP请求而已。另外注意一点工作习惯写线程里收到任何WinINet错误一定要把GetLastError()转换成可读的ERROR_INTERNET_*字样记下来。这个代码在网上能搜到现成的错误映射表但每次项目里都有人直接把数字塞日志里排查时得翻Windows头文件才猜得到意思等于给自己埋坑。做工具不怕代码朴素怕的是出错时没有足够信息定位。这些日志习惯保持住比把上传代码优化出20%的性能更有价值希望帮到你。本文还有配套的精品资源点击获取
MFC HTTP文件上传实战：WinINet、multipart与工作线程详解
简介MFC框架下实现HTTP/HTTPS上传的完整示例工程面向需要基于WinInet进行网络文件传输的C开发人员重点解决文件选择、服务器地址配置和上传进度展示等界面与协议衔接问题。压缩包共49个文件以头文件h、源文件cpp、Visual Studio工程文件sln/vcxproj为主另含可运行的exe及调试所需的pdb、idb等文件整体大小约73.09MB便于直接打开工程查看代码和运行效果。该资源已有567人学习代码中封装了PostFormData等关键类演示了MFC对话框下调用WinInet接口实现POST上传的流程包括SSL设置、请求构造、错误处理及UI更新适合作为学习MFC网络编程和HTTP协议在实际项目中落地的参考。1. 打开文件、填上服务器地址、点上传MFC里最朴素的HTTP上传工具怎么做做过Windows桌面工具的人多半遇到过这种需求生产线上把报表传回服务器、终端机把日志文件定时上送、或者给一个十年前的MFC老程序加一个“把导出文件发给中心”的功能。这个标题其实就是一套已经标准化了的需求——文件选择、服务器地址配置、HTTP/HTTPS上传三者合一落到MFC界面上。它解决的是“不让使用方记任何命令行、不装额外运行时双击就能把文件传到指定服务端”这件事适合做内部工具、工控机客户端、遗留系统集成。技术路线很成熟WinINet/WinHTTP是系统自带接口CFileDialog选文件编辑框配地址一条主链路下来几乎没有第三方依赖。2. 先搭界面文件选择、服务器地址与配置记忆2.1 用CFileDialog做文件选择单文件与多文件的两种写法MFC里选文件的标准做法是CFileDialog这个封装直接走Windows通用对话框不需要自己画文件列表。标题里的“文件选择”看起来是个小功能但落地时有两个决策点只允许选一个文件还是多个文件以及选完文件之后路径怎么存、下次打开要不要记住上次的目录。先看单文件的选择写法// 单文件选择pFileName 接收完整路径 CString SelectSingleFile(const CString strTitle) { CFileDialog dlg(TRUE, // TRUE 打开文件 _T(*.*), // 默认扩展名仅作初始过滤 NULL, OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, _T(所有文件 (*.*)|*.*|日志文件 (*.log)|*.log||), AfxGetMainWnd()); dlg.m_ofn.lpstrTitle strTitle; // 对话框标题 if (dlg.DoModal() IDOK) { return dlg.GetPathName(); // 返回完整路径 } return _T(); }OFN_FILEMUSTEXIST强制用户只能选真实存在的文件适合上传场景避免选了路径之后读文件才报错。OFN_HIDEREADONLY隐藏“只读”复选框减少无意义输入。GetPathName()返回的是磁盘绝对路径后续传给上传函数直接使用即可。多文件选择会稍微绕一点。CFileDialog 构造后要手动加OFN_ALLOWMULTISELECT标志同时缓冲区大小默认只有_MAX_PATH文件多或者路径长时会截断这是个老坑。需要自己扩容缓冲区// 多文件选择返回 CStringArray元素为完整路径 CStringArray SelectMultiFiles(const CString strTitle) { CStringArray arrFiles; CFileDialog dlg(TRUE, NULL, NULL, OFN_FILEMUSTEXIST | OFN_HIDEREADONLY | OFN_ALLOWMULTISELECT, _T(所有文件 (*.*)|*.*||), AfxGetMainWnd()); // 关键扩容缓冲区否则文件多时静默截断 const UINT nBufSize 32768; dlg.m_ofn.lpstrFile new TCHAR[nBufSize]; dlg.m_ofn.nMaxFile nBufSize; dlg.m_ofn.lpstrFile[0] _T(\0); dlg.m_ofn.lpstrTitle strTitle; if (dlg.DoModal() IDOK) { POSITION pos dlg.GetStartPosition(); while (pos ! NULL) { arrFiles.Add(dlg.GetNextPathName(pos)); } } delete[] dlg.m_ofn.lpstrFile; return arrFiles; }GetNextPathName内部会处理“目录 多个文件名”两种返回格式不用自己解析这是MFC对比纯Win32 API的便利点。这里有个容易被忽视的细节lpstrFile指向的缓冲区在DoModal()期间必须保持有效所以不能直接在栈上构造后就释放我习惯用new[]分配并在对话框关闭后delete[]。多选模式下返回的文件在CStringArray里后续可以逐一遍历上传。2.2 服务器地址配置区编辑框、URL合法性校验与注册表记忆服务器地址配置是标题里另一个明确要求。通常做法是放一个静态文本加一个编辑框旁边留“保存配置”的按钮。控件排布可以直接在对话框资源编辑器里画运行起来就是标准的MFC窗口不需要额外代码。但地址本身必须校验否则用户填了个192.168.1.10:8080或者漏了协议头上传阶段才报错体验就很差。我在界面里一般放三个控件CComboBox用于协议选择HTTP / HTTPS一个CEdit用于填地址和端口一个“测试连接”按钮作为可选动作。地址框里让用户填完整URL比如http://192.168.1.10:8080/upload校验用 WinINet 自带的InternetCrackUrl最省事// 校验URL是否合法并拆出协议、主机、端口、路径 BOOL ValidateServerUrl(const CString strUrl, CString strHost, INTERNET_PORT nPort) { if (strUrl.IsEmpty()) { AfxMessageBox(_T(服务器地址不能为空)); return FALSE; } URL_COMPONENTS uc { 0 }; uc.dwStructSize sizeof(URL_COMPONENTS); uc.lpszHostName NULL; uc.dwHostNameLength 1; // 先探测需要多大缓冲区 uc.lpszUrlPath NULL; uc.dwUrlPathLength 1; // INTERNET_FLAG_NO_CANONICALIZE不自动转义保持原样 if (!InternetCrackUrl(strUrl, (DWORD)strUrl.GetLength(), INTERNET_FLAG_NO_CANONICALIZE, uc)) { AfxMessageBox(_T(URL格式不正确请检查是否缺少 http:// 或 https://)); return FALSE; } // 第二次调用获取真实数据 CString strHostBuf; CString strPathBuf; uc.lpszHostName strHostBuf.GetBuffer(uc.dwHostNameLength 1); uc.dwHostNameLength uc.dwHostNameLength 1; uc.lpszUrlPath strPathBuf.GetBuffer(uc.dwUrlPathLength 1); uc.dwUrlPathLength uc.dwUrlPathLength 1; if (!InternetCrackUrl(strUrl, (DWORD)strUrl.GetLength(), INTERNET_FLAG_NO_CANONICALIZE, uc)) { strHostBuf.ReleaseBuffer(); strPathBuf.ReleaseBuffer(); return FALSE; } strHostBuf.ReleaseBuffer(); strPathBuf.ReleaseBuffer(); strHost strHostBuf; nPort uc.nPort; return TRUE; }第一次InternetCrackUrl传空缓冲区是为了探测长度第二次才真正填充数据。uc.nPort在URL里没写明端口时WinINet 会自动补 80 或 443这个特性省得自己判断协议。校验通过后把完整地址保存到注册表下次启动直接带出来。保存位置用HKEY_CURRENT_USER\Software\你的程序名不需要管理员权限// 保存服务器地址到注册表key为HKEY_CURRENT_USER void SaveServerUrl(const CString strUrl) { HKEY hKey NULL; DWORD dwDisposition 0; LONG lRet RegCreateKeyEx(HKEY_CURRENT_USER, _T(Software\\FileUploadTool), 0, NULL, 0, KEY_WRITE, NULL, hKey, dwDisposition); if (lRet ERROR_SUCCESS hKey ! NULL) { // 以UTF-16写入REG_SZ即宽字符字符串 RegSetValueEx(hKey, _T(ServerUrl), 0, REG_SZ, (const BYTE*)(LPCTSTR)strUrl, (DWORD)(strUrl.GetLength() 1) * sizeof(TCHAR)); RegCloseKey(hKey); } } // 读取时用RegQueryValueEx注意先探测长度再读 CString LoadServerUrl() { CString strUrl; HKEY hKey NULL; if (RegOpenKeyEx(HKEY_CURRENT_USER, _T(Software\\FileUploadTool), 0, KEY_READ, hKey) ERROR_SUCCESS) { DWORD dwSize 0; RegQueryValueEx(hKey, _T(ServerUrl), NULL, NULL, NULL, dwSize); // 拿到大小 if (dwSize 0) { LPTSTR pBuf strUrl.GetBuffer(dwSize / sizeof(TCHAR)); RegQueryValueEx(hKey, _T(ServerUrl), NULL, NULL, (BYTE*)pBuf, dwSize); strUrl.ReleaseBuffer(); } RegCloseKey(hKey); } return strUrl; }GetBuffer分配的缓冲区大小严格按dwSize / sizeof(TCHAR)计算注册表返回的dwSize包含结尾的\0字节数。这个写法比用CString::LoadFile或自定义INI更稳而且注册表方案在域环境下还能跟随用户配置漫游。除了地址文件选择对话框的初始目录也可以存注册表下次打开直接定位到上次的目录省得一层层点进去。3. 传输层选型与multipart拼包3.1 为什么选WinINet而不是MFC的CInternetSession或libcurlMFC自带CInternetSession和CHttpFile老教程里常用来做HTTP GET/POST但标题需求是上传文件这就有个现实问题CHttpFile对 multipart/form-data 的支持基本为零要自己拼报文体而它又包了一层很厚的封装拼完数据还要受制于它的句柄管理方式。我试过用CInternetSession做文件上传最后为了控制超时和读取响应还是要拿底层HINTERNET句柄等于白绕一圈。所以干脆直接用WinINet API中间不做MFC封装。libcurl 功能确实强支持断点续传、连接复用、SSL各种细节但MFC工程引入它要把CURL源码或预编译库接进VS项目链接配置对新手是麻烦事。如果目标是“在MFC框架下快速做出一个自用的上传工具”WinINet是系统自带的不会有运行时分发问题。WinINet 在服务端API调用的场景下有一个天然好处默认集成IE的代理设置公司内网开了代理时InternetOpen传INTERNET_OPEN_TYPE_PRECONFIG就能自动走代理省一层配置。代价是它自带HTTP连接池长连接保持行为不完全由自己控制上传大文件时要留意连接被服务端回收的情况。3.2 手拼multipart/form-data格式、boundary与文件名编码HTTP上传文件绝大多数服务端接口比如Java的Servlet、Python的Flask/FastAPI、Nginx后端都按 multipart/form-data 解析。这个格式本身不复杂核心是一个随机boundary字符串把各部分分隔开。自己在MFC里拼包等于把浏览器的行为复刻一遍控制力最强。拼包前先明确两个参数name是服务端接口约定的表单字段名很多后端写死成file要跟对方确认filename是服务端保存收到的文件名如果不想让服务器看到本地磁盘路径这里可以只传文件名部分。正文长度需要精确计算否则服务端报文解析会错位。// 构造multipart/form-data报文体并上传 BOOL UploadViaWinINet(const CString strServerUrl, const CString strFilePath, CString strResponse) // 返回值服务端响应文本 { // 1. 读取文件内容文件不大时一次性读入 CFile file; if (!file.Open(strFilePath, CFile::modeRead | CFile::shareDenyWrite)) { AfxMessageBox(_T(无法打开文件可能被占用)); return FALSE; } ULONGLONG nFileSize file.GetLength(); BYTE* pFileData new BYTE[(size_t)nFileSize]; file.Read(pFileData, (UINT)nFileSize); file.Close(); // 2. 生成随机boundary CString strBoundary; strBoundary.Format(_T(----WebKitFormBoundary%04d%04d), rand() % 10000, rand() % 10000); // 3. 从完整路径里拆出文件名只取最后一段 CString strFileName strFilePath; int nPos strFileName.ReverseFind(_T(\\)); if (nPos 0) strFileName strFileName.Mid(nPos 1); // 4. 拼header段 CString strHeader; strHeader.Format(_T(--%s\r\n) _T(Content-Disposition: form-data; name\file\; filename\%s\\r\n) _T(Content-Type: application/octet-stream\r\n\r\n), strBoundary, strFileName); CStringA strHeaderA CStringA(strHeader); // 5. 拼结尾段 CString strTail; strTail.Format(_T(\r\n--%s--\r\n), strBoundary); CStringA strTailA CStringA(strTail); // 6. 总长度 header 文件 tail ULONGLONG nContentLength strHeaderA.GetLength() nFileSize strTailA.GetLength(); DWORD dwContentLength (DWORD)nContentLength; HINTERNET hInternet InternetOpen(_T(MFCUpload/1.0), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0); if (hInternet NULL) { delete[] pFileData; return FALSE; } // 7. 用INTERNET_FLAG_SECURE走https服务端要求http就传0 HINTERNET hConnect InternetConnect(hInternet, GetHostFromUrl(strServerUrl), GetPortFromUrl(strServerUrl), NULL, NULL, INTERNET_SERVICE_HTTP, 0, 0); if (hConnect NULL) { InternetCloseHandle(hInternet); delete[] pFileData; return FALSE; } // 8. 构造请求POST UploadPath HINTERNET hRequest HttpOpenRequest(hConnect, _T(POST), GetPathFromUrl(strServerUrl), NULL, NULL, NULL, INTERNET_FLAG_SECURE, 0); if (hRequest NULL) { InternetCloseHandle(hConnect); InternetCloseHandle(hInternet); delete[] pFileData; return FALSE; } // 9. 设置Content-Type和Content-Length CString strContentType; strContentType.Format(_T(multipart/form-data; boundary%s), strBoundary); HttpAddRequestHeaders(hRequest, _T(Content-Type: ) strContentType, (DWORD)-1L, HTTP_ADDREQ_FLAG_REPLACE | HTTP_ADDREQ_FLAG_ADD); // 10. 发送请求分块写body BOOL bSend HttpSendRequestEx(hRequest, NULL, 0, dwContentLength, 0); if (bSend) { DWORD dwWritten 0; // 先写header段 InternetWriteFile(hRequest, strHeaderA.GetBuffer(), strHeaderA.GetLength(), dwWritten); strHeaderA.ReleaseBuffer(); // 再写文件内容 DWORD dwFilePos 0; while (dwFilePos (DWORD)nFileSize) { DWORD dwChunk min(4096, (DWORD)nFileSize - dwFilePos); InternetWriteFile(hRequest, pFileData dwFilePos, dwChunk, dwWritten); dwFilePos dwWritten; } // 最后写tail段 InternetWriteFile(hRequest, strTailA.GetBuffer(), strTailA.GetLength(), dwWritten); strTailA.ReleaseBuffer(); } // 11. 结束请求并读取响应文本 BOOL bEnd HttpEndRequest(hRequest, NULL, 0, 0); if (bEnd) { CHAR szBuf[1025] { 0 }; DWORD dwRead 0; while (InternetReadFile(hRequest, szBuf, 1024, dwRead) dwRead 0) { szBuf[dwRead] 0; strResponse CString(szBuf); // 注意此处假定响应是文本 dwRead 0; } } InternetCloseHandle(hRequest); InternetCloseHandle(hConnect); InternetCloseHandle(hInternet); delete[] pFileData; return bEnd; }这个流程最容易翻车的地方是HttpSendRequestEx的dwContentLength参数。它必须等于整个包体长度header 文件 tail多一字节少一字节都会让服务端解析失败或超时等待。另一个是InternetWriteFile的返回值是“本次写入的字节数”不等于你要写入的字节数所以循环里必须用dwFilePos dwWritten不能假设一次写完。文件数据用min(4096, ...)分块避免一次性把整个大文件塞给底层网络栈。3.3 HTTPS上传与证书处理INTERNET_FLAG_SECURE和证书错误路径标题明确提到“http或者https”在设计上就是地址栏给用户两个选择。走HTTPS时HttpOpenRequest要带上INTERNET_FLAG_SECURE标志同时默认端口会变成443。这一步做了之后最常见的现象是内网自签名证书时报ERROR_INTERNET_SEC_CERT_DATE_INVALID12045或者ERROR_INTERNET_SEC_CERT_CN_INVALID12037程序直接弹错上传中断。这是因为WinINet默认对HTTPS证书做严格校验而内网服务器的证书往往是自签的、主机名对不上或已过期。生产环境我的处理原则是校验不能全关但内网工具可以容忍特定错误。做法是给HttpOpenRequest追加几个忽略标志// 自签名内网证书只在上传工具里加生产环境不要效仿 DWORD dwSecureFlags INTERNET_FLAG_SECURE; // 允许证书名称与主机名不一致 dwSecureFlags | INTERNET_FLAG_IGNORE_CERT_CN_INVALID; // 允许证书日期已过期 dwSecureFlags | INTERNET_FLAG_IGNORE_CERT_DATE_INVALID;命令行工具和无界面服务绝不建议这样写等于把HTTPS的边界撕掉一半。但在机房内网、设备证书常年不更新的场景下这是同事之间传文件的工具安全威胁模型远低于公网加了反而能正常干活。如果服务器证书确实有问题更体面的做法是让运维把证书导入Windows根证书存储区certmgr.msc→ 受信任的根证书颁发机构 → 导入这样代码里一点特殊标志都不用加。4. 让界面不卡工作线程、进度上报与取消4.1 上传为什么必须离开UI线程MFC程序的UI线程靠消息循环活着。如果直接在“上传”按钮的OnBnClicked里跑HttpSendRequestEx加InternetWriteFile那么从点击到最后传输完成整个窗口的消息泵被卡住拖动窗口、点取消按钮全部无效。文件小时只有一两秒的“假死”大文件时Windows会直接标注“未响应”用户第一反应是杀进程血泪经验。更麻烦的是WinINet的InternetOpen句柄和线程模型有限制同一个HINTERNET句柄不建议跨线程并发使用。常见做法是在工作线程里重新InternetOpen这样请求、连接、句柄都在线程内自洽主线程只通过消息接收结果。MFC里建工作线程的标准工具是AfxBeginThread。4.2 工作线程与PostMessage进度上报上传线程不需要返回线程句柄也不需要等待AfxBeginThread默认立即启动。启动后线程不能直接操作界面控件只能通过PostMessage向主窗口投递自定义消息让主窗口去更新进度条。#define WM_UPLOAD_PROGRESS (WM_USER 100) #define WM_UPLOAD_FINISHED (WM_USER 101) // 上传工作线程入口pParam 指向一个包含所有参数的上下文结构体 UINT UploadThreadProc(LPVOID pParam) { CUploadContext* pCtx (CUploadContext*)pParam; HWND hWnd pCtx-hWnd; // 主窗口句柄用于PostMessage CString strUrl pCtx-strUrl; CString strFile pCtx-strFile; // 内部重新打开Internet句柄避免跨线程复用 HINTERNET hInternet InternetOpen(_T(MFCUpload/1.0), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0); // ... 这里复用 3.2 节的上传主体逻辑 ... // 上传过程中每写完一块就上报一次进度 DWORD dwFilePos 0; while (dwFilePos nFileSize) { DWORD dwChunk min(4096, nFileSize - dwFilePos); InternetWriteFile(hRequest, pFileData dwFilePos, dwChunk, dwWritten); dwFilePos dwWritten; // 向主窗口投递进度消息进度百分比由主窗口计算 ::PostMessage(hWnd, WM_UPLOAD_PROGRESS, (WPARAM)dwFilePos, (LPARAM)nFileSize); } // 结束时通知主窗口 ::PostMessage(hWnd, WM_UPLOAD_FINISHED, (WPARAM)bSuccess, (LPARAM)strResponse); delete pCtx; return 0; } // 按钮事件里启动线程 void CFileUploadDlg::OnBnClickedBtnUpload() { // 收集界面参数到上下文结构体 CUploadContext* pCtx new CUploadContext; pCtx-hWnd m_hWnd; pCtx-strUrl m_strServerUrl; pCtx-strFile m_strFilePath; // 启用取消按钮禁用上传按钮防止二次点击 GetDlgItem(IDC_BTN_UPLOAD)-EnableWindow(FALSE); GetDlgItem(IDC_BTN_CANCEL)-EnableWindow(TRUE); AfxBeginThread(UploadThreadProc, pCtx); }进度消息的WPARAM传已上传字节数LPARAM传文件总大小主窗口在ON_MESSAGE(WM_UPLOAD_PROGRESS, ...)里相除得到百分比。这里有个性能问题4KB一块就发一条消息100MB文件要发两万多条消息进度条刷新不过来。实际做法是做个节流记录上次发送的当前进度只有变化超过1MB或者时间超过200ms才PostMessage。消息量降下来后进度条拖动和窗口重绘都不会抢上传线程的CPU。4.3 取消操作HttpEndRequest后的处理与标志位取消上传没那么简单不是设个m_bCancel TRUE线程就会停。WinINet的上传请求一旦发出InternetWriteFile会继续把数据塞给网络栈。真正的取消动作是关闭请求句柄但直接InternetCloseHandle会导致服务端收到一个不完整的请求体对某些后端来说会留下半截文件或占用一个连接不释放。更稳妥的顺序是把volatile BOOL取消标志传给线程线程在写文件循环的开始处判断一次如果置位就调用HttpEndRequest结束当前请求或者直接把请求句柄关闭然后再清理。有一种情况比较棘手服务端如果正在等待完整的包体HttpEndRequest会阻塞到超时。为了响应取消操作我一般在线程里再留一个隐藏的小技巧——设置较短的INTERNET_OPTION_RECEIVE_TIMEOUT让取消后的等待尽快返回。// 在循环入口处响应取消 if (pCtx-bCancel) { // 中断当前请求服务端会收到连接重置 InternetCloseHandle(hRequest); // 通知主窗口已取消 ::PostMessage(hWnd, WM_UPLOAD_FINISHED, (WPARAM)FALSE, (LPARAM)_T(用户取消)); break; }MFC里对取消按钮的响应不要粗暴地在线程里搞TerminateThread那会让网络句柄泄漏、内存来不及释放下次上传时系统可能报句柄不足。HttpEndRequest失败返回时读一下GetLastError如果是ERROR_INTERNET_CONNECTION_RESET基本可以认定是主动取消导致的不算真正意义上的网络异常日志里要区分开。5. MFC上传文件绕不开的5个坑现象、原因、处理5.1 点击上传后窗口白屏无响应现象点完“上传”窗口变白鼠标转圈等几秒甚至几十秒才弹结果。文件稍微大一点系统直接提示“此程序未响应”用户当场就想杀进程。原因按钮事件直接调了上传函数。HttpSendRequestEx和InternetWriteFile是阻塞调用期间UI线程的消息循环完全停摆。对话框的“确定”“取消”按钮全部失效连重绘都被卡住。处理上传逻辑必须放工作线程。按钮事件里只做三件事收集界面参数、禁掉上传按钮、AfxBeginThread创建线程。线程内部与主窗口交互一律走PostMessage不要用SendMessage因为后者是同步的等主窗口处理消息时如果主窗口正忙线程反而被卡住。5.2 中文文件名上传后服务器收到乱码或400现象文件名是“测试报告.pdf”上传后服务端日志里显示????.pdf或者接口直接返回400文件保存失败。原因multipart里filename的值按Unicode直接CStringA强转转成了系统当前代码页中文环境是GBK但服务端按UTF-8解析两边对不上。文件名里的中文在HTTP头里属于非ASCII字符有的框架严格要求RFC 2231编码有的则看你用什么格式塞进去。处理两个层面解决。第一filename放进header之前先转UTF-8CStringA strUtf8 CW2A(strFileName, CP_UTF8)保证字节序列是UTF-8第二如果服务端对非ASCII文件名仍然挑剔就约定好统一把文件名ASCII化——上传时把本地文件名替换成file_YYYYMMDD_HHMMSS.ext再放进multipart原始名写在额外一个表单字段里上报。后面这种做法在实际内网系统里最省心服务器端不用改编码逻辑。5.3 服务器地址可达但上传超时程序几分钟后才报错现象InternetWriteFile返回成功后程序卡在HttpEndRequest或InternetReadFile上最长要拖一两分钟才返回错误码12002。原因WinINet默认的接收超时时间很长而且请求失败后还有内部重试逻辑。服务器如果只收文件不返回响应比如某些老接口写死不吐内容客户端会一直挂在读响应那一步。处理给请求句柄显式设置超时。HttpOpenRequest返回后立刻调用InternetSetOption// 设置连接、发送、接收三组超时单位毫秒 DWORD dwTimeout 30000; InternetSetOption(hRequest, INTERNET_OPTION_CONNECT_TIMEOUT, dwTimeout, sizeof(dwTimeout)); InternetSetOption(hRequest, INTERNET_OPTION_SEND_TIMEOUT, dwTimeout, sizeof(dwTimeout)); InternetSetOption(hRequest, INTERNET_OPTION_RECEIVE_TIMEOUT, dwTimeout, sizeof(dwTimeout));30秒对常规内网足够文件特别大或跨公网时可以放宽到60秒。这里要区分连接超时和接收超时的现象连不上是立刻弹错误接收超时是“已经传完了但没有等到服务端回应”日志里看到12002就知道是哪一端的问题。5.4 HTTPS上传报错12037/12045证书明明是合法的现象同样的地址浏览器访问完全正常程序里一传就报12045再一查是SEC_CERT_DATE_INVALID。原因浏览器下载了系统根证书列表做了自动化信任而WinINet在校验时使用的根证书存储区可能没有包含新颁发的中间证书。另一种常见情况是服务器证书链里带了本地自签的根证书这台机器没装过。处理先让运维确认证书链完整缺中间证书就去服务器导出补装。如果就是为了让工具跑通在内网场景下可以把INTERNET_FLAG_IGNORE_CERT_DATE_INVALID和INTERNET_FLAG_IGNORE_CERT_CN_INVALID加上但要把这段逻辑用宏或配置项包起来防止别人误以为HTTPS的证书校验是摆设。日志里务必记录GetLastError()这样别人排查时立刻知道是证书问题而不是真的断网。5.5 传1GB大文件内存直接爆掉现象文件小于几百MB没问题超过1GB后new BYTE[nFileSize]抛异常或程序吃掉大量内存被系统强制终止。原因3.2节的示例里为了演示把整个文件读进了内存。大文件场景这个做法不成立——字节数组、CString里的header和tail同时驻留内存峰值接近文件两倍大小。处理改为流式上传。InternetWriteFile本身支持分块写完全可以把CFile的对象传给线程边读边写// 流式上传不一次性读入内存 CFile file; file.Open(strFilePath, CFile::modeRead | CFile::shareDenyWrite); BYTE buffer[8192]; ULONGLONG nRemain file.GetLength(); while (nRemain 0) { UINT nRead file.Read(buffer, sizeof(buffer)); DWORD dwWritten 0; InternetWriteFile(hRequest, buffer, nRead, dwWritten); nRemain - dwWritten; // 以实际写入为准 } file.Close();这里还要警惕32位程序的文件大小上限。MFC的CFile::GetLength()返回ULONGLONG但老代码里如果用了DWORD接收超过4GB后会溢出。做工具时如果没把握系统是64位的建议先查sizeof(void*)和文件大小上限或者干脆限制只传4GB以下文件。6. 上传完怎么确认真成功了抓包验证与日志习惯工具做完能跑通不代表它真的在正确地工作。我见过很多次“显示上传成功但服务器上文件是0字节”的情况原因五花八门服务端返回200但内容是空文件、multipart边界写得有误导致只解析出部分字段、或者进度条走完但HttpEndRequest失败被代码吞掉了。所以验证这一步我强烈建议装个Fiddler或Wireshark手动抓一次上传请求。Fiddler抓HTTPS需要装根证书内网测试机上直接跑还挺有效。抓到请求后重点看三类内容Content-Type里的boundary是否与包体一致文件内容的起始和结束位置是否有\r\n混淆Content-Length是否与包体实际长度吻合。这三处错一个服务端行为都会很奇怪。另外多看服务端日志比看客户端返回码靠谱。客户端HttpEndRequest成功只能说明“TCP层面的请求已经完整发完”服务端业务逻辑是否成功处理完全看HTTP状态码和响应体内容。我习惯在上传函数返回后统一记一条日志字段固定字段说明示例时间本地时间到秒2025-05-21 14:32:10文件名实际发送的文件名report_20250521.pdf大小文件字节数20488291耗时从开始传到响应返回的毫秒数1840返回码HTTP状态码200响应体服务端返回的文本前512字节upload success日志写进同目录下的upload.log追加模式不用数据库。出现“显示成功但文件不对”的情况先查返回码是200还是201再查响应体里服务端有没有把文件ID回传。进阶方向可以考虑做MD5秒传上传前先传文件哈希服务端比对已有文件就直接返回成功省大量带宽。这个思路在MFC里实现也不难多一次HTTP请求而已。另外注意一点工作习惯写线程里收到任何WinINet错误一定要把GetLastError()转换成可读的ERROR_INTERNET_*字样记下来。这个代码在网上能搜到现成的错误映射表但每次项目里都有人直接把数字塞日志里排查时得翻Windows头文件才猜得到意思等于给自己埋坑。做工具不怕代码朴素怕的是出错时没有足够信息定位。这些日志习惯保持住比把上传代码优化出20%的性能更有价值希望帮到你。本文还有配套的精品资源点击获取
