EmbeddedWB在Delphi 12.3中的编译安装与实战指南

简介：面向Delphi开发者的EmbeddedWB控件完整源代码包，覆盖D5至XE12版本，基于WebBrowser技术实现嵌入式网页浏览与交互，适合需要在桌面应用中内嵌页面、抓取网页数据或自定义浏览器行为的开发场景。压缩包共226个文件，大小约2.44MB，其中包含65个pas源文件、126个dcu预编译单元、22个dpk工程文件，以及res、inc、dfm等辅助资源，既能查看原始实现，也便于重新编译集成。目前已有87人学习下载。通过分析源码可深入理解控件的事件触发与底层封装逻辑，还可利用工程文件快速装入IDE，针对下载管理、脚本注入、页面渲染等需求做定制修改，是学习和扩展EmbeddedWB功能的实用资料。

1. EmbeddedWB-D5-XE12-SRC：这个源码包解决什么问题，为什么还有人用它

看到 EmbeddedWB-D5-XE12-SRC.7z 这个包名，第一反应很可能是"都 2025 年了，还折腾 IE 内核？"这个判断对了一半。EmbeddedWB（Embedded Web Browser）是 Delphi 社区流传很多年的网页浏览器封装控件，它把 IE 内核塞进 VCL 窗体，让桌面程序里直接嵌一个能跑 HTML/JS/ActiveX 的浏览器窗口。D5-XE12 表示这套源码覆盖从 Delphi 5 到 XE 系列的一大批老版本，SRC 就是 Source，源码包。它到今天还有价值的原因很简单：大量存量系统——工控上位机、医院挂号机、企业内部帮助中心——还在用 TWebBrowser 这层老技术，而 EmbeddedWB 恰好把这些项目最头疼的 JS 互调、弹窗拦截、右键菜单屏蔽都封装好了。适合读这篇的人有两类：一类是维护老项目、被迫把新 IDE 和旧控件撮合到一起的工程师；另一类是刚开始学 Delphi、想找个能快速出界面的浏览器控件的同学。下文直接按"判断版本到底能不能用 → 编译安装 → 跑通第一个页面 → 踩坑清单 → 一个能落地的进阶用法"来写，全程围绕 Delphi 12.3 这个实际环境。

2. 装进 Delphi 12.3 之前：先看懂 D5-XE12 的版本范围和依赖关系

2.1 为什么"给 D5-XE12 的源码包"能在 12.3 编译：源码包和二进制包的根本区别

很多人拿到这种包会有一个疑问：控件明明写着支持到 XE 系列，怎么敢往 Delphi 12.3 里装？这就要分清两种分发形式。如果下载到的是编译好的 .bpl、.dcu 文件，那基本没戏，因为 DCU 内部格式和具体编译器版本强绑定，Delphi 12 的 IDE 不会认老版本的编译产物。但标题里明确写了 SRC，说明你拿到的是 .pas 源码，附带 .dpk 或 .dproj 工程文件。源码包的意义就在于：安装时由你当前这台机器上的 Delphi 重新编译一遍，生成匹配 12.3 的 DCU 和 BPL。所以只要源码没有使用当前编译器已经移除的语法或单元，理论上都能装。

打开包先做三件事，判断它的底子干不干净。第一，用文本检索工具在 .pas 文件里搜CompilerVersion或VER这样的条件编译关键字，能看到类似{$IFDEF VER230}之类的分支。有这些宏说明作者长期维护，对老版本做过分叉处理，装进新 IDE 的成功率高得多。第二，打开主单元看 uses 子句，如果出现OleServer、ActiveX、MSHTML_TLB、SHDocVw这几个名字，说明它走的是公开 COM 接口，这类代码在近几代 Delphi 里几乎没有破坏性变更。第三，看包内是否带 .inc 头文件，很多老控件用 include 文件保存公共编译选项，有它至少说明工程结构是规范的。

实际检索命令在 Windows 下用 findstr 就行，不一定要装额外工具：

findstr /S /M /C:"CompilerVersion" C:\Proj\EWB\*.pas

这条命令会在指定目录下递归搜索包含 CompilerVersion 字样的文件，并把文件路径列出来。参数/S是递归子目录，/M只显示包含匹配内容的文件名而不打印整行，/C:指定精确字符串，避免把Version之类的半截词也搜进来。搜到文件后逐个打开看条件编译块覆盖到哪个版本，如果最新只写到 VER230（对应 Delphi 10.4），说明作者最后一次适配在 XE 时代；这不代表 12.3 不能编，但要有点心理准备，总会有几个编译错误需要手工处理。

