如何在 mpdf 中正确显示 html 复选标记（✓）：mpdf 默认无法正确解析经典 asp 传递的 `%u2714` 类 url 编码 unicode 字符，导致 ✓ 显示为乱码；需在 php 端将 `%uxxxx` 转换为标准 html 实体 `xxxx;` 并解码为 utf-8。
当使用 classic-ASP 构建含 HTML 实体（如 ✔ 表示 ✔）的表格并 POST 至 PHP 后端生成 PDF 时，常因字符编码传输链断裂，导致 mPDF（v6.0）将 ✔ 错误解析为 %u2714（非标准 JS 风格 URL 编码），最终 PDF 中显示为文字 %u2714 而非复选标记。
根本原因在于：classic-ASP 在表单提交或字符串拼接过程中，可能对 Unicode 字符进行非标准转义（尤其在未显式设置 Response.Charset = "UTF-8" 或 Request.Charset 不一致时），而 mPDF 的 WriteHTML() 方法依赖原始 HTML 字符串的语义完整性——它不自动处理 %uXXXX 这类非 RFC 兼容编码。
✅ 正确解决方案是在 PHP 接收后、调用 WriteHTML() 前，对 $output 进行标准化预处理：
// 将非标准 %uXXXX 编码转换为标准 HTML 十六进制实体，并解码为 UTF-8 字符
$output = preg_replace('/%u([0-9A-F]{4})/', '&#x$1;', $output);
$output = html_entity_decode($output, ENT_COMPAT, 'UTF-8');⚠️ 注意事项：
立即学习“前端免费学习笔记（深入）”；
- 不要仅替换 %u2714（如 str_replace('%u2714', '✔', $output)）：该方式脆弱且不可扩展，无法覆盖其他符号（如 ✗ %u2717、→ %u2192 等）；
- 字体配置非首要问题：即使已注册 Symbola 字体，若传入 mPDF 的 HTML 字符串本身已是 %u2714 文本而非 ✔ 字符，字体再全也无济于事；
-
确保 mPDF 初始化启用 UTF-8：你已使用 'utf-8' 参数（✅ 正确），但需确认 config_fonts.php 中 symbola 字体定义后，CSS 中显式应用：
.pass_x { font-family: symbola, sans-serif; } - 避免双重编码陷阱：勿在 ASP 端用 Server.HTMLEncode() 包裹 ✔，否则会变成 ✔，PHP 端需额外 html_entity_decode() —— 推荐 ASP 端保持原始实体，专注 UTF-8 响应头。
完整修正后的 PHP 关键代码段如下：
$output = $_POST["output"];
// ✅ 标准化 Unicode 编码（关键修复）
$output = preg_replace('/%u([0-9A-F]{4})/', '&#x$1;', $output);
$output = html_entity_decode($output, ENT_COMPAT, 'UTF-8');
$mpdf = new \mPDF('utf-8', 'A4-L', 0, '', 5, 5, 20, 20);
$mpdf->allow_charset_conversion = true;
$mpdf->WriteHTML($style, 1);
$mpdf->SetHTMLHeader($header);
$mpdf->SetHTMLFooter($footer);
$mpdf->WriteHTML($output); // 此时 $output 已含真实 ✔ 字符
$mpdf->Output($temp, 'F');? 总结：mPDF 渲染符号的核心前提，是输入 HTML 字符串中已存在有效的 UTF-8 字符（而非其编码表示）。通过正则+html_entity_decode() 统一清洗 %uXXXX，可一劳永逸解决各类 Unicode 符号（✔ ✗ ★ ▲ 等）在 PDF 中的显示异常，无需修改前端逻辑或依赖特定字体加载顺序。
