Twig raw 过滤器的作用 #

首先明确：Twig的raw过滤器不会执行编码操作，它的核心作用是关闭Twig的自动转义机制。

默认情况下，Twig会自动将变量中的特殊HTML字符（比如<、>、&等）转义为对应的HTML实体，防止XSS攻击和渲染异常。而raw过滤器就是告诉Twig：直接输出变量的原始内容，不要进行任何转义处理。它既不会编码，也不会解码，只是跳过转义步骤。

OctoberCMS DynamicPDF（DoomPdf）字符异常问题分析与解决 #

从你描述的情况来看，HTML预览正常但生成PDF时ő、ű变成?，确实可以排除Twig的问题，问题出在Dompdf（DynamicPDF基于的底层库）的渲染环节，核心原因大概率是字体不支持UTF-8扩展字符或者PDF渲染时的编码配置缺失。以下是具体的解决步骤：

1. 为PDF模板指定支持UTF-8的字体 #

Dompdf默认使用的字体（比如Helvetica）并不包含匈牙利语的特殊字符（ő、ű属于Latin Extended-A字符集），所以渲染时会用?替代无法识别的字符。你需要在PDF模板的CSS中明确指定支持这些字符的字体：

body {
    font-family: 'DejaVu Sans', sans-serif;
}

DejaVu Sans是一款开源的支持多语言字符的字体，Dompdf通常会默认包含这款字体，如果没有的话，你需要把字体文件上传到插件的字体目录，并在配置中加载。

2. 确保PDF生成时强制使用UTF-8编码 #

在控制器生成PDF的代码中，检查是否设置了正确的编码。比如在调用DynamicPDF的生成方法时，明确指定编码为UTF-8：

$pdf = PDF::loadTemplate('your-template', $data, [], [
    'encoding' => 'UTF-8'
]);

不同版本的DynamicPDF可能配置方式略有差异，你可以查看插件的文档确认编码参数的设置位置。

3. 避免不必要的raw过滤器使用 #

既然{{ name }}渲染字符正常，说明Twig的自动转义已经正确处理了UTF-8字符，此时使用raw过滤器完全没有必要——它只会输出原始字符串，而如果PDF渲染器的字体/编码配置有问题，就会出现字符丢失的情况。优先保留默认的{{ name }}写法即可。

4. 验证渲染后的HTML内容 #

如果以上步骤无效，可以在生成PDF前，先把Twig渲染后的HTML内容输出查看：

$html = Template::load('your-template', $data)->render();
dd($html); // 查看输出的HTML中ő、ű是否正常显示

如果HTML中字符正常，那100%是Dompdf的字体或编码配置问题，重点排查字体加载和编码设置。

内容的提问来源于stack exchange，提问作者zsss