简介：本资源面向在 Windows 平台下使用 C++ 读取 Excel 的开发者，重点演示如何借助 VS2010 的 MFC 框架调用 WPS Office 接口读取 XLSX 文件。内容围绕 WPS 动态库加载、接口函数指针获取、工作簿与工作表遍历、单元格数据解析及 MFC 界面显示等环节展开，适合具备一定 C++ 与 MFC 基础、需要在不依赖 Microsoft Office 环境下处理表格数据的读者参考。压缩包共 29 个文件，以 12 个 h 头文件与 3 个 cpp 源文件为核心，另有 sln、vcxproj 等工程配置及 rc、ico 等界面资源，整体约 19.6MB，工程结构完整可直接编译调试。目前已有 1807 人学习下载。通过该示例可掌握 WPS 接口调用流程、XLSX 数据解析思路与常见错误处理方式，并据此扩展出符合自身业务需求的表格读取模块。

1. 用 C++ 通过 WPS 读取 xlsx：一条被低估的落地路径

上周帮一个做工业数据采集的朋友排查问题，他的 C++ 程序需要读取现场 Excel 报表，但现场机器只装了 WPS，没装 Microsoft Office。他一开始用 COM 组件调 Excel.Application，结果直接报「无效的类字符串」，程序卡死在 CoCreateInstance。这不是个例——很多工控、医疗、财务场景的终端环境都是 WPS 打底，C++ 想读 xlsx，要么绕开 Office 依赖，要么就得学会跟 WPS 的 COM 接口打交道。

这篇笔记拆的就是「C++ 通过 WPS 读取 Excel」这条路径。它解决的核心问题是：在只有 WPS 的 Windows 环境下，用 C++ 稳定读取 xlsx 的单元格、区域和公式结果。适合两类人：一是维护老 MFC/Qt 项目、必须走 COM 的工程师；二是想评估「WPS 自动化 vs 纯解析库」选型边界的开发者。下面从原理、环境、代码到踩坑，一步步拆开。

2. 先搞懂 WPS 的 COM 接口：为什么 Excel.Application 会翻车

2.1 WPS 的 ProgID 与 Excel 的差异

Microsoft Office 的 Excel 对外暴露的 ProgID 是Excel.Application，而 WPS 表格对应的 ProgID 是KET.Application（部分版本也兼容ET.Application）。这是第一个分水岭：如果你的代码里写死了Excel.Application，在纯 WPS 环境下 CoCreateInstance 会直接返回REGDB_E_CLASSNOTREG，也就是「类未注册」。

WPS 的 COM 接口在设计上尽量兼容 Excel 的对象模型，Workbooks、Worksheets、Range、Cells这些对象名基本一致，所以迁移成本主要集中在前期的创建和释放环节。但兼容不等于等价，后面会讲到几个关键差异点。

常见做法是：先尝试KET.Application，失败再回退到Excel.Application，这样同一份代码在两种环境下都能跑。我一般会封装一个CreateExcelApp函数，把 ProgID 探测逻辑收进去，避免散落在业务代码里。

2.2 环境准备：注册表、位数与权限

在动手写代码前，有三件事必须先确认，否则后面全是玄学问题。

第一，确认 WPS 的 COM 组件已注册。打开注册表编辑器，定位到HKEY_CLASSES_ROOT\KET.Application，如果这个键存在，说明 WPS 表格的自动化接口可用。如果不存在，通常是安装时没勾选「WPS 表格组件」或者装的是精简版。

第二，确认位数匹配。你的 C++ 程序是 32 位还是 64 位，必须和 WPS 的 COM 服务器位数一致。64 位程序调 32 位 COM 服务器会失败，反之亦然。现场排查时，用任务管理器看一眼 WPS 进程的「平台」列就能确认。

第三，权限问题。如果程序以服务方式运行或者在高完整性级别下运行，而 WPS 以普通用户权限运行，COM 跨权限调用会被 UAC 拦截。常见做法是把程序清单里的requestedExecutionLevel设为asInvoker，避免不必要的提权。

提示：不要用管理员权限去跑读取 Excel 的程序，除非确实需要写系统目录。提权只会让 COM 激活更容易失败。

2.3 一个最小可跑的 COM 调用骨架

下面这段代码是读取 xlsx 的最小骨架，用KET.Application创建实例，打开工作簿，读取 A1 单元格的值。编译时需要包含<comdef.h>和<atlbase.h>，并链接ole32.lib、oleaut32.lib。

