企业官网建设流程全解析

简介：WPTools For XE5 是一套面向 Delphi XE5 开发者的文字处理 VCL 组件工具，支持富文本编辑、样式表、可编辑页眉页脚、书签、嵌入式图文混排、邮件合并及多格式转换（RTF/DOCX/HTML/XML/PDF）等能力，适合在桌面应用中集成高级文档功能或构建报表/模板输出场景。资源包共 547 个文件，以 dfm 窗体、pas 单元、dcu 编译产物和 dpr 工程为主，辅以 res 资源、XML 配置及少量说明文档，整体约 13.97MB，结构紧凑。包内含多套可直接运行的示例工程及图标设计源文件、位图资源，并可了解 WPReporter 循环列表生成和 SVG 渲染引擎等进阶用法。已有 18 人学习下载，适合需要深度定制文字处理组件或进行文档转换开发的 Delphi 中高级工程师参考。

1. WPTools 在 XE5 上还能不能打：先搞清它在解决什么问题

做 Delphi XE5 桌面项目的人，迟早撞上一个需求：给客户一个能编辑排版、能存 RTF、能打印的“伪 Word”。用系统自带的 TRichEdit 顶着，三页以内还行，表格、页眉页脚、图文混排一上，立刻翻车。WPTools 就是为这件事存在的商业 VCL 组件包：一个 WYSIWYG 文档内核，加上 RTF/HTML 导入导出、邮件合并、拼写检查和页面设置，装成一排组件直接拖。它历史悠久，XE5 时代恰好是它最成熟的区间。这篇笔记讲怎么在 Delphi XE5 里把它装稳、跑通、绕开典型坑，适合正在选型、或者已经拿到 License 却装不上的工程师。

2. 装进 Delphi XE5 的正确姿势：dpk 编译、Library Path 与 IDE 检查三步走

装 WPTools 和装普通 VCL 控件最大的不同：它不是 setup.exe，而是一堆 .dpk、.pas、.dcu 等着你自己编译。第一次装的人最容易卡在路径和编译顺序上。下面按我日常操作顺序讲，做完再开业务代码。

2.1 先做版本配对：XE5 用 32 位 Win32 包，别碰 FMX

WPTools 在 XE5 时代对应的是 8.x 这一代源码，压缩包里一般按 Delphi 版本分好目录，常见结构是 source 和 lib 并列，lib 下再按 Delphi 版本细分。装之前先确认手里的包确实支持 XE5，而不是 XE2、XE3 时代的老包。强装旧包往往能编过，运行期却给你看糊涂账——属性莫名丢失、打印偏移，查半天都是版本错配。

XE5 同时能编 Win32、Win64、FMX 和 Android 目标，但 WPTools 的根基是 VCL 加 Windows GDI。你只需要关心 Win32 目标。Win64 目标编出来也可能跑，但打印、RTF 流在 64 位下的验证工作量你未必愿意做；FMX 和 Android 则直接不适用，这点在第 5 章的避坑里会再展开。

2.2 把源码与 lib 目录写进 Library Path：DCU 找不到的根因

“找不到单元 WPRichText”这类报错，十有八九不是包没被 IDE 加载，而是 Library Path 里没有它的 DCU 目录。常见做法是把两段路径都加进去：一段是 WPTools 的 source 源码目录，另一段是 lib 下当前 Delphi 版本对应的输出目录。在 IDE 里走 Tools > Options > Delphi Options > Library – Win32，把路径追加到 Library Path 即可。

搜索顺序有个坑要注意：工程属性里的 Search Path 优先于全局 Library Path。如果你的项目目录里恰好放了一个旧版 WPRichText.pas，WPTools 会被这个同名文件抢答，报出一堆莫名其妙的重定义错误。另外，路径里尽量别有中文和空格；实在躲不开，就在 Library Path 里用双引号把整段路径包起来。

装完路径后，先确认运行期包的 BPL 真的生成到了 IDE 能加载的位置，再继续下一步：

:: 确认运行期包已经生成到 XE5 的 BPL 输出目录 :: XE5 对应 RAD Studio 12.0 安装目录，常见路径如下 :: 如果找不到，说明刚才编译没成功，先回 2.3 查编译错误 dir /s /b "C:\Program Files (x86)\Embarcadero\RAD Studio\12.0\bin\wptools*.bpl"

