PDF中文文本乱码主因是解析库未正确处理中文字体与CMAP映射；需先验证文本层有效性，再统一UTF-8编码、补全系统字体，最后OCR兜底。
Yii框架中提取PDF中文文本出现乱码，核心问题不在Yii本身，而在于PDF解析环节的编码处理和字体映射缺失。PDF-Parser-1.0、pdfplumber 或其他底层库读取时若未正确识别中文字体或CMAP表，就会把Unicode字符映射失败，输出或十六进制乱码。解决关键在于打通“PDF字体→系统字体→解析编码→PHP输出”整条链路。
确认PDF是否含可选中文文本
先排除文件本身问题：用Adobe Acrobat或Foxit打开该PDF，尝试鼠标选中中文——能选中并复制出正常汉字，说明文本层存在；若只能复制出空格、方块或乱码，大概率是扫描图或ToUnicode映射缺失。此时必须走OCR路线，跳过纯文本提取。
强制指定UTF-8输出与解码逻辑
即使PDF文本可读，Yii中echo或json_encode时仍可能因响应头或PHP内部编码不一致导致二次乱码：
- 确保config/main.php文件本身以UTF-8无BOM格式保存（用Notepad++或VS Code检查编码）
- 在控制器输出前加：header('Content-Type: text/html; charset=utf-8');
- 对提取出的字符串做兜底转换：mb_convert_encoding($text, 'UTF-8', 'auto')，避免GBK/GB2312残留
补全系统级中文字体支持
PDF-Parser-1.0或pdfplumber依赖pdfminer.six，而pdfminer对未嵌入字体的还原，需系统有对应字体文件（如SimSun、Noto Sans CJK）。Linux服务器尤其容易缺字：
- Ubuntu/Debian：运行 sudo apt install fonts-wqy-zenhei fonts-wqy-microhei
- CentOS/RHEL：sudo yum install wqy-zenhei-fonts
- 重启PHP-FPM或Web服务使字体生效
绕过字体陷阱：改用OCR兜底提取
当上述方法仍失败，说明PDF使用了自定义CID字体或CMAP异常。此时应放弃纯文本流解析，直接调用OCR：
- 用
pdf2image将PDF每页转为300dpi PNG - 调用Tesseract命令：tesseract page.png stdout -l chi_sim --psm 6
- 在Yii中用
exec()或shell_exec()捕获输出，并用iconv('UTF-8', 'UTF-8//IGNORE', $output)过滤非法字节