#include <windows.h> #include <comdef.h> #include <atlbase.h> #include <iostream> // 初始化 COM，尝试创建 WPS 表格应用实例 int main() { HRESULT hr = CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED); if (FAILED(hr)) { std::cerr << "COM 初始化失败: " << std::hex << hr << std::endl; return -1; } CComPtr<IDispatch> spApp; // 优先尝试 WPS 的 ProgID hr = spApp.CoCreateInstance(L"KET.Application"); if (FAILED(hr)) { // 回退到 Microsoft Excel hr = spApp.CoCreateInstance(L"Excel.Application"); } if (FAILED(hr)) { std::cerr << "无法创建 Excel/WPS 实例: " << std::hex << hr << std::endl; CoUninitialize(); return -1; } // 设置 Visible 为 false，避免弹窗 CComVariant vVisible(false); spApp.InvokeHelper(0x0000012E, DISPATCH_PROPERTYPUT, &vVisible); // Visible 的 DISPID 因版本而异，建议用 GetIDsOfNames // 打开工作簿 CComPtr<IDispatch> spWorkbooks; { CComVariant vResult; spApp.GetPropertyByName(L"Workbooks", &spWorkbooks); } CComPtr<IDispatch> spWorkbook; { CComVariant vFileName(L"C:\\test\\demo.xlsx"); CComVariant vResult; // Workbooks.Open 的参数较多，这里用 Invoke 简化示意 // 实际项目中建议用 GetIDsOfNames 获取 Open 的 DISPID } // ... 后续读取 Cells 的代码 CoUninitialize(); return 0; }

上面这段代码故意留了两个「坑点」：一是InvokeHelper里硬编码 DISPID 不可靠，不同 WPS 版本的 DISPID 可能不同；二是Workbooks.Open的参数列表很长，直接 Invoke 容易传错。下一章会给出更稳妥的封装方式。

逻辑说明：CoInitializeEx用COINIT_APARTMENTTHREADED是因为 COM 自动化对象通常是 STA 模型，用 MTA 可能导致跨线程调用异常。CComPtr是 ATL 的智能指针，自动管理引用计数，避免手动 Release 漏掉。参数方面，CoCreateInstance的第一个参数是 ProgID，第二个参数是聚合对象（通常 nullptr），第三个是上下文（CLSCTX_LOCAL_SERVER表示本地服务器），第四个是接口 IID。

3. 封装一个可复用的 WPS 读取类：从 Open 到 Range 取值

3.1 用 GetIDsOfNames 替代硬编码 DISPID

上一章的骨架里，InvokeHelper硬编码 DISPID 是个隐患。正确做法是用GetIDsOfNames根据方法名动态获取 DISPID。下面封装一个InvokeByName辅助函数，把「按名字调用」这件事统一处理。

// 辅助函数：根据方法名获取 DISPID 并调用 HRESULT InvokeByName(IDispatch* pDisp, const wchar_t* name, WORD flags, DISPPARAMS* pParams, VARIANT* pResult) { if (!pDisp) return E_POINTER; DISPID dispid; OLECHAR* names[] = { const_cast<OLECHAR*>(name) }; HRESULT hr = pDisp->GetIDsOfNames(IID_NULL, names, 1, LOCALE_USER_DEFAULT, &dispid); if (FAILED(hr)) return hr; return pDisp->Invoke(dispid, IID_NULL, LOCALE_USER_DEFAULT, flags, pParams, pResult, nullptr, nullptr); }

逻辑说明：GetIDsOfNames的第二个参数是名字数组，第三个参数是名字数量，第四个是语言环境。Invoke的flags参数决定是调用方法（DISPATCH_METHOD）还是读写属性（DISPATCH_PROPERTYGET/DISPATCH_PROPERTYPUT）。参数说明：pParams是DISPPARAMS结构，里面包含参数数组和命名参数，调用方法时参数顺序是逆序的，这点很容易搞反。

3.2 打开工作簿与读取单元格的完整流程

有了InvokeByName，打开工作簿和读取单元格就顺了。下面这段代码演示从创建实例到读取 A1 值的完整链路，关键步骤都加了注释。