这段命令的作用是帮你从真实文件系统层面确认 BPL 存在。BPL 是 IDE 真正加载的二进制，只生成了 DCU 而没有 BPL，控件面板永远不会有东西。如果你把 WPTools 装到了自定义目录，把路径换成你自己的 bin 目录即可。

2.3 编译顺序：先 RunTime 包后 DesignTime 包，再点 Install

标准顺序是先编译运行期包（名字类似 WPTools80_RT.dpk），再编译并安装设计期包（类似 WPTools80_Design.dpk 或 dclWPTools.dpk 这类）。运行期包只 Build，不要点 Install；设计期包 Build 完再点 Install，这一步才会把组件注册进 IDE 控件面板。

打开 dpk 时 IDE 会问 base path，直接选 WPTools 解压根目录，确保生成的 .bpl 和 .dcp 落到同一套输出目录里，避免一部分进 bin、一部分散在源码目录。如果安装包里带了 .dpg 工程组文件，直接打开它一次编完最省事；没有就按先运行期后设计期的顺序手工一个个开。

装完可以通过注册表看 IDE 是否真的登记了这个包：

:: 查看 XE5 已注册的 IDE 设计期包，确认 WPTools 出现在列表里 :: 12.0 是 XE5 的注册表版本号，如果 IDE 装的是精简版，按实际版本查找 reg query "HKCU\Software\Embarcadero\BDS\12.0\Known IDE Packages" /s | findstr /i "wptools"

有输出说明设计期包已注册；没输出说明 Install 那步实际没成功，回到 2.3 开头重新编译安装。

2.4 验证三件套：控件栏、Demo 编译、帮助文档

装完别急着写业务代码，先做三个验证，按下面的表格逐项过：

其中 Demo 编译是最硬的一条验证，它会把路径、版本、位宽、编译顺序所有问题一次性暴露出来。Demo 能跑，再拖控件到自己的窗体上；拖上去不崩，才算真正装稳。走到这一步再开始业务代码，能省一整天的血泪。

3. 十分钟跑通 WPRichText 编辑器：最小代码、三个必调属性和文件读写

安装只是入场券。真正决定你用不用得下去的是 WPRichText 这个核心组件的行为方式。它和 VCL 自带 TRichEdit 完全是两套心智模型：WPRichText 内部维护的是一个带格式标记的文档对象，RTF、HTML、纯文本都只是它的导入导出格式。

3.1 最小工程：一个 WPRichText 加两个按钮，先跑通打开和保存

新建一个 VCL 工程，放一个 WPRichText1 铺满窗体，再放两个按钮，分别做打开和保存。先只处理文件读写，格式化的门道放后面。

uses WPRichText, WPIOFormatted; procedure TForm1.btnOpenClick(Sender: TObject); begin // wpFormatRTF 告诉加载器按 RTF 解析，而不是按纯文本猜 // 如果文件是 WPTools 自己的 .wpt 二进制格式，改成 wpFormatWPT WPRichText1.LoadFromFile('C:\tmp\demo.rtf', wpFormatRTF); // LoadFromFile 加载失败时不会静默吞掉，文档里会留下错误标记 // 想保证干净状态，加载前可以先调 WPRichText1.ClearDocument; end; procedure TForm1.btnSaveClick(Sender: TObject); begin // 保存时格式必须和读取时一致，否则表格和图片会丢 WPRichText1.SaveToFile('C:\tmp\demo_out.rtf', wpFormatRTF); end;

LoadFromFile 的第二个参数是 TWPIFormattedTextInputFormat 枚举，常见值有 RTF、HTML、纯文本和 WPT 原生格式。纯文本加载时默认按 ANSI 处理，要读 UTF-8 文本得看你的版本里有没有对应的 UTF-8 枚举，没有就自己用 LoadFromStream 先解码再喂进去。SaveToFile 的参数含义对称，就不再单独解释。

3.2 三个必调属性：Font、PageSetup、LoadOptions

第一组属性是字体。WPRichText1.Font 决定的是“新输入文字”的默认样式，而不是整个文档所有文字。对中文项目，先把它指到中文字体并显式设置字符集，否则后续所有中文相关的坑都会从这冒出来：

// 设置默认输入字体，避免新输入的中文被按 Western 字符集渲染 WPRichText1.Font.Name := '微软雅黑'; WPRichText1.Font.Charset := GB2312_CHARSET;

