企业官网建设流程全解析

简介：这是一套面向 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+点击进源码，编译照样报找不到单元。

两套环境的对照如下，配之前对一眼能省不少来回：

表里最后两行是关键：Rio 的 IDE 是 32 位程序，它只能加载 32 位的设计期包，所以 64 位那份只编运行期包就够了，编设计期包给 64 位没有任何意义，还会因为没法注册而白折腾一遍。

顺手把要用的路径变量写成一个 cmd，后面编译直接复用：

set SRC=D:\SDK\XLSReadWriteII_v6.0.0.47 set D7=C:\Program Files (x86)\Borland\Delphi7 set RIO=C:\Program Files (x86)\Embarcadero\Studio\20.0 set BDSCOMMON=C:\Users\Public\Documents\Embarcadero\Studio\20.0

SRC是解压根目录，D7和RIO是两套 IDE 的安装根，BDSCOMMON是 Rio 存放 Bpl、Dcp 的公共目录。这几个变量写在一个 build.cmd 里，比每次手打一长串路径靠谱，换机器只要改前三行。

3. 编译与安装组件包：D7 走 dcc32，Rio 分平台编两次

组件包装不装得上，本质就两件事：包编出来了没有，IDE 找得到找不到。开发环境里双击 .dpk 走 IDE 图形界面也能编，但我更习惯命令行，因为报错信息完整、可复现，出了问题能直接贴出来对着看，不用回忆「刚才点了哪个按钮」。

3.1 Delphi 7：先把 BPL 和 DCP 的输出目录固定下来

D7 的包工程如果直接在 IDE 里编译，BPL 默认掉进%DELPHI%\Projects\Bpl，DCU 掉进包的所在目录，时间一长到处是散落的中间文件。我一般显式指定输出目录，保证一个包的产物集中在一处：

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，运行期包补一份 Win64

Rio 这边要编两次，而且是同一个 .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和Unregister，dcc64 编得出来但 IDE 加载不了，编了也白编。

3.3 让 IDE 找到 BPL：PATH 这条线最容易断

包编出来了，接下来是让 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、代码页和 UTF8String

D7 没有 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 后重开 IDE；Rio 重新走一遍 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 packages，exe 依赖外部包；客户机没装 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:Config=Release /p:Platform=Win32 /t:Build "%RIO%\bin\msbuild.exe" Project1.dproj /p:Config=Release /p:Platform=Win64 /t:Build

两行都要绿。只编 32 位就以为万事大吉，是 64 位迁移时最常见的自欺欺人。

第三段验证运行期，写一个文件再读回来，逐项对：

读回那段我一般写成一个小控制台程序，Write完立刻Read，把Sheets.Count、表名和前几个单元格的值打印出来。看着土，但它能一次把编码、坐标、类型三件事全验掉，比在 Excel 里肉眼找快得多。

还有一个容易漏的检查：把编译好的 exe 单独拷到一台没装 Delphi 的机器上跑一遍。这一步能立刻暴露运行期包依赖的问题，早发现在自己手上，晚发现就在客户现场。

从那以后我每装一台新机器、每换一个 Delphi 版本，都强制走完这三段再碰业务代码——组件装没装上是一回事，装上了能不能稳定出一份 Excel 是另一回事，中间差的那点验证时间，远比事后翻日志便宜。希望帮到你。

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