// 打开工作簿并读取 A1 单元格 CComPtr<IDispatch> OpenWorkbook(IDispatch* pApp, const std::wstring& path) { // 获取 Workbooks 集合 CComPtr<IDispatch> spWorkbooks; CComVariant vWorkbooks; InvokeByName(pApp, L"Workbooks", DISPATCH_PROPERTYGET, nullptr, &vWorkbooks); spWorkbooks = vWorkbooks.pdispVal; // 准备 Open 的参数：FileName, UpdateLinks, ReadOnly, ... // DISPPARAMS 的参数是逆序的，所以最后一个参数放最前面 CComVariant vFileName(path.c_str()); CComVariant vUpdateLinks(0); // 不更新链接 CComVariant vReadOnly(true); // 只读打开，避免锁文件 VARIANT args[] = { vReadOnly, vUpdateLinks, vFileName }; DISPPARAMS dp = { args, nullptr, 3, 0 }; CComVariant vWorkbook; HRESULT hr = InvokeByName(spWorkbooks, L"Open", DISPATCH_METHOD, &dp, &vWorkbook); if (FAILED(hr)) { std::cerr << "打开工作簿失败: " << std::hex << hr << std::endl; return nullptr; } return vWorkbook.pdispVal; } // 读取指定工作表的单元格值 CComVariant ReadCell(IDispatch* pWorkbook, const std::wstring& sheetName, const std::wstring& cellAddr) { // 获取 Worksheets 集合 CComVariant vSheets; InvokeByName(pWorkbook, L"Worksheets", DISPATCH_PROPERTYGET, nullptr, &vSheets); CComPtr<IDispatch> spSheets = vSheets.pdispVal; // 按名称获取工作表 CComVariant vSheetName(sheetName.c_str()); VARIANT sheetArgs[] = { vSheetName }; DISPPARAMS sheetDp = { sheetArgs, nullptr, 1, 0 }; CComVariant vSheet; InvokeByName(spSheets, L"Item", DISPATCH_PROPERTYGET, &sheetDp, &vSheet); CComPtr<IDispatch> spSheet = vSheet.pdispVal; // 获取 Range CComVariant vAddr(cellAddr.c_str()); VARIANT rangeArgs[] = { vAddr }; DISPPARAMS rangeDp = { rangeArgs, nullptr, 1, 0 }; CComVariant vRange; InvokeByName(spSheet, L"Range", DISPATCH_PROPERTYGET, &rangeDp, &vRange); CComPtr<IDispatch> spRange = vRange.pdispVal; // 读取 Value CComVariant vValue; InvokeByName(spRange, L"Value", DISPATCH_PROPERTYGET, nullptr, &vValue); return vValue; }

逻辑说明：Workbooks.Open的参数顺序在 COM 里是逆序的，所以FileName放在args数组的最后。ReadOnly设为true是个好习惯，避免程序占用文件导致用户无法编辑。Worksheets.Item既可以传索引也可以传名称，传名称时如果工作表不存在会抛异常，实际项目中要加 try-catch 或者先遍历判断。

参数说明：DISPATCH_PROPERTYGET用于读属性，DISPATCH_PROPERTYPUT用于写属性，DISPATCH_METHOD用于调方法。DISPPARAMS的cArgs是参数个数，rgdispidNamedArgs用于命名参数（通常 nullptr），cNamedArgs是命名参数个数。

3.3 批量读取区域：比逐单元格快一个数量级

逐单元格读Cells(i, j)在数据量大时会非常慢，因为每次跨进程调用都有开销。正确做法是用Range一次性读取整个区域，拿到一个二维VARIANT数组再在本地遍历。

// 批量读取 A1:C100 区域，返回二维数组 void ReadRange(IDispatch* pSheet, const std::wstring& addr) { CComVariant vAddr(addr.c_str()); VARIANT rangeArgs[] = { vAddr }; DISPPARAMS dp = { rangeArgs, nullptr, 1, 0 }; CComVariant vRange; InvokeByName(pSheet, L"Range", DISPATCH_PROPERTYGET, &dp, &vRange); CComVariant vValues; InvokeByName(vRange.pdispVal, L"Value", DISPATCH_PROPERTYGET, nullptr, &vValues); // vValues 是一个 VARIANT，包含 SAFEARRAY if (vValues.vt == (VT_ARRAY | VT_VARIANT)) { SAFEARRAY* psa = vValues.parray; LONG lbRow, ubRow, lbCol, ubCol; SafeArrayGetLBound(psa, 1, &lbRow); SafeArrayGetUBound(psa, 1, &ubRow); SafeArrayGetLBound(psa, 2, &lbCol); SafeArrayGetUBound(psa, 2, &ubCol); for (LONG r = lbRow; r <= ubRow; ++r) { for (LONG c = lbCol; c <= ubCol; ++c) { VARIANT v; VariantInit(&v); LONG idx[2] = { r, c }; SafeArrayGetElement(psa, idx, &v); // 处理 v，注意 VariantClear VariantClear(&v); } } } }

逻辑说明：Range.Value返回的VARIANT在区域大于一个单元格时是VT_ARRAY | VT_VARIANT，维度是 2。SafeArrayGetLBound和SafeArrayGetUBound的第二个参数是维度编号，从 1 开始。参数说明：SafeArrayGetElement的idx数组是各维度的下标，顺序和SafeArrayCreate时一致。

注意：批量读取时如果区域内有公式，Value返回的是计算结果，不是公式本身。要拿公式用Formula属性。

