简介这是一套基于PDFium开源渲染引擎的Delphi/CBuilder PDF处理组件包面向在桌面应用中实现PDF查看、导航、文本提取与编辑的开发者支持Delphi/CBuilder 5至10.3和Lazarus 2.0.6。包内共1010个文件以671个dcu编译单元、46个obj、44个hpp、35个pas源码、31个dpk工程文件为主并含res/dcr资源、demo示例、帮助文档及dll运行库压缩包共23.75MB结构清晰便于直接安装或对照源码二次编译。已有617人浏览学习。价值在于版本中带有全部源代码开发者可深入阅读PDFium渲染与编辑逻辑按需修改扩展同时提供多版本工程和BPL设计期包可在Rad Studio与Lazarus环境中灵活集成。1. 为什么你会去下这个 PDFium 完整源码包而不是找现成 DLL拿到这份Winsoft_PDFium_Component_Suite_5.4_for_5-10.3_FULL_SOURCE.rar时我正被 Delphi 10.3 项目里 PDF 编辑组件收费和 DLL 版本冲突轮番折磨。这套号称“完整源码”的套件不是把编译好的 BPL 丢给你而是把 PDFium 的 Delphi 封装层源码全部摊开从 Delphi 5 到 10.3 的工程文件按版本分好目录。它适合两类人一类是手里有老项目要补 PDF 渲染、编辑、合并能力又不想被闭源控件绑定另一类是喜欢自己编译、愿意看底层单元源码的 Delphi 开发者。它能解决的很直接解析 PDF、逐页渲染、提取文本、填表、合并都能绕开商业授权写进你自己的程序里。下文我按“先看清楚里面有什么再装进 IDE跑通第一个渲染绕开典型翻车点最后谈编辑合并”的顺序把这份资源从 rar 变成实际能跑的组件。2. 先拆包看结构一份完整源码套件该怎么入手拿到 rar 后的第一件事不是急着解压到 Delphi 安装目录而是把压缩包当成一个工程集来盘点。完整源码包和普通安装包最大的差别是它把每个 Delphi 版本的编译差异都留在工程文件里目录结构、包依赖、DLL 放置路径都隐藏了作者跨版本维护的思路。如果你的 Delphi 是 10.3却一上来就打开默认的 D5 目录后面编译报错会非常难看。2.1 用 unrar 列表看清源码包的骨架我一般先把压缩包内容导出来看不直接解压unrar l Winsoft_PDFium_Component_Suite_5.4_for_5-10.3_FULL_SOURCE.rar listing.txtWindows 下没装 unrar用 7-Zip 打开压缩包选择“信息”或直接右键查看列表也能达到同样效果。打开 listing.txt 后重点过滤三类文件后缀为.dpk、.dproj的包工程文件后缀为.pas、.dcu的源码单元以及带D5、D7、D10_3、XE8这类版本标号的目录。你要用 Delphi 10.3就先圈出带D10_3的目录其余版本目录暂时不用看。再看有没有Demo、Examples目录有的话先打开示例工程因为示例工程里通常已经配置好了环境变量和搜索路径比手动猜路径可靠。这个步骤的本质是建立“源码地图”。完整源码包为了兼容 5 到 10.3 这么大的跨度会把版本相关的代码拆成条件编译块比如{$IFDEF UNICODE}、{$IFDEF VER300}如果直接打开错误版本的工程IDE 自动加的搜索路径可能会指向不存在的 DCU于是出现满屏红色。先列清单你至少知道这套源码里哪个目录是运行时包、哪个是设计时包后面安装时不至于把二者搞混。2.2 看包和依赖确实不是 PDFium 的 C 源码这里有一个非常容易误判的点。包名写的是“PDFium Component Suite”但它不是给你编译 Google PDFium C 引擎的那份源码。PDFium 引擎本体几乎总是以 DLL 形式分发这份FULL_SOURCE指的是 Delphi 封装层源码TPDFDocument、TPDFPage这些 Pascal 组件通过LoadLibrary或静态导入去调用pdfium.dll里的 C 接口。你手上能改的是 Delphi 封装PDFium 核心解析器仍然是 DLL。判断方法很简单解压后看有没有一堆.dll或.lib文件。如果只有 Win32/Win64 子目录各放一个pdfium.dll源码目录里放PDFium.pas、PDFiumTypes.pas这类 Pascal 单元那就是我刚才说的结构。这种方式的工程意义在于你可以在 Pascal 层做二次封装比如自定义异常、缓存页面对象、做线程安全包装但底层 PDFium Crash 时你依然没有源码可调。所以如果你的需求是改 PDFium 内核、自研深度页面解析那这份包帮不上忙如果只是想把 PDFium 稳定地接进 Delphi 业务系统这份源码完全够用。包内另有设计时注册单元负责把组件拖到 IDE 面板上运行时包和设计时包分离也符合 Delphi 组件开发的基本标准。看清楚这一点就不会在遇到渲染异常时浪费时间翻 Delphi 封装以外的东西。2.3 选 Release 编译还是 Debug 编译一个马上影响体积的决定安装到 IDE 之前建议先想清楚编译配置。封装层 Debug 版本会保留完整调试信息BPL 体积变大而且在某些 Delphi 版本上会和 IDE 自带的运行时包冲突Release 版本精简更适合集成到业务工程。常见做法是第一次装包用 Release后续需要追踪封装层内部调用栈时才临时切 Debug。命令行编译 Delphi 包的写法很多我常用的是先用 IDE 打开工程确认搜索路径没问题再手动选配置因为 IDE 会补很多命令行难模拟的路径变量# 路径以你解压后的实际目录为准 cd D:\PDFiumSuite\Packages\D10_3 msbuild PDFium_D10_3.dproj /p:ConfigRelease /p:PlatformWin32/p:ConfigRelease和/p:PlatformWin32是两个最容易改错的开关。Config 控制 BPL 是否带调试信息Platform 控制目标平台Win32 能同时兼容 32 位和 64 位 Delphi IDE 的组件安装但如果要交付原生 64 位 EXE后面还得再编译一次 Win64。编译完会输出.bpl和.dcp.bpl是运行时组件包.dcp给 IDE 辨认符号用。往别的机器分发时千万别把.dcp放到运行目录运行期只认.bpl和pdfium.dll。这里还有一层容易被忽略的依赖某些 PDFium 封装包在编译时会把FPDF_*函数地址写死成静态链接。静态链接的优点是程序启动时就能发现 DLL 缺失缺点是换 DLL 版本就必须重编封装。动态加载则把 DLL 版本问题往后移运行到LoadFromFile才报错。看单元源码的initialization段能看到是LoadLibrary(pdfium.dll)还是external pdfium.dll这决定了你后面换 DLL 的成本。2.4 把 pdfium.dll 放到哪个目录才算数封装层加载 DLL 的策略大致分两类一类是在initialization段直接LoadLibrary(pdfium.dll)另一类是用静态导入库。动态加载的好处是 DLL 缺失时程序还能启动静态导入则一启动就要求 DLL 在位。无论哪种我的建议都是强制把解压出的 DLL 放到 EXE 同目录随后把该目录加入 PATH。放在系统盘、IDE 目录或依赖 Delphi 的搜索路径都会在不同系统上产生“找到了但版本不对”“找不到却无提示”的玄学问题。提示PDFium 是持续演进的引擎不同版本对 PDF 2.0 特性、字体回退算法的支持差异不小。包内自带 DLL 版本通常经过作者验证建议不要用系统里别的软件塞进来的旧版pdfium.dll顶替字体渲染和解析结果都可能不一致。这里给一张目录优先级表参考目录位置效果适用场景EXE 同目录最稳定版本隔离正式交付推荐IDE 的搜索路径目录影响全局容易拿错 DLL仅调试时临时用Windows System32系统级污染不推荐删除时麻烦3. 把组件装进 Delphi 10.3 并跑通第一页渲染这一章解决两件事组件怎么出现在组件面板上以及第一个能跑的渲染程序怎么写。很多资源下载之后卡在“不知道装哪个包”其实看目录名就能判断带Run或Runtime后缀的包先编译安装带Design、DT后缀的包后安装顺序不能反。3.1 安装包先装运行时再装设计时顺序不能反完整源码包安装标准顺序是“运行时包 → 设计时包”。运行时包提供实际类和函数设计时包负责把组件注册到组件面板设计时包依赖运行时包顺序反了会直接报错。具体操作为在 Delphi 10.3 里File Open打开 D10_3 目录下的运行时.dpk在工程管理器里右键Build然后Install再打开设计时.dpk重复同样操作。安装完成后组件面板会多出 PDFium 分类或类似名称里面能看到TPDFDocument组件。安装时如果弹出“无法定位程序输入点”或“无法加载包”先不要暴力点确定。常见原因有两个一是 IDE 的运行时包路径里已经存在旧版本 BPL卸载旧包或清空C:\Users\用户名\AppData\Roaming\Embarcadero\BPL下同名文件二是包引用了不在搜索路径里的 DCU需要在Project Options Packages Runtime Packages里把源码目录加入Library Path。装好后我习惯先把TPDFDocument拖到窗体上不写代码先看属性窗口有没有暴露DLLFileName、PDFiumVersion这类属性。有的话说明封装支持运行时指定 DLL 路径多环境部署会灵活很多。3.2 最小代码加载 PDF 并把第一页渲染成 TBitmap装好后写个最小验证程序确认 DLL 和封装都正常。下面代码以 VCL 窗体、放置一个TButton和TImage为例procedure TForm1.Button1Click(Sender: TObject); var Doc: TPDFDocument; Page: TPDFPage; Bmp: TBitmap; begin Doc : TPDFDocument.Create(Self); try Doc.LoadFromFile(C:\Temp\demo.pdf); Page : Doc.Pages[0]; // PDFium 页索引从 0 开始 Bmp : TBitmap.Create; try Bmp.Width : Round(Page.Width * 1.5); Bmp.Height : Round(Page.Height * 1.5); Page.Render(Bmp.Canvas.Handle, 0, 0, Bmp.Width, Bmp.Height, 0); Image1.Picture.Bitmap : Bmp; finally Bmp.Free; end; finally Doc.Free; end; end;这段代码的每一步都有讲究。LoadFromFile内部依赖FPDF_LoadDocument路径字符串在封装层会转成 UTF-16所以中文路径大多能正确处理Doc.Pages[0]返回页句柄用TPDFPage包住后可以取宽高。Page.Render实际调用FPDF_RenderPageBitmap参数里第一个是目标 DC 或位图句柄0, 0是起点宽高参数实现缩放最后一个参数是旋转角度传 0 表示原始方向。这里Page.Width和Page.Height默认单位是点1/72 英寸直接赋给TBitmap在 96 DPI 屏幕上会偏小所以乘 1.5 比较接近实际尺寸。如果你手上的封装 API 签名不同比如Page.Render(Bmp, 0, 0, Scale, 0)注意查源码里的实际声明不一定都是 DC 句柄开头。实际项目里 PDF 不一定来自文件路径常见场景是从数据库读字节流再渲染。很多封装支持LoadFromStream我习惯把字节流转成TMemoryStream再传入var MS: TMemoryStream; begin MS : TMemoryStream.Create; try MS.WriteBuffer(ABytes[0], Length(ABytes)); Doc.LoadFromStream(MS); finally MS.Free; end; end;这种用法对SaveToStream同理适合做不落盘的 PDF 合并工具。要注意的是流对象在加载、渲染完成前不能释放否则页面对象访问的是无效内存表现为随机崩溃或页内容错乱。这是 PDFium 封装里最常见的生命周期问题之一。3.3 常用方法速查一页纸看明白这个套件的边界功能常见调用形式对应 PDFium 底层打开 PDFDoc.LoadFromFile(path)FPDF_LoadDocument页数Doc.PageCountFPDF_GetPageCount取页Doc.Pages[i]FPDF_LoadPage渲染到 DCPage.Render(dc, x, y, w, h, rotate)FPDF_RenderPageBitmap取文本Page.ExtractText()FPDFText_GetText保存副本Doc.SaveToFile(path)FPDF_SaveAsCopy关闭文档Doc.CloseFPDF_CloseDocument表里最后一行Doc.Close值得单独说。封装容易在对象释放时自动调Close但如果你用同一个TPDFDocument实例反复加载不同文件忘记显式Close会累积页句柄。我一般用一个页面就立即释放页对象整个文档处理完马上Doc.Close避免 VCLFree通知机制里访问已释放句柄。4. 避坑PDFium 集成时最容易翻车的五个现场这一章写的都是我实际遇到或帮同事排查过的问题。PDFium 本身是 C 库接到 Delphi 的 VCL 世界里大多数坑不是算法问题而是版本、路径、生命周期和字符编码。4.1 装了包却提示“无法定位程序输入点”现象程序运行到Doc.LoadFromFile时弹窗“无法定位程序输入点 FPDF_... 于动态链接库 pdfium.dll”。原因EXE 运行时找到的pdfium.dll和编译封装时用的 DLL 版本不一致。完整源码包里通常按 Win32/Win64 放了一份 DLL但系统 PATH 或 IDE 搜索目录里存在另一份旧版本程序从旧目录加载了它。解决打开封装单元找到记录版本号的常量或FPDF_GetVersion调用编译后输出版本号再写一行ShowMessage看实际 DLL 路径。强制做法是运行时用绝对路径说话如pdfium.DLLFileName : ExtractFilePath(Application.ExeName) pdfium.dll;4.2 64 位系统上 32 位 EXE 加载 DLL 莫名失败现象同一个 EXE在 32 位 Windows 上运行正常在 64 位 Windows 上报找不到 DLL。原因打包时把pdfium.dll的 64 位版本放进了目录32 位进程就是加载不了表现为“找不到”或“不是有效的 Win32 程序”。解决严格区分目录32 位 EXE 配 Win32 目录里的 DLL64 位 EXE 配 Win64 版本不要用一个大而全的 DLL 同时对付两种架构。检查方式在代码里用{$IFDEF WIN64}分支指定不同文件名或子目录。4.3 中文路径加载失败但英文路径一切正常现象LoadFromFile(D:\资料\合同.pdf)返回 False 或抛“文件不存在”改成D:\pdf\contract.pdf就好了。原因封装层的LoadFromFile要么接受AnsiString要么在内部把字符串做了一次不正确的转型中文被截断。解决在全 Unicode 工程里强制传入String类型不要手写成PAnsiChar如果封装提供LoadFromFileW这类宽字符重载优先使用。在源码里搜索AnsiString能找到罪魁祸首。另一个隐藏坑是文件路径里含点号或空格PDFium 和 Windows API 都支持但某些封装会先 Split 一下路径自己把第一个点后的内容当成扩展名截掉。4.4 渲染结果和 Adobe 打开的不一样字体变方块现象同一个 PDFAdobe Acrobat 显示宋体程序渲染成方框或乱码。原因PDF 里没有嵌入字体子集渲染时依赖系统字体目标机器缺字体或字体名映射不一致。解决先看 PDF 文档属性里的字体列表再确认目标机器是否安装对应字体。如果必须跨多台机器优先在 PDF 生成阶段就嵌入字体或调用封装层的字体映射回调指定C:\Windows\Fonts\simsun.ttc。这个坑还经常表现为“只有文字异常、图形正常”让人误以为是渲染参数问题其实根源只是字体回退列表太短。4.5 长循环渲染后内存只涨不降现象循环处理几百个 PDF任务管理器里内存从 200MB 一路涨到 2GB单个 PDF 处理完后内存也不回落。原因每页GetPage得到的TPDFPage对象没释放或者Render创建的临时位图没销毁PDFium 的页句柄和位图句柄必须手动关闭不能完全依赖 Delphi 对象析构。解决每页处理完立刻Page.Free或Doc.ClosePage(Page)渲染用的TBitmap放在try...finally里释放。更保险的做法是在封装层源码里检查TPDFPage.Destroy是否真的调用了FPDF_ClosePage如果只有注释没有调用就打补丁修复。5. 不只是浏览用这套封装做编辑、合并与生成的实用路子PDFium 组件在很多人印象里只能渲染其实封装到 Delphi 这层后创建页面、导入页面、填表单都能做。下面三组代码比渲染更接近“PDF 编辑组件”这个定位。5.1 创建新 PDF 并写入一段文字PDF 不像 Word 那样自由编辑排版PDFium 更适合“在页面上按坐标绘制内容块”。新建页面并写字可以这样写var Doc: TPDFDocument; NewPage: TPDFPage; begin Doc : TPDFDocument.Create(nil); try NewPage : Doc.AddPage(595, 842); // A4 尺寸 NewPage.Font : Doc.AddFont(SimSun); NewPage.TextOut(72, 720, 这是用 PDFium 封装的页面); Doc.SaveToFile(new_page.pdf); finally Doc.Free; end; end;逻辑说明AddPage(595, 842)创建一页空白页面AddFont(SimSun)在 PDF 内部创建一个字体资源渲染时在目标机器查找中文字体TextOut(72, 720, ...)的坐标系以左下角为原点距离底边 720 点、左边 72 点和 VCLTCanvas的左上角原点完全相反。第一次写 PDF 的人十有八九在这里上下颠倒想要页面顶部留 72 点应该写Page.Height - 72。如果你要做跨机器分发尽量用 PDF 标准 14 字体中的Helvetica或嵌入字体避免依赖目标机字体。5.2 合并两个 PDF不是把页“复制”过去是导入页面对象合并 PDF 时如果直接复制页面对应对象会丢失共享资源因为字体、图片、颜色空间往往放在源文档的根对象里。常见做法是使用 PDFium 的FPDF_ImportPages封装。假设封装层提供这样一个接口DocDest.ImportPages(DocSrc, 1,2,4, 0);第一个参数是源文档第二个参数是页范围字符串第三个参数是插入位置。导入后源文档的共享资源会在目标文档中重建不会出现“字体变方块”。这里最坑的是页码从 1 开始而Pages[i]的索引从 0 开始两者差一页。1-3表示第 1 到第 3 页1,2,4表示三页。很多人在合并时把Pages[0]的索引当成字符串页码传进去结果合并结果总是少一页或错位。我一般会写一个转换函数把 0 基索引转成 1 基字符串再传。5.3 表单填写工具能做一半证书签章要另想出路填 PDF 表单是电子签章、报销流程里的常见需求。PDFium 对 AcroForm 的支持包括读取字段、设置字段值、触发计算脚本但不会帮你做业务校验。封装层把字段暴露成类似Doc.GetField(i)的接口使用时要先判断字段类型if Doc.GetFieldCount 0 then for i : 0 to Doc.GetFieldCount - 1 do if Doc.GetField(i).FieldType 1 then // 1 表示文本字段 Doc.GetField(i).Value : 某字段值;FieldType 1对应的常量在源码里通常是PDF_FIELDTYPE_TEXT不要凭记忆写数字直接引用常量。签名域比文本域复杂得多FPDF_FFL_SetFieldValue只能设置显示值不能完成合规数字签名流程。要生成真正带证书的电子签名还得配合密码学库合成 PKCS#7 再调底层句柄这部分想靠 PDFium 组件完全打通不现实做产品选型时需要把边界划清楚。6. 最后留一手验证这套 PDFium 组件是否真的在干活一套完整源码包部署完还得验明正身。我正式把它并入业务项目之前会写一个版本探针加载文档后用组件暴露的版本接口打印 PDFium 的版本号和编译日期ShowMessage(Format(Build: %s, [Doc.PDFiumVersion]));如果拿不到类似1.8.1.2018的字符串说明封装没有开放版本接口。这时直接看物理文件更可靠右键 EXE 目录里的pdfium.dll查看文件属性里的“产品版本”。两个版本号一对比心里就有底了。验证渲染一致性的另一个小技巧是把渲染出的位图保存为 24 位 PNG再和 Adobe Acrobat 导出的图像做像素级对比重点看文本边缘、矢量线宽、半透明对象。字体不齐是字体问题颜色发灰则要检查渲染参数里的FPDF_REVERSE_BYTE_ORDER和灰度标志。这里有一个我一直保留的习惯因为 PDFium 默认渲染配置和 Acrobat 的平滑策略不完全一样直接用同一份 PDF 截图对比时可能发现有细微差异。遇到这种情况先不急着改封装而是用FPDF_GetViewerPreference读取文档本身对渲染的偏好很多差异是文档自己设置的。之前有个同事以为是组件 bug折腾半天才发现是渲染时没启用抗锯齿。从那以后我每次换pdfium.dll版本或升级封装包都会强制走一遍“加载-渲染-对比”三步流程确认版本号、路径、像素结果全部一致才允许合并进主干代码。这个习惯救过我很多次因为 PDFium 各版本之间的行为差异确实存在而且很难从升级日志里看出来。希望这个验证习惯对你也有用少走我走过的弯路把手上这套 PDFium 源码包尽快用到真项目里。本文还有配套的精品资源点击获取