2.2 隐藏依赖：MSXML、SHDocVw、OleServer 与它们和 IE 内核的关系

EmbeddedWB 不是简单地把 TWebBrowser 换个皮肤，它直接操纵 IWebBrowser2 接口，同时用 MSXML 做 DOM 解析。编译这种控件时，机器上必须能找到几组对应的 Delphi 单元，它们的状态决定了你会不会撞上"缺文件"错误。把这些依赖摸清楚，后面编译时看到报错才不慌。

不少人在 12.3 里编译 EmbeddedWB 时卡在msxmldom.dcu not found这个错误上，第一反应是去装 MSXML SDK。其实这个报错和你系统里有没有 msxml.dll 没有关系，它是 Delphi 编译器在自己的库路径里找不到 msxmldom.pas/.dcu 单元文件。常见原因是 Library Path 里漏了 Delphi 自带的 MSXML 相关目录，或者包内自带了一份复刻的 MSXML 单元，但它所在的目录没有加进全局路径。

处理顺序有讲究：先找包内有没有 msxmldom.pas，如果有，把它所在目录加进 Library Path 并优先于系统库；如果没有，到 Delphi 安装目录下找现成的 .dcu。用 where 命令能快速定位：

where /r "C:\Program Files (x86)\Embarcadero\Studio" msxmldom.dcu

/r表示从指定目录开始递归搜索，不加/r的 where 只查 PATH。找到后把该目录追究到 Library Path 里即可。这里多说一句：尽量别把整个 Studio 安装目录加进工程搜索路径，搜索范围太大会拖慢 IDE 启动和编译速度，只加实际包含缺失 dcu 的最小目录。

2.3 包的结构：运行时包与设计时包为什么要分开装

老 Delphi 控件包通常拆成两个层次：运行时包（Runtime Package）和设计时包（Design-time Package）。运行时包的作用是让你的程序在启动时能加载这些功能单元，它只负责"跑"；设计时包则是给 IDE 用的插件，作用是让组件出现在组件面板上，双击就能拖进窗体，同时生成对应的代码。

为什么要分开？因为设计时包依赖 IDE 的 DesignIDE 等设计期单元，这部分代码如果混进运行时包，会让最终用户程序无端多出一堆 IDE 相关的 DLL 依赖。所以工程文件里经常有两个 .dpk/.dproj，一个名字朴素、用于 Build，一个名字带 D 或 Design 字样、用于 Install。命名规则每个包不一样，不能一概而论，但经验是：打开包工程后看 Project Manager 窗口，如果右键菜单里有 Install 这个动作，它多半是设计时包；如果只有 Build/Compile，那就是运行时包。12.3 里 Install 按钮是判断包类型最可靠的信号。

安装顺序也是个容易翻车的点：必须先编译运行时包，再安装设计时包。原因是设计时包会 require 运行时包里的单元，运行时包没编译好，设计时包一安装就会报"找不到某个 dcu"或依赖的 BPL 不存在。这一步顺序错了，后面所有排查都是白费。先把概念立住，下一章直接把完整的安装操作流程走一遍。

3. 在 Delphi 12.3 编译安装 EmbeddedWB：最小操作流程与验收

3.1 解压和目录规划：路径短、无中文、避开 UAC

拿到 EmbeddedWB-D5-XE12-SRC.7z，解压这一步就值得单独说。老控件对文件路径的容忍度比现代组件低得多，路径里有中文、空格、超长层级，编译时可能冒出莫名其妙的资源找不到错误，而且这类错误日志根本不提示是路径问题，只能靠猜。

建议的解压目录是类似C:\Proj\EWB这样的短路径，原因有三个。第一，避开C:\Program Files这类受系统保护的目录，原因不用多解释，UAC 会在编译写 dcu 时拦截你。第二，不要带中文，老 Pas 源码里有些硬编码的 include 路径在处理非 ASCII 字符时会给编译器添乱。第三，整个包解出来后目录层级别太深，三层以内最好，7z 包本身可能已经带了多层目录结构，再往深处放，IDE 搜索路径就容易碰到 Windows 路径长度上限。