4. 避坑与排查：那些让程序卡死或读空的细节

4.1 坑一：CoCreateInstance 返回 0x80040154

现象：程序启动后创建实例失败，错误码0x80040154，对应REGDB_E_CLASSNOTREG。

原因：ProgID 写错，或者 WPS 的 COM 组件没注册。有些 WPS 版本注册的是ET.Application而不是KET.Application，还有的只注册了WPS.Application。

解决：先用OleView或者注册表搜索确认可用的 ProgID。代码里做多级回退：KET.Application→ET.Application→Excel.Application。如果全失败，提示用户检查 WPS 安装。

4.2 坑二：打开工作簿后进程残留

现象：程序退出后，任务管理器里还有 WPS 进程，或者文件被锁定无法编辑。

原因：COM 对象没有正确释放，引用计数没归零。常见的是Workbook.Close没调，或者Application.Quit没调。

解决：用CComPtr管理所有接口指针，确保作用域结束时自动 Release。在退出前显式调用Workbook.Close(false)和Application.Quit()。如果还是残留，检查是否有IDispatch被AddRef后忘了Release。

4.3 坑三：读取空单元格返回 VT_EMPTY 导致崩溃

现象：遍历区域时，遇到空单元格程序崩溃或输出乱码。

原因：空单元格的Value返回VT_EMPTY或VT_NULL，直接当字符串用会解引用空指针。

解决：取值前先判断vt。如果是VT_EMPTY或VT_NULL，当作空字符串处理。如果是VT_BSTR，用SysStringLen判断长度。如果是VT_R8，转成字符串再拼接。

4.4 坑四：中文路径导致 Open 失败

现象：文件路径含中文时，Workbooks.Open返回失败，错误码0x800A03EC。

原因：COM 接口期望BSTR，如果传入的是char*或者编码不对，路径解析会出错。

解决：统一用std::wstring和CComBSTR。从std::string转换时用MultiByteToWideChar指定CP_ACP或CP_UTF8，不要直接强转。

4.5 坑五：Visible 属性设置时机不对

现象：设置Visible = false后仍然弹出 WPS 窗口，或者设置时报错。

原因：Visible属性必须在打开工作簿之前设置，打开后再设可能无效。另外某些 WPS 版本对Visible的 DISPID 和 Excel 不一致。

解决：创建实例后立即设Visible = false。如果InvokeByName找不到Visible，用GetIDsOfNames打印实际 DISPID 对比。实在不行，接受窗口短暂弹出，用ScreenUpdating = false减少闪烁。

5. 进阶技巧：用 IDispatch 做延迟绑定与性能验证

5.1 延迟绑定的取舍

前面所有代码都走IDispatch延迟绑定，好处是不需要导入类型库，编译期不依赖 WPS 的 tlb 文件。代价是每次调用都要GetIDsOfNames，有额外开销。如果读取频率很高，可以把常用的 DISPID 缓存起来，避免重复查询。

// 缓存 DISPID 的简单示例 class DispIdCache { std::map<std::wstring, DISPID> cache_; IDispatch* pDisp_; public: explicit DispIdCache(IDispatch* p) : pDisp_(p) {} DISPID Get(const std::wstring& name) { auto it = cache_.find(name); if (it != cache_.end()) return it->second; DISPID id; OLECHAR* n[] = { const_cast<OLECHAR*>(name.c_str()) }; pDisp_->GetIDsOfNames(IID_NULL, n, 1, LOCALE_USER_DEFAULT, &id); cache_[name] = id; return id; } };

逻辑说明：缓存以名字为键，DISPID 为值。第一次查询后写入 map，后续直接命中。参数说明：GetIDsOfNames的LOCALE_USER_DEFAULT表示用当前用户区域设置，一般不需要改。

5.2 验证读取结果是否正确

写完读取逻辑后，怎么确认拿到的值是对的？我一般用「三对照」：一是和 WPS 界面里看到的值对照，二是和用 Python 的 openpyxl 读出来的值对照，三是和公式栏里的公式对照（如果读的是 Formula）。下面这个表格列出常见数据类型对应的 VARIANT 类型，方便排查。

5.3 一个我踩过的性能坑

早期我图省事，用Cells(i, j)逐格读一个 5000 行的表，结果跑了将近 40 秒。后来改成Range("A1:F5000").Value一次性读，降到 0.8 秒。差距来自跨进程调用的次数：逐格读是 30000 次 COM 调用，批量读是 1 次。从那以后我每次写 WPS 读取代码，都强制先问自己一句「能不能一次读一个区域」，能批量就绝不逐格。希望这个习惯也能帮到你。

本文还有配套的精品资源，点击获取