PHP DOMDocument 保存 HTML 为什么会改写字符：编码声明、实体与输出对比

后台把一段中文 HTML 交给 DOMDocument::loadHTML() 后，页面看起来没少字，但保存出来的字符串却变成了 你 一类实体，连原来的标签顺序也有变化。这个现象通常不是中文“被破坏”，而是解析器没有从输入中可靠识别字符集，随后又按 DOM 的规则重新序列化。

先把问题拆成“输入字节是什么编码、解析器按什么编码读、保存时输出什么编码”三段，再谈实体是否需要还原；不要只改 $dom->encoding 就期待结果不变。

先看清字符改写发生在哪一段

排查时最容易混在一起的是“原始字符串”“DOM 节点里的文本”和“最终保存字符串”。下面这个最小案例故意不在输入片段里放字符集声明，便于观察路径：

价格：￥99，城市：上海';

$dom = new DOMDocument('1.0', 'UTF-8');
$dom->loadHTML($html);

echo $dom->saveHTML();

这里的 DOMDocument('1.0', 'UTF-8') 只是创建对象时的声明，并不能替代 HTML 输入本身的编码提示。真正决定解析结果的关键节点是 loadHTML：它先把字符串交给 HTML 解析器，再把文本和元素存入 DOM。只有在最后调用 saveHTML 时，DOM 才被重新写回 HTML 字符串。

输入没有明确声明时，中文为什么容易变成实体

传统 DOMDocument::loadHTML() 使用 HTML 解析规则读取字符串，字符集识别依赖输入内容中的声明和底层解析库的行为。对 UTF-8 中文片段，稳妥做法是让待解析内容带有明确的 UTF-8 元信息，而不是事后只设置对象属性。

价格：￥99，城市：上海';
$input = ''
    . ''
    . ''
    . $fragment
    . '';

$dom = new DOMDocument('1.0', 'UTF-8');
$dom->loadHTML($input);
$output = $dom->saveHTML();

加入声明后，解析器有机会按 UTF-8 读取输入，中文文本在 DOM 中就不会因为错误的默认判断而先走一轮错误转码。注意这里说的是“有机会”：如果上游已经把 UTF-8 字节错误地转换过，DOM 层无法凭空恢复原文，仍要回到 HTTP 响应头、文件实际编码和字符串来源检查。

不要用实体形式判断文本是否正确

HTML 中的  、数字实体或直接出现的中文，都可能表示同一个文本节点。更可靠的验收方式是读取节点的 textContent，再用 mb_strlen 或明确的 UTF-8 字节检查确认内容，而不是直接对比 saveHTML() 的字面字符串。

saveHTML 改写标签和实体，是序列化而不是原文回放

DOMDocument 保存的是节点树，不是原始 HTML 文本的编辑器缓存。调用 saveHTML() 时，解析过的元素、属性和文本会被重新序列化，因此可能看到自动补齐的 html、head、body，属性引号变化，或特殊字符改用实体表示。

如果业务需要保留原始空白、属性顺序或非标准标签写法，DOM 就不是合适的“无损字符串替换器”。此时应使用 HTML 解析器允许的结构化修改，或者在明确风险后选择字符串级处理；不要把序列化输出当成原文快照。

PHP 8.4 的 Dom\\HTMLDocument 适合什么场景

PHP 手册已经提示，传统 DOMDocument::loadHTML() 按 HTML 4 解析，和现代浏览器使用的 HTML5 规则存在差异。PHP 8.4 新增的 Dom\\HTMLDocument 提供 createFromString()、createFromFile() 和 saveHtml()，当输入包含现代 HTML5 结构时，优先评估这个接口。

saveHtml();

迁移时要先确认运行环境是否启用了 DOM 扩展，并用实际页面做回归：重点检查自定义元素、语义化结构、实体、空白和错误处理。旧代码如果依赖 DOMDocument 自动补齐的节点，切换解析器后不要只看“能否输出字符串”，还要检查节点查询结果是否改变。

一套不绕圈的编码验收流程

1. 记录输入字符串来自文件、HTTP 响应还是数据库，并确认上游声明和真实字节一致。
2. 给 HTML 输入提供明确的 UTF-8 元信息，再调用 loadHTML。
3. 在 DOM 中按节点读取 textContent，确认中文、人民币符号和不间断空格等关键字符。
4. 调用 saveHTML 后只验收语义和浏览器显示，不要求输出字面与输入逐字一致。
5. 若页面依赖 HTML5 解析差异，在 PHP 8.4 环境单独对比 Dom\\HTMLDocument 的节点树。

这里别急着用 html_entity_decode 对整段结果做一次“修复”。实体是否应该解码取决于它处在文本节点、属性值还是脚本数据中，盲目全局替换可能制造新的 HTML 结构问题。

常见问题

设置了 DOMDocument 的 encoding，为什么结果仍然变了？

对象编码声明不能替代输入 HTML 的字符集识别。应同时检查输入声明、真实字节和解析库，再看保存阶段的序列化结果。

saveHTML 输出实体，是不是说明中文乱码？

不一定。实体是 HTML 表达字符的一种形式，读取 DOM 节点的 textContent 并在浏览器中按正确响应头显示，才能判断文本是否真的错误。

什么时候应该改用 Dom\\HTMLDocument？

当项目运行在 PHP 8.4 或更高版本，且要按现代 HTML5 规则解析复杂文档时，可以优先评估它；迁移前要用真实页面回归节点结构和错误处理。

小结

DOM 处理 HTML 的核心变化是：输入先被解析成节点树，输出再由节点树重新生成。把编码声明放在输入识别阶段，把实体当作合法序列化形式，把 HTML4 与 HTML5 解析差异纳入回归范围，字符改写就不再是只能靠猜的现象。