第二组是页面设置。WPRichText 的屏显分页和打印分页都依赖 PageSetup 里的纸张尺寸和边距，单位因版本而异，多数是 1/10 毫米。如果发现打印出来的 A4 宽度明显不对，就按这个量级反推修正：

// 直接代码设置 A4 纵向、左右边距 2cm // 单位以你版本 PageSetup 帮助说明为准，多数是 1/10 毫米 // 如果单位猜错，打印出来的纸张尺寸会整体放大或缩小，对比现实纸张就能发现 WPRichText1.PageSetup.PaperWidth := 2100; WPRichText1.PageSetup.PaperHeight := 2970; WPRichText1.PageSetup.LeftMargin := 200; WPRichText1.PageSetup.RightMargin := 200;

第三组是 LoadOptions 和 SaveOptions。这两个集合属性控制导入导出时对表格、图片、扩展格式的取舍。不同版本枚举成员略有差异，装完后去 WPIORTF.pas 或帮助里搜 LoadOptions 就能看到完整清单。常见做法是保持默认，只在导入 HTML 时按需关掉图片解析。千万别在一开始就把这两个属性改得面目全非，否则你会分不清丢格式是组件的问题还是你配置的问题。

3.3 读回与格式走查：Text、RTFText、HTMLText 三兄弟的区分

同一个文档对象，WPRichText 给你三个读出入口，用途完全不同。Text 返回纯文本，适合做摘要和校验；RTFText 返回 RTF 字符串，适合再给别的编辑器消费；HTMLText 返回 HTML，适合做网页预览或入 Web 端。走查时把三者都打出来对比，能快速判断文档内核有没有坏：

// 走查：用三种视图对比同一个文档 // Text 丢格式但保证内容完整，RTFText 保留精细格式，HTMLText 是给浏览器看的 Memo1.Lines.Add('纯文本前 50 字：' + Copy(WPRichText1.Text, 1, 50)); Memo1.Lines.Add('RTF 头：' + Copy(WPRichText1.RTFText, 1, 40)); Memo1.Lines.Add('HTML 头：' + Copy(WPRichText1.HTMLText, 1, 40));

这里有个性能问题值得提前说：HTMLText 对大文档很贵，几十页带图表的文档生成 HTML 可能要一秒多。不要在界面刷新里反复读 HTMLText，改完文档后再一次性取。段落级修改则常用 ActiveParagraph 定位光标所在段：

// 把光标所在段设为居中对齐，适合做工具栏按钮 WPRichText1.ActiveParagraph.Alignment := taCenter;

ActiveParagraph 随光标移动，比先找段落再赋值的写法稳得多。左对齐、右对齐、两端对齐对应枚举也都能直接赋，这是做格式刷类功能的地基。

4. 邮件合并与 RTF/HTML 互转：WPMailMerge 和格式过滤器的实战参数

多数项目用 WPTools 不只是因为它能排版，而是因为它能批量生成文档。邮件合并和格式互转是这里最常用的两个能力，也是最容易用错的两个。

4.1 邮件合并：模板字段、数据源与 Execute 三条线

邮件合并的常见做法是把 WPTools 当模板编辑器：先在 WPRichText 里写好一封带字段的信，字段用工具栏上的 Insert Merge Field 插入，在文档里显示成带灰色底纹的占位文本。运行时把数据源挂上去，Execute 一次，模板里的字段被当前记录的值替换，结果输出到新文档。核心代码结构如下：

// 常见写法：把模板字段替换成数据集当前行的值 WPMailMerge1.WPRichText := WPRichText1; WPMailMerge1.DataSource := dsCustomer; // dsCustomer 是 TDataSource，指向数据集 WPMailMerge1.MergeTo := wpMergeNewDocument; // 结果进新文档，原模板保持不动 WPMailMerge1.Execute;

这里有两个关键点。一是字段名大小写敏感，模板里写 CustomerName，代码里取数据的字段名也得完全一致，否则合并不报错，但结果里留一个空占位，看起来像玄学。二是 MergeTo 的选择决定内存表现：几万条记录的合并，输出到单个大文档会非常吃内存，常见的稳法是把 MergeTo 指向文件或打印机，逐条生成，不要把所有结果攒在一个文档里。WPTools 8.x 各版本对 WPMailMerge 的属性命名有出入，你的版本以安装包自带的 MailMerge 示例工程为准，先把 Demo 里的属性对照着抄一遍最稳妥。

4.2 RTF 与 HTML 互转：三条失真规律