如果你已经把它解压到了类似E:\下载\老项目存档\EmbeddedWB-D5-XE12-SRC这种很长的路径，懒得手工搬迁，可以用 robocopy 一键复制到短路径：

robocopy "E:\下载\老项目存档\EmbeddedWB-D5-XE12-SRC" C:\Proj\EWB /E /COPY:DAT

/E会复制所有子目录，包括空目录；/COPY:DAT只复制数据、属性和时间戳，不复制 NTFS 安全权限，这样可以避免文件被带上原来机器的 ACL 导致本机读写受限。对比直接用资源管理器复制，robocopy 的优势是长路径支持更稳，中途失败还能续传。复制完建议顺手打开源码目录看一眼，确认 .pas 和 .dpk 都在第一层或第二层，别解压出个压缩包套压缩包。

3.2 添加 Library Path：Win32 与 Win64 各加一遍

EmbeddedWB 这类老控件在 12.3 里编译能不能过，很大程度取决于 Library Path 配得对不对。Library Path 是编译器搜索单元的全局路径，它和工程的 Search Path 不同：工程搜索路径只对当前工程生效，Library Path 对整个 IDE 的所有工程生效。控件包就是要加进 Library Path，因为组件安装后，后续任何工程用到它时，编译器都要能找到对应单元。

具体操作路径在 Delphi 12.3 中是 Tools > Options > Language > Delphi > Library > Library Path。打开后注意左上角有平台下拉框，默认显示的是 32-bit Windows。这里有个容易被忽略的点：加完 Win32 路径后，要手工切到 64-bit Windows 再加一遍。很多人只加了当前选中的平台，结果新建一个 64 位工程时立刻报找不到 EmbeddedWB，又回头查半天。

推荐加进去的目录是包里放源码的那个文件夹，一般叫 Source。如果你把整个包根目录加进去，IDE 会去扫描示例工程、资源文件、文档，不仅拖慢搜索速度，还可能出现单元名冲突——示例里同名 pas 覆盖了正经源码，这种问题排查起来非常费时间。加完之后可以不关闭设置窗口，直接切到 Use 界面的其他平台确认两处都已写入。

判断路径是否生效有个简单方法：随便新建一个空 VCL 工程，在代码里敲一个 EmbeddedWB 单元里特有的类名，如果自动补全能弹出来，说明搜索路径已经接上了。这个方法比看设置界面更直观，我每次配置完都会这么验一下。

3.3 编译运行时包并安装设计时包：右键菜单的正确用法

路径配好，接下来就是正式的编译安装。先在项目管理器里把包工程加载进来。操作路径是 File > Open Project，然后在文件对话框里把文件类型筛选改为 Delphi Package（.dpk，.dproj），找到你判断为运行时包的那个文件打开。打开后项目树上会出现这个包，右键可以看到 Compile 和 Build 两个动作，快捷键分别是 Ctrl+F9 和 Shift+F9。这里用 Build 更稳妥，理由是 Build 会重新编译所有依赖单元，而 Compile 会尝试增量编译，老包换到新 IDE 后增量编译经常误判，认为某些旧 DCU 还能用，导致链接出一堆牛头不对马嘴的错误。

Build 通过后，再 File > Open Project 打开设计时包，此时右键菜单里会多出一个 Install 动作。点击 Install，弹出的对话框里能看到这个 BPL 被注册进 IDE 的包列表。如果这里弹出"无法加载包"或"不是有效的 Delphi 包"之类的错误，多半是前一步运行时包没 build 好，或者你拿错了文件——拿运行时包来 Install 就是这个结果。安装成功后，组件面板会多出一个页签（常见叫 EmbeddedWB 或相关名字），里面躺着 EmbeddedWB 这个主控件。

这一整步没有捷径，有些人为了省事直接把两个包都打开，一起右键 Build 再一起 Install，如果两个包之间存在依赖关系，这种操作顺序经常失败。老老实实先装运行时包、再装设计时包，一般一遍过。在这个环节还经常遇到缺某个单元路径的报错，别急着去翻包，先回 3.2 把报错单元所在的目录补进 Library Path，再重新 Build。

3.4 新建工程验收：拖入组件并跑通第一个 Navigate

装完之后别急着开心，做一个最小验收工程，确认组件真的能编译进用户程序。新建一个 VCL Application，平台选 32 位 Windows，往窗体上拖一个 EmbeddedWB 组件，再放一个按钮和一个 Edit。在按钮 OnClick 里写一行导航代码：

