D7与Rio下XLSReadWriteII v6.0.0.47安装避坑

简介这是一套面向 Delphi 开发者的原生 Excel 读写组件覆盖 Delphi 7 至 10.3 Rio适合需要在桌面应用中直接生成、解析与修改 xls/xlsx 文件的项目。它不依赖本机安装 Excel 或其他办公软件内置针对单元格值优化的内存管理并提供 Direct Read/Direct Write 模式便于处理较大文件XLSX 引擎按文件格式规范自动构建强调兼容性与不破坏原文件且包含完整源码、无运行时费用。压缩包共 596 个文件约 2.59MB以 248 个 pas 源码、164 个 html 文档、53 个 dfm 窗体、32 个 dpr 示例工程及 dproj、dcr、res 等工程/资源文件为主另含图表、自动筛选、透视表等示例配置便于按模块查阅与复用。已有 302 人学习适合需要稳定 Excel 导出导入、公式与透视表处理及源码级定制的 Delphi 开发者参考。1. 两套编译器下的 XLSReadWriteII v6.0.0.47先分清 D7 和 Rio 再动手上周接了个老项目机器上同时装着 Delphi 7 和 10.3 Rio想用同一套 XLSReadWriteII v6.0.0.47 读写 Excel结果组件面板里装了三次都没出现页签。这类情况很典型XLSReadWriteII 是纯 Delphi 代码的组件包不依赖 Excel也不依赖 OLE装对了一打开 IDE 就多出一个页签装错了要么启动时弹包加载失败要么编译期报单元重复。下面按 D7 和 Rio 两条线分开走从目录、库路径、包编译一路到最小可跑代码最后把卸不干净怎么救也写清楚。2. 目录与库路径v6.0.0.47 里哪几个文件夹必须被 IDE 看见拿到压缩包先别急着双击 .dpk。最常见的前十分钟浪费是把整个包解到「桌面\新建文件夹 (2)」然后一路下一步最后 dcc32 报找不到单元人开始怀疑包本身是坏的。XLSReadWriteII 这种以源码形式分发的组件包装得好不好八成取决于解压路径和库路径这两件事有没有做对编译本身反而是最简单的。2.1 解压位置Source、Packages、Bin 各管什么我固定解压到D:\SDK\XLSReadWriteII_v6.0.0.47这种路径不在系统盘、全英文、没有空格。理由不玄学——dcc32 和 msbuild 的命令行参数里一旦出现空格引号少写一个就会把路径截断报出来的错还跟路径毫无关系排查起来纯属浪费时间。放在 Program Files 下面同样容易出问题UAC 会让编译器写不进去 DCU报「Cannot create file」。解压开之后目录大致是这么分工的Source所有 .pas 单元包括主单元、表格数据单元、字体和格式单元。这个目录只需要被加进库路径不要往里写东西也不要把它拷进工程目录。Packages按 IDE 版本分的子目录里面有 .dpk 包工程D7 和 Rio 各用各的那一份。这是要编译的对象。Bin或Lib可能放着预编译好的 DCU 或者 DLL 说明。这个包的卖点之一就是不依赖外部运行库所以这里一般没有需要跟着 exe 发的东西D7 时代残留的「拷 dll 到 System32」习惯在这里用不上。工程里绝对不要把 Source 下的 .pas 添加进来当普通单元用。这么干短期能编过长期会跟包里的同名单元冲突报出来的就是那个经典的「unit 也被包含在另一个包里」。轻则要清一遍工程的搜索路径重则整个 IDE 起不来。2.2 库路径D7 填一处Rio 要填两处这一步是 D7 和 Rio 差异最大的地方也是新手最容易漏的。Delphi 7 只有一个全局库路径Tools → Environment Options → Library → Library path把D:\SDK\XLSReadWriteII_v6.0.0.47\Source追加到末尾分号隔开。D7 只有 32 位目标填一次就完事。Rio 的库路径按平台分。Tools → Options → Language → Delphi → Library右边有个下拉框要分别在「Windows 32-bit」和「Windows 64-bit」里各加一次Source路径。只在 32 位那边加了切到 64 位目标编译就报Unit XLSReadWriteII6 not found很多人第一反应是包编坏了其实是路径没跟平台走。提示加在 Browsing path 里没用。Browsing path 只影响代码跳转和提示编译期不参与看着能 Ctrl点击进源码编译照样报找不到单元。两套环境的对照如下配之前对一眼能省不少来回项目Delphi 7Delphi 10.3 RioIDE 版本 / 编译器7.0 / dcc32 15.020.0 / dcc32、dcc64 33.0默认字符串类型AnsiString中文系统 CP936UnicodeString库路径入口Tools → Environment Options → LibraryTools → Options → Language → Delphi → Library需要分别配置的平台只有 32 位Windows 32-bit 与 Windows 64-bit 各一次BPL 默认输出目录%DELPHI%\Projects\BplC:\Users\Public\Documents\Embarcadero\Studio\20.0\BplDCP 默认输出目录%DELPHI%\Projects\Dcp同上目录下的 Dcp设计期包32 位一份只有 32 位IDE 本身是 32 位进程运行期包32 位一份32 位、64 位各一份表里最后两行是关键Rio 的 IDE 是 32 位程序它只能加载 32 位的设计期包所以 64 位那份只编运行期包就够了编设计期包给 64 位没有任何意义还会因为没法注册而白折腾一遍。顺手把要用的路径变量写成一个 cmd后面编译直接复用set SRCD:\SDK\XLSReadWriteII_v6.0.0.47 set D7C:\Program Files (x86)\Borland\Delphi7 set RIOC:\Program Files (x86)\Embarcadero\Studio\20.0 set BDSCOMMONC:\Users\Public\Documents\Embarcadero\Studio\20.0SRC是解压根目录D7和RIO是两套 IDE 的安装根BDSCOMMON是 Rio 存放 Bpl、Dcp 的公共目录。这几个变量写在一个 build.cmd 里比每次手打一长串路径靠谱换机器只要改前三行。3. 编译与安装组件包D7 走 dcc32Rio 分平台编两次组件包装不装得上本质就两件事包编出来了没有IDE 找得到找不到。开发环境里双击 .dpk 走 IDE 图形界面也能编但我更习惯命令行因为报错信息完整、可复现出了问题能直接贴出来对着看不用回忆「刚才点了哪个按钮」。3.1 Delphi 7先把 BPL 和 DCP 的输出目录固定下来D7 的包工程如果直接在 IDE 里编译BPL 默认掉进%DELPHI%\Projects\BplDCU 掉进包的所在目录时间一长到处是散落的中间文件。我一般显式指定输出目录保证一个包的产物集中在一处cd /d %SRC%\Packages\Delphi7 %D7%\Bin\dcc32.exe -B -Q ^ -U%SRC%\Source ^ -NU%TEMP%\xls_dcu\d7 ^ -LE%D7%\Projects\Bpl ^ -LN%D7%\Projects\Dcp ^ XLSReadWriteII6_D7.dpk参数逐个说一下-B是全部重建改过 Source 里的单元后必须带否则可能拿旧的 DCU 链接-Q静默模式只输出错误和警告-U指定单元搜索路径指到 Source这样包工程里不用写死相对路径-NU是 DCU 输出目录扔到临时目录避免污染源码树-LE是 .bpl 输出目录-LN是 .dcp 输出目录。不同大版本的 dcc32 开关略有出入拿不准的时候跑一次dcc32 -?对一下别照抄。包文件名以你手上Packages\Delphi7里的实际 .dpk 为准不同批次打包出来的命名不完全一样别硬套我这个。编完在Projects\Bpl下应该能看到一个 .bpl在Projects\Dcp下能看到同名 .dcp两个文件对得上才算成功。3.2 Rio设计期包只编 Win32运行期包补一份 Win64Rio 这边要编两次而且是同一个 .dpk 用两个编译器各编一遍cd /d %SRC%\Packages\Delphi10_3 %RIO%\bin\dcc32.exe -B -Q -U%SRC%\Source ^ -LE%BDSCOMMON%\Bpl -LN%BDSCOMMON%\Dcp ^ XLSReadWriteII6_Rio.dpk %RIO%\bin\dcc64.exe -B -Q -U%SRC%\Source ^ -LE%BDSCOMMON%\Bpl\Win64 -LN%BDSCOMMON%\Dcp\Win64 ^ XLSReadWriteII6_Rio.dpk第一条dcc32出的 32 位包既当设计期又当运行期第二条dcc64出的 64 位包只做运行期。注意我把 64 位的产物放进了Bpl\Win64子目录不跟 32 位混在一起——同名 BPL 放在同一目录里后编的会覆盖先编的等到 64 位工程链接时才发现拿到的是 32 位文件报「不兼容的机器类型」那种错看着吓人其实特别蠢。如果包工程里同时存在设计期和运行期两个 .dpk常见做法是把 Register 过程单独放在设计期包里64 位只需要编运行期那个。设计期包里有Register和Unregisterdcc64 编得出来但 IDE 加载不了编了也白编。3.3 让 IDE 找到 BPLPATH 这条线最容易断包编出来了接下来是让 IDE 认。Delphi 7 加载包的方式比较朴素Component → Install Packages → Add选Projects\Bpl下的 .bpl。但 D7 的 IDE 在启动时要按 PATH 去找上次记录的包所以%DELPHI%\Projects\Bpl必须在系统 PATH 里或者干脆把 .bpl 拷进%DELPHI%\Bin。少了这一步当场能装成功第二天开机 IDE 弹「Cannot load package」人直接懵。Rio 这边不依赖 PATH包路径记在 IDE 自己的配置里Component → Install Packages → Add 选Bpl目录下的 32 位 .bpl 就行。但路径别选临时目录或者下载目录那些地方过两周就被清理了IDE 每次启动都会试着重加载然后失败弹窗还关不干净。装好之后看组件面板应该多出一个页签里面有几个组件把其中一个拖到窗体上如果 Object Inspector 能正常列出属性说明设计期注册成功这一步过了才轮到写代码。卸载也别图省事删文件。正确顺序是先 Component → Install Packages → 选中包 → Remove再去删 .bpl。反着来IDE 会一直记着那个已经消失的包每次启动都报一次加载失败只能去注册表里翻那才叫后悔药没处买。4. 工程侧配置从 uses 到第一个能打开的 xls环境通了接下来是工程本身。这里有两个坑跟 D7 的历史包袱强相关跟包装得好不好没关系但报出来的症状特别像安装失败。4.1 单元引用与坐标顺序[列, 行]别写反新建一个 VCL 窗体程序放一个按钮代码大致如下uses XLSReadWriteII6; // v5 系列这里是 XLSReadWriteII5类名同步换成 TXLSReadWriteII5 procedure TForm1.Button1Click(Sender: TObject); var XLS: TXLSReadWriteII6; begin XLS : TXLSReadWriteII6.Create(nil); try XLS.Sheets.Count : 2; XLS.Sheets[0].Name : 明细; XLS.Sheets[0].AsString[0, 0] : 物料编码; // [列, 行]0 基 XLS.Sheets[0].AsString[1, 0] : 数量; XLS.Sheets[0].AsString[0, 1] : A-001; XLS.Sheets[0].AsFloat[1, 1] : 12.5; XLS.Filename : D:\out\demo.xls; XLS.Write; finally XLS.Free; end; end;几点说明。单元名和类名以你装完之后组件面板上显示的为准包是按 6.x 打包的就用 6 的单元手上是 5.x 系列就把数字换掉属性名这几年基本没动过。AsString和AsFloat是按类型取值写数字别用AsString否则 Excel 里那格是文本后续求和全是 0这种问题排查起来能耗掉半天。坐标顺序是[列, 行]从 0 开始跟 Excel 的 A1 表示法正好相反写反了不会报错只是数据整片错位这是这套库最容易翻车的地方。最后Filename加Write才会落盘只赋值不写磁盘上什么都没有。4.2 D7 的中文乱码AnsiString、代码页和 UTF8StringD7 没有 UnicodeString而 xls 的 BIFF8 格式内部存的是 Unicode 字符串中间必然有一次转换转换用的就是系统默认代码页。中文系统上是 CP936正常的AsString[0,0] : 物料编码一切正常。翻车的是这几种写法把字符串先UTF8Encode再赋给 AnsiString从 UTF-8 的文本文件里读进来直接塞进去或者从网页接口拿到 JSON 没转码就用。结果是 Excel 打开一片问号或者方块人第一反应是「这组件不支持中文」其实是转了两遍或者转错了方向。// 错误UTF-8 字节流直接当 AnsiString 塞进去BIFF8 会按 CP936 再解一次 XLS.Sheets[0].AsString[0, 0] : AnsiString(UTF8Encode(物料编码)); // 正确要么保持本地编码原样写入要么显式走 WideString 让库按 Unicode 处理 XLS.Sheets[0].AsString[0, 0] : 物料编码;Rio 下不存在这个问题字符串本身就是 UnicodeString直接赋就行。如果同一个工程要同时维护 D7 和 Rio 两个版本我的做法是在公共单元里包一层ToCellStr函数用{$IFDEF VER150}区分D7 分支原样返回 AnsiString高版本分支直接返回 UnicodeString业务代码里不出现任何编码转换省得哪天又在某个角落埋一个乱码。顺带提醒一个上限xls 是 BIFF8单表 65536 行、256 列。真实报表超过这个量写入时不会崩但多出来的部分直接丢而且不报错属于典型的黑匣子行为。要么分表要么先确认业务量级再决定用不用这个格式。4.3 运行期包要不要跟着发工程里有个选项叫「Build with runtime packages」勾上意味着 exe 里不链接组件代码运行时去加载 .bpl。开发机上有 BPL跑得好好的拷到客户机上就是「找不到 XLSReadWriteII6_D7.bpl」或者更绕的「无法定位程序输入点」因为客户机上可能有个版本不一样的同名包。我的一般做法是把这个勾去掉让组件单元静态链进 exe。代价是 exe 变大一些好处是部署只有一个文件不用管 BPL 版本对不对得上内网工具机上这点体积根本不算事。如果确实要走运行期包比如多个程序共用、想减小体积那 BPL 必须跟 exe 一起发而且包名的版本后缀要严格对上升级组件时两边一起换。这些年我见过太多「开发机能跑、客户机报错」的案例最后都是这一条引起的。5. 避坑与排查五条装 XLSReadWriteII 时真踩过的记录5.1 组件面板没有页签IDE 启动还弹「Cannot load package」现象按步骤装了包重启 IDE 弹窗提示包加载失败点掉之后组件面板干干净净好像什么都没装过。原因BPL 不在 IDE 能找到的位置。D7 是靠 PATH 找的Projects\Bpl没进 PATH 就会这样Rio 是记在上次安装的绝对路径里包被移走或删掉同样报这个。解决D7 把%DELPHI%\Projects\Bpl加进系统 PATH 后重开 IDERio 重新走一遍 Component → Install Packages → Add指到实际存在的 .bpl。别在弹窗里点「忽略」了事下次启动还弹。5.2 32 位编得过64 位报Unit XLSReadWriteII6 not found现象同一个工程切到 Windows 64-bit 目标就编译失败切回 32 位一切正常。原因Rio 的库路径是按平台分开存的只在 Windows 32-bit 下加了 Source 路径64 位那边是空的。解决Tools → Options → Language → Delphi → Library把平台切到 Windows 64-bit重新加一次 Source 路径同时确认Bpl\Win64下确实有 64 位的运行期包。两件事缺一不可。5.3It contains unit ... which is also contained in package ...现象装第二个包时 IDE 直接拒绝加载提示某个单元已经被另一个包包含。原因机器上同时存在两个大版本的 XLSReadWriteII或者曾经把 Source 里的 .pas 直接加进过工程同名单元被编译了两份。解决先 Component → Install Packages 卸掉旧版本再清理工程的搜索路径确保Source目录只被当作库路径引用不作为工程单元。清完还不行就删掉工程目录下的 DCU 缓存重新构建别在旧产物上继续编。5.4 D7 导出的 xls 中文全是问号现象程序没报错文件也能打开就是中文单元格显示为???。原因字符串在写入前被转过一次编码UTF-8 字节流被当成 CP936 解释或者反过来。解决检查赋值前有没有多余的UTF8Encode、UTF8Decode从文件或接口拿到的数据先确认原始编码再转。D7 下最稳的做法是全程保持本地编码不做任何转换。5.5 客户机上双击就报找不到 BPL现象开发机运行正常拷到客户机弹「找不到 XLSReadWriteII6_D7.bpl」或rtl70.bpl。原因工程勾了 Build with runtime packagesexe 依赖外部包客户机没装 Delphi自然也没有运行期库。解决Project → Options → Packages取消勾选 Build with runtime packages重新构建后只发 exe。如果业务上必须用运行期包那就把 BPL 和必要的运行期库一起打包发过去别只发一个 exe。6. 装完怎么验证三段检查一次跑通再动业务代码装完不验证等于把问题留到业务代码写完那天。我固定跑三段十分钟内能确认这套环境是真通了还是只是「看起来装上了」。第一段验证设计期。打开 IDE看组件面板有没有多出那个页签拖一个组件到空白窗体上Object Inspector 里能正常列出属性、改一个值不报错F9 空跑一次能出窗口。这一步过不了后面全免谈。第二段验证编译期两个平台各 build 一次:: Rio 下两个目标各编一次确认库路径和包都对得上 %RIO%\bin\msbuild.exe Project1.dproj /p:ConfigRelease /p:PlatformWin32 /t:Build %RIO%\bin\msbuild.exe Project1.dproj /p:ConfigRelease /p:PlatformWin64 /t:Build两行都要绿。只编 32 位就以为万事大吉是 64 位迁移时最常见的自欺欺人。第三段验证运行期写一个文件再读回来逐项对检查项操作通过标准文件能生成执行写入代码目标目录出现 .xls大小不为 0中文正常单元格写「物料编码」Excel 打开无乱码、无问号类型正确数字用 AsFloat 写入Excel 里右对齐SUM 能算出结果坐标没写反第 1 行第 2 列写值Excel 里出现在 B1 而不是 A2读回一致用同一组件 Read 后取值值与写入时完全相同行数上限写入超过 65536 行明确知道会被截断业务侧有分表策略读回那段我一般写成一个小控制台程序Write完立刻Read把Sheets.Count、表名和前几个单元格的值打印出来。看着土但它能一次把编码、坐标、类型三件事全验掉比在 Excel 里肉眼找快得多。还有一个容易漏的检查把编译好的 exe 单独拷到一台没装 Delphi 的机器上跑一遍。这一步能立刻暴露运行期包依赖的问题早发现在自己手上晚发现就在客户现场。从那以后我每装一台新机器、每换一个 Delphi 版本都强制走完这三段再碰业务代码——组件装没装上是一回事装上了能不能稳定出一份 Excel 是另一回事中间差的那点验证时间远比事后翻日志便宜。希望帮到你。本文还有配套的精品资源点击获取