WPTools 在 XE5 时代的强项是 RTF 和 HTML 之间的互转。用三句话概括失真规律：段落级样式（缩进、行距、对齐）基本保真；字符级样式（字距、上标、下划线类型）在 HTML 侧容易降级；嵌套超过两层的表格，HTML 端经常丢边框和列宽。转换代码本身不复杂：

// 转 HTML 的常用三段式：载入 RTF -> 看导出选项 -> 取 HTMLText WPRichText1.LoadFromFile('sample.rtf', wpFormatRTF); // 图片是走 Base64 内嵌还是走外部路径，由 SaveOptions 里图片相关枚举控制 // 翻到 WPTools 帮助的 SaveOptions 一节，按你的发布形态选 Memo1.Lines.Text := WPRichText1.HTMLText; // 反向：HTML 载入，再存成 RTF WPRichText1.LoadFromFile('page.html', wpFormatHTML); WPRichText1.SaveToFile('page.rtf', wpFormatRTF);

HTML 导入有个硬约束必须提前知道：WPTools 认标签上的内联 style，不认头部 style 块里定义的类。你用工具生成 HTML 时，一定要让工具输出内联样式，否则字体大小、颜色、行距全会静默丢失。反过来的 RTF 导出相对宽容，WPTools 自己生成的 RTF 拿到 Word 里打开，格式重合度很高。

4.3 什么时候别拿 WPTools 当转换服务器

边界和用法一样重要。WPTools 8.x 这一代的主战场是 RTF、HTML、纯文本，DOCX 不是它的主场。如果你的需求是“把用户上传的 DOCX 转成 PDF 预览”，不要指望 WPTools 一步到位，常见做法是把 DOCX 先经 Word 或 LibreOffice 转成 RTF，再进 WPTools 处理。另外，WPTools 本身是 VCL 组件，不是线程安全的，大批量转换不能在后台线程里直接调用同一个 WPRichText 实例。常见的稳妥方案是起一个串行任务队列，逐个处理，给用户展示进度条，而不是并发猛跑。这顿操作能让你的转换服务稳定很多倍。

5. WPTools 在 XE5 上的避坑指南：从控件面板空白到中文乱码的五段案例

下面五条是装机和日常使用里反复出现的翻车点，全部按“现象 → 原因 → 解决”的格式写，方便你对着排查。

5.1 控件面板里没有 WPTools 页

现象：编译安装全绿，IDE 没有报一个错，控件面板上却找不到 WPTools 页，或者组件全是灰的。
原因：设计期包没有 Install，或者磁盘上残留了另一个 Delphi 版本编出来的 dclWPTools 包，IDE 加载失败后直接把整包隐藏了。
解决：打开 IDE 的 Component > Install Packages，在列表里搜 wptools，有就先 Remove 再重新从设计期包 Install；同时用 2.3 节的 reg query 确认注册表登记。如果之前装过别的 Delphi 版本，先把旧版本的 wptools*.bpl 从 IDE 搜索路径里清掉，再重装当前版本。

5.2 一拖 WPRichText 到窗体，IDE 当场崩

现象：新建窗体后拖 WPRichText 上去，IDE 直接 Access Violation 退出，再打开工程设计器也打不开，只能开代码。
原因：运行期包和设计期包版本不一致，最典型的是 PATH 里同时存在两份 wptools 的 BPL，IDE 加载了旧的那份，和当前设计期包对不上。这个坑一度被当成玄学，其实就是同名 BPL 冲突。
解决：删除 bin 和系统目录下所有 wptools*.bpl，只留当前 XE5 刚编译出来的这一份，再重新 Build 运行期包并 Install 设计期包。注意删除前先关掉 IDE，不然文件被占用删不掉。

5.3 打开中文 RTF 全是乱码或问号

现象：Word 存的中文 RTF 打开后部分中文变成“?”或整段不可读，英文内容正常。
原因：RTF 文件头里没声明 GBK 代码页，WPTools 按 ANSI 西文猜字符集，中文就被拆坏；同时默认字体字符集可能是 DEFAULT_CHARSET，渲染阶段也没有可用的中文字体回退。
解决：加载前把 WPRichText1.Font.Charset 设为 GB2312_CHARSET，并指定一个中文字体名；如果文档来源可控，建议上游直接输出 UTF-8 纯文本或带正确代码页的 RTF，比在 WPTools 端反复补救省事得多。