procedure TForm1.Button1Click(Sender: TObject); begin EmbeddedWB1.Silent := True; EmbeddedWB1.Navigate(Edit1.Text); end;

Silent := True的作用是屏蔽 IE 内核的脚本错误弹窗。老网页里经常有一些无关紧要的 JS 报错，不屏蔽的话，每加载一页都可能蹦一个"在此页上的脚本造成 Internet Explorer 运行速度减慢"之类的对话框，非常干扰体验。Navigate是异步操作，传入字符串是目标 URL，可以是https://或file:///开头的地址，执行后立即返回，真实加载完成发生在后台。

运行程序，在 Edit 里输入一个本地 HTML 文件的 file:// 地址，点按钮，窗体里应该出现页面内容。如果出现空白页，大概率不是控件问题，而是 IE 渲染模式过旧，这个坑放第五章细说。如果出现的是"类未注册"或"对象名未找到"，那说明安装的包有问题，或者 Library Path 和实际安装路径不一致。最小验收能过，说明 EmbeddedWB 已经正式在 Delphi 12.3 里活下来了，可以进入实际业务开发。

4. 让 EmbeddedWB 真正干活：导航时机、JS 互调与弹窗拦截

4.1 DocumentComplete：判断页面真正加载完成的三个信号

EmbeddedWB 的导航是异步的，Navigate刚返回时页面可能还没有任何内容，马上访问 DOM 或执行脚本大概率扑空。判断页面加载完成的可靠信号有三个：Busy 属性变成 False、触发 DocumentComplete 事件、以及执行某条 JS 能拿到预期结果。其中 DocumentComplete 是最常用的，但很多人直接在事件里无脑写逻辑，遇到页面里有 iframe 就翻车。iframe 加载完成也会触发 DocumentComplete，事件参数里带回来的 pDisp 是当前触发者的接口，和顶层窗口的 pDisp 不是同一个值。

正确写法是用 Application 属性判断这次完成事件是不是顶层页面发出来的：

procedure TForm1.EmbeddedWB1DocumentComplete(ASender: TObject; const pDisp: IDispatch; const URL: OleVariant); begin if pDisp = EmbeddedWB1.Application then StatusBar1.Panels[0].Text := '页面完成: ' + EmbeddedWB1.LocationURL; end;

pDisp是这次完成事件对应的浏览器对象，Application是控件持有的顶层浏览器对象，两者相等才说明整个页面加载完了。LocationURL比事件参数里的 URL 更可靠，因为重定向之后，参数 URL 可能是初始地址，而 LocationURL 是最终地址。在这一步不要急着做复杂的页面解析，先确认 URL 是自己期望的，再后续操作。

4.2 Delphi 调用页面 JavaScript：ExecScript 是最稳的入口

Delphi 侧往页面里注入脚本，最常用的方法是调用 ExecScript。这个方法是 EmbeddedWB 封装好的，可以直接把一段 JavaScript 代码作为字符串丢给页面执行，免去手工拿 IHTMLDocument2 接口再操作窗口对象的麻烦。

if EmbeddedWB1.ExecScript( 'document.getElementById("saveBtn").click();', 'JavaScript') then Label1.Caption := '脚本已注入' else Label1.Caption := '脚本注入失败';

ExecScript 返回 Boolean，表示脚本有没有成功送进页面执行环境，但它不能告诉你脚本内部有没有抛异常。比如脚本里引用了不存在的对象，返回仍然是 True，执行却以失败告终。所以关键逻辑最好在脚本层面自己包一层容错，或者通过 Delphi 回调接收结果。第二个参数是脚本语言，老版本常见写法是'JavaScript'，有的包也接受'JScript'，安装后先用最简单的alert('test')试一下哪个字符串被接受。测试时建议直接把 alert 屏蔽关掉，否则会被弹窗淹没。

脚本字符串里的中文和特殊字符要注意，ExecScript 传入的是 Pascal 字符串，脚本里的内容要符合 JS 语法。如果数据里有单引号，直接拼接会把整个脚本弄崩。常见的做法是先将数据进行转义再拼脚本，字符串内容里的\和'都要转：反斜杠换成\\，单引号换成\'。

function JSStringQuote(const AValue: string): string; begin Result := StringReplace(AValue, '\', '\\', [rfReplaceAll]); Result := StringReplace(Result, '''', '\''', [rfReplaceAll]); end;

StringReplace的最后一个参数[rfReplaceAll]是必须的，不带它默认只替换第一处，遇到多条记录时脚本就会错乱。把用户输入、数据库字段这类动态数据拼进 JS 之前过一遍这个函数，能省掉大量玄学报错。

4.3 页面里的 JS 反向呼叫 Delphi：最老但最灵的"协议拦截"方案

业务场景里经常有页面想通知 Delphi 侧做点事，比如点网页上的按钮触发本地打印、从页面把表单数据交回桌面程序。实现途径有好几条，最稳的其实是 IE 时代流传下来的"伪协议拦截"思路。原理简单：页面里把location.href赋一个自定义协议地址，比如myapp://action?name=abc，EnbeddedWB 在导航开始前会触发 BeforeNavigate2 事件，Delphi 侧在这里截住这个地址，解析参数后自己处理，同时把本次导航 Cancel 掉，不让 IE 真的去打开这个未知协议。

procedure TForm1.EmbeddedWB1BeforeNavigate2(ASender: TObject; const pDisp: IDispatch; const URL: WideString; const Flags: OleVariant; const TargetFrameName: OleVariant; const PostData: OleVariant; const Headers: OleVariant; var Cancel: WordBool); var AAction: string; begin if Pos('myapp://action?', LowerCase(URL)) = 1 then begin AAction := Copy(URL, Pos('?', URL) + 1, MaxInt); DoMyAction(AAction); Cancel := True; end; end;

Pos返回第一次出现子串的位置，用LowerCase(URL)是为了让页面里写MyApp://还是myapp://都能命中。Copy(URL, Pos('?', URL) + 1, MaxInt)取出问号后面所有内容，这里的 MaxInt 表示取到字符串末尾。Cancel := True是本方案的核心，忘记写它会触发系统弹窗，提示"没有关联程序来执行这个操作"。这个方案的优点是跨版本最稳定，不依赖任何 COM 注册。缺点也明显，URL 长度有限制，不适合传大段数据，传结构化内容时建议用 Base64 编码塞进参数，或者拆成多条消息按顺序传。

4.4 弹窗、右键与脚本错误：进场先关掉三样东西

用 IE 内核的控件做桌面程序，弹窗管理是最影响体验的部分。网页里的 alert、confirm 会以 IE 对话框的样式弹出来，和桌面程序风格完全不搭；右键菜单是浏览器默认的"查看源代码、刷新"那一套，和业务无关；脚本错误弹窗会在每个页面加载时报错。这三样东西进场第一件事就要处理。

alert 和 confirm 的拦截方式是找 EmbeddedWB 事件列表里 ShowMessage 相关的动作。每个版本的事件命名略有差异，但大致逻辑一致：设一个 Handled 标志为 True，表示这个弹窗由 Delphi 自己处理，然后根据业务弹一个 MessageDlg。需要注意的是 confirm 有返回值，不像 alert 只需要关闭，所以在确认框的场景里，要把 MessageDlg 的返回值转成确认标志再赋回去，不同版本的包返回值位置不一样，以事件参数说明为准。

右键菜单的关闭通常是属性开关，到对象检查器里搜 Menu 或 Popup 相关的属性，把浏览器默认菜单相关的项置 False。这个开关在不同版本里位置很分散，不需要死记，直接把对象检查器的搜索框里敲"Menu"过一遍，把看起来像浏览器专属菜单的选项都关掉就行。脚本错误弹窗则交给 Silent 属性统一处理，设成 True 之后大部分脚本错误不会再打扰用户。但注意 Silent 也会连 with 一些有意义的错误信息一起吞掉，调试阶段建议先保持 False，上线前再开。

5. 避坑清单：老包装进新 IDE 的 5 个高频故障

5.1 msxmldom.dcu not found：先查 Library Path，再查包内依赖

现象：编译 EmbeddedWB 包时，编译器在早期阶段就报msxmldom.dcu not found，整个工程停在这个错误上。初次接触的人会以为是系统缺 MSXML 组件，去下载安装包重装系统组件，结果问题依旧。

原因：这个错误的本质是编译器在搜索路径里找不到 msxmldom.pas/.dcu 单元文件。Delphi 自带 MSXML 相关单元，但不同版本里存放它的目录有差异，未必默认加在 Library Path 中。另外有些 EmbeddedWB 源码包会内置一份修改过的 msxmldom 单元，如果包内这份文件没有被搜索路径覆盖到，就会报错。

解决：先用 where 命令在 Delphi 安装目录里定位已有的 msxmldom.dcu，把所在目录加进 Library Path。如果包内自带 msxmldom 相关 pas 文件，优先使用包内的，并把它的目录放到路径列表前端，避免和系统库版本冲突。改完路径后重启 IDE 再编译，路径配置缓存有时候不会热加载。

5.2 BPL 安装后 IDE 提示"不是有效的包"：八成拿运行时包当了设计时包

现象：在 Project Manager 里打开某个 .dpk，右键 Install，弹出错误"不是有效的 Delphi 包"或"无法加载包"，组件面板上什么都没多出来。

原因：Windows 上的 .bpl 本质是个 DLL，运行时包和设计时包虽然喝着同一个项目名，但内容不同，设计时包额外引用了 IDE 的 DesignIDE 等设计期单元。运行时装包试图 Install 进 IDE，IDE 加载它时发现没有设计期注册代码，直接拒绝。

解决：确认你打开的是设计时包。常见做法是把包内所有 .dproj 都看一遍，文件名带 D 或 Design 字样的优先。更可靠的判断方法是打开包工程后，直接看右键菜单里有没有 Install，没有的就不是。如果包内只有运行时包而没有设计时包，那就只能用"运行时包 + 代码里手动创建组件"的方式使用，组件不会出现在面板上。

5.3 网页白屏或"此页面已停止工作"：渲染引擎版本过旧

现象：EmbeddedWB 安装成功，能编译能运行，但 Navigate 一个现代网站时，窗体白屏，或者显示"此内容在此版本中不可用"，更有甚者直接弹"Internet Explorer 已停止工作"。

原因：IE 内核的渲染模式默认可能停留在旧版本（IE7 兼容模式），对现代 CSS、ES6 语法支持不够，页面整个渲染失败。EmbeddedWB 本身不控制渲染模式，它用的是系统 IE 的设置，必须通过注册表给程序指定浏览器版本。

解决：在 HKCU 的 FeatureControl 键下，为你的主程序 exe 名称创建 REG_DWORD 值，设置 IE 版本。常用值是 11001，对应 IE11 Edge 模式。

reg add "HKCU\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION" /v MyApp.exe /t REG_DWORD /d 11001 /f

/v后面的 MyApp.exe 必须是程序的实际文件名，包括扩展名，写成别的名字不生效。/d 11001是数据，11001 表示 IE11 Edge 模式，11000 是 IE11 标准模式，平时用 11001 兼容性最好。需要注意 32 位和 64 位程序的注册表视图问题：32 位程序写注册表时会被重定向到 WOW6432Node 节点，64 位程序则写原生的位置，不放心就把两个位置都写一遍。改完注册表要重启程序，运行时改不会热生效。

5.4 中文 URL 与页面乱码：Unicode 交接的旧账

现象：Navigate 一个带中文参数的 URL，比如https://example.com/查询?key=中文，页面能加载但中文参数变成问号；或者页面本身显示正常，但通过 ExecScript 传中文进去，页面里拿到的是乱码。

原因：从 Delphi 2009 开始，默认字符串类型是 UnicodeString，但老控件内部很多地方仍然按 Ansi 处理，特别是 URL 拼接和脚本注入这两条路径。Delphi 侧传过去的 Unicode 字符串被隐式转成 Ansi 时，代码页对不上，中文字符直接变成 ？。这个问题在高版本 Delphi 上特别典型，属于老控件最常见的隐性翻车点。

解决：给 URL 参数做显式编码，把中文转成百分号编码再拼进 URL，这是跨版本最安全的做法。编码函数用 System.NetEncoding 里的 TNetEncoding.URL，把整段中文参数编码后再拼接。脚本注入则统一走上一章写的 JSStringQuote，先转义再拼接。另外页面本身建议用 UTF-8 编码并写明 meta charset，避免页面内容解码和二重编码叠加出乱码。这几个点同时处理，中文问题基本能压下来。

5.5 新版网页打不开：认清边界，把外部页面甩给系统浏览器

现象：内嵌网页加载公司 OAuth 登录页能出来，但 Google、新版视频网站这类强依赖现代浏览器特性的页面要么白屏要么报错，改造 JS 也救不回来。

原因：IE 内核在 2022 年之后被微软彻底停止支持，现代网页不会为 IE 做兼容，你的 EmbeddedWB 再调高仿真版本，也解决不了 WebGL、Service Worker 这些能力缺失。

解决：这类问题不该从控件层面解决，而要从架构上划清边界。EmbeddedWB 只渲染系统内部页面，凡是面向公网或第三方服务的 URL，检测到就交给系统浏览器。落地代码也不复杂，ShellExecute 一行：

uses Winapi.ShellAPI; procedure TForm1.OpenExternal(URL: string); begin ShellExecute(0, 'open', PChar(URL), nil, nil, SW_SHOW); end;

ShellExecute的第一个参数 0 表示不依赖父窗口，'open'动作会调用系统默认浏览器打开，SW_SHOW让新窗口正常显示。在 BeforeNavigate2 里判断域名，如果命中外部分流名单，Cancel := True 并调 OpenExternal，就不会出现"内嵌页面打不开，用户又不知道怎么复制链接"的尴尬。这套做法不是妥协，而是让 IE 内核干它擅长的事，把现代网页交给现代浏览器。

6. 进阶：用 EmbeddedWB 做"Delphi 播放 PPT"的三种落地方案

6.1 为什么这个老需求特别适合 EmbeddedWB

很多工控和办公系统里有个经典需求：在程序里播放培训 PPT。老的实现方式是让 IE 内核调用本机 Office 的 ActiveX 插件，把 PPT 直接嵌进浏览器控件，这也是 EmbeddedWB 这类控件在当年被大量选型的原因。但新版 Office 和 Windows 已经移除了 IE ActiveX 支持，"直接打开 .ppt 文件"这条路基本断了。如果项目必须保留内嵌播放体验，有三种替代路径，按可靠程度排序：PPT 转图片、转 PDF 或转长图。转图片最稳，不依赖任何插件，只要页面能显示；转 PDF 需要客户端装了 PDF 控件；用 Office Online 嵌入则必须联网。建议优先走转图片方案。

6.2 图片版 PPT 翻页页面的最小模板

假设你已经把 PPT 导出成了 slide1.png 到 slide12.png，放到程序目录下的 slides 文件夹，用下面这个 HTML 做一个翻页页面：

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <style> body { margin:0; background:#333; } #slide { width:100vw; height:100vh; object-fit:contain; } </style> </head> <body> <img id="slide" src="slides/slide1.png" alt="PPT 第 1 页"> <script> var n = 1, total = 12; function go(step) { n += step; if (n < 1) n = 1; if (n > total) n = total; document.getElementById('slide').src = 'slides/slide' + n + '.png'; } document.onkeydown = function(e) { if (e.key === 'ArrowRight' || e.key === ' ' ) go(1); if (e.key === 'ArrowLeft') go(-1); }; </script> </body> </html>

HTML 里object-fit:contain让图片在窗口缩放时保持完整比例，不裁边。JS 里go(step)是翻页函数，step 为正数表示下一页，负数表示上一页。页面里绑定了键盘事件，屏幕右侧方向键和空格键都能触发。把这个 HTML 文件路径交给 EmbeddedWB 导航，窗体里就能获得一个稳定的翻页 PPT 播放器。往后要加幻灯片编号、显示当前页数，在 HTML 里补充 DOM 操作就行，完全不用动 Delphi 代码。

6.3 最后验证三步：加载、执行 JS、拿回结果

控件安装完、示例跑通后，养成固定验证三步的习惯。第一步验证页面加载：Navigate 一个本地 HTML，等 DocumentComplete 触发，看 LocationURL 是否正确。第二步验证注入：ExecScript 一段修改页面标题的脚本，比如document.title = 'OK'，再读页面标题确认值被改掉了。第三步验证回调：用伪协议方式让页面触达 Delphi 事件，确认 BeforeNavigate2 拦截到了自定义 URL。三步全通，说明这个包的导航链路、注入链路和回调链路都活着，可以放心投入业务。这套验证方法同样适用于以后升级 IDE 或换个老控件包时，做回归测试。我现在的习惯是，不管什么老控件装进新 IDE，先编一遍、再跑这三个最小用例，全过才继续往项目里接，免得在业务代码里排查控件兼容性，浪费的时间远超现在这几分钟。希望帮到你。

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