5.4 屏显分页和打印机分页对不上

现象：编辑器里的分页线显示第 3 页，打印机出来的物理第 4 页；表格在页边界处错开半行。
原因：屏幕渲染按屏幕 DPI 粗算页长，打印机按自己的实际 DPI 重排。WPTools 的精确分页发生在打印阶段，编辑器里的分页线只是参考。
解决：打印前把页面设置对齐打印机，再执行 Print。常见写法如下，具体属性名以你版本的打印示例工程为准：

// 打印统一走打印机 DC，让 WPTools 按打印机分辨率重排 WPRichText1.Printing.AlignToPaper := True; // 枚举或属性名以你的版本 Help 为准 WPRichText1.Print;

如果你的版本没有 AlignToPaper，去 WPTools 自带的打印示例里找打印前置调用代码，照着抄。千万不要拿编辑器里的分页线当最终物理页数去给客户交付，那是把参考系当成了真值。

5.5 XE5 建 Android 目标，WPRichText 直接编不过

现象：给 XE5 工程新增 Android 平台后一编译，提示找不到单元 WPRichText，或者直接报平台不支持。
原因：WPTools 8.x 是 VCL 组件，依赖 Windows 句柄、打印机 DC 和 GDI 渲染，FMX 和 Android 根本不具备这些运行时基础。
解决：把工程平台切回 Win32，WPTools 只用于纯 Windows 客户端。移动端要预览同一份文档，常见做法是后端把 RTF 转成 HTML 或 PDF，再让移动端用 WebView 呈现，别用条件编译去硬绕，绕出来的结果只会拖垮维护成本。

6. 进阶：先学会验证再当黑匣子用：段落遍历与状态栏自检

WPTools 装好、能跑、坑也踩过一轮后，值得花一小时把编辑器界面做完整，并且给文档加一道自检手段。这两个习惯能让你在后续维护里省下大量定位时间。

6.1 用 WPToolbar、WPRuler、WPStatusBar 拼出接近 Word 的界面

WPTools 的价值在于组件完整，不只是 WPRichText 一个文本盒子。在窗体上再放一个 WPToolbar、一个 WPRuler、一个 WPStatusBar，把它们指向同一个编辑器，就能得到一套带工具栏、标尺、页码状态的编辑窗口：

// 装配示例：工具栏、标尺、状态栏都指向同一个编辑器 WPToolbar1.WPRichText := WPRichText1; WPRuler1.WPRichText := WPRichText1; WPStatusBar1.WPRichText := WPRichText1;

工具栏负责加粗、斜体、列表、表格这类高频操作，标尺负责缩进和页边距的拖动，状态栏自动显示当前页码、光标位置和插入状态。三个组件都挂在同一个 WPRichText 实例上，没有额外的同步代码，比你自己拼十个按钮和事件干净得多。注意 WPToolbar 默认没有绑定打印机图标，打印按钮需要自己接一个，方法就是调用第 5.4 节那段打印代码。

6.2 段落遍历函数：给文档加一道自检

文档对象不是黑匣子，WPTools 允许你从 FirstParagraph 出发遍历整个文档结构。我习惯在每次版本升级或批量导入后跑一个段落自检函数，确认文档没有被静默搞坏：

// 自检函数：遍历所有段落，统计空段和异常段落 // TParagraph 的类名和 Length 属性以你安装版本的单元声明为准 // 这个函数的价值是验证“文档内核健康”，不是背 API function TForm1.CheckDocHealth: Integer; var p: TParagraph; cnt: Integer; begin Result := 0; cnt := 0; p := WPRichText1.FirstParagraph; while Assigned(p) do begin Inc(cnt); // Length 是段落内有效字符数 // 空段过多，通常是循环追加文档时留下了脏段落 if p.Length = 0 then Inc(Result); p := p.Next; end; // 全空文档不算病，空段比例超过段落总数的 20% 才需要警惕 end;

这个函数帮我抓过一次真实的线上问题：一个批量生成合同的流程，连续跑了几百份之后，某份合同的开头多出了十几个空段，打印出来第一页全是白行。遍历一看，是合并模板时上一次循环的尾部残留没清干净。所以我的习惯是：每次升级 WPTools 或换 IDE 版本，第一件事就是拿这个自检函数在真实文档上跑一遍，通过了才敢把旧功能交接出去。你也值得养一个类似的小工具，希望帮到你。

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