麒麟系统下PDF转Word时中文乱码或格式错乱如何解决？

Question

在麒麟操作系统（Kylin OS）下将PDF转为Word时，常因中文字体缺失、OCR引擎不支持GB18030/UTF-8编码或LibreOffice/WPS for Linux对PDF文本层解析能力不足，导致中文显示为方框、乱码或段落错位。典型表现为：复制文本出现“□□□”，表格塌陷，页眉页脚丢失，或简繁体混排异常。该问题并非单纯软件兼容性问题，根源在于麒麟系统默认未预装完整中文字体（如Noto Sans CJK、Source Han Serif），且多数开源PDF工具（如pdf2text、poppler-utils）未启用中文语言包与OCR后处理。此外，部分PDF为扫描图像型（无文本层），若未调用支持中文的OCR引擎（如PaddleOCR或Tesseract-CHI），直接转换必然失败。需结合字体配置、OCR适配与格式保留策略协同解决。

Answer 1

```html

一、现象层：典型故障表征与日志线索定位

• 复制PDF文本出现“□□□”或“”——字体映射失败的直接信号
• LibreOffice Writer中段落缩进错乱、首行悬挂失效——Unicode双向算法（BIDI）未启用或GB18030解码链断裂
• WPS for Linux打开后页眉页脚空白、表格边框消失——PDF结构树（Tagged PDF）解析器缺失CJK语义支持
• dmesg | grep -i font 显示 Fontconfig warning: no elements found——系统级字体缓存未重建

二、配置层：麒麟OS字体生态重构

麒麟V10 SP1默认仅预装fonts-wqy-microhei（文泉驿微米黑），但该字体不包含GB18030全字符集（缺7万+汉字），且无OpenType GPOS/GSUB特性，无法支撑Word级排版。需执行：

sudo apt update && sudo apt install -y fonts-noto-cjk fonts-source-han-serif-cn ttf-wqy-zenhei
sudo fc-cache -fv
sudo ln -sf /usr/share/fonts/noto-cjk /usr/share/fonts/truetype/noto-cjk

验证命令：fc-list :lang=zh-cn | grep -E "(Noto|Source|WenQuanYi)" 应返回≥3个完整字体族。

三、工具链层：PDF解析引擎选型与中文适配

工具	是否支持Tagged PDF	GB18030解码	OCR嵌入能力	麒麟兼容性
poppler-utils (pdfinfo/pdftotext)	✓（需-raw参数）	✗（默认Latin1）	✗	需编译--enable-zlib --with-cairo
pdf2text (Python-pdfminer.six)	✓（Laparams.detect_vertical=True）	✓（decode='utf-8'）	✗	pip3 install --no-binary :all: pdfminer.six
Apache PDFBox (Java)	✓（PDPageContentStream）	✓（setEncoding("GB18030")）	✓（Tesseract桥接）	需OpenJDK 11+及fontconfig-java补丁

四、OCR层：扫描型PDF的端到端中文识别闭环

对图像型PDF，必须构建PaddleOCR v2.6+推理流水线（非Tesseract-CHI，因其在ARM64麒麟上无预编译wheel）：

pip3 install paddlepaddle-gpu==2.4.2.post112 paddlenlp==2.6.2
git clone https://github.com/PaddlePaddle/PaddleOCR.git
cd PaddleOCR && python3 tools/infer/predict_system.py \
  --image_dir="/path/to/pdf_pages/" \
  --det_model_dir="./inference/ch_PP-OCRv4_det_infer/" \
  --rec_model_dir="./inference/ch_PP-OCRv4_rec_infer/" \
  --cls_model_dir="./inference/ch_ppocr_mobile_v2.0_cls_infer/" \
  --use_gpu=True --gpu_mem=2000

关键配置：rec_char_dict_path指向ppocr/utils/ppocr_keys_v1.txt（含GB18030前15000码位），并启用--rec_char_type ch。

五、格式保真层：从文本提取到Word DOM重建

graph LR
A[PDF输入] --> B{是否含文本层？}
B -->|是| C[PDFBox提取带位置信息的TextChunk]
B -->|否| D[PaddleOCR输出JSON：{x,y,width,height,text}]
C & D --> E[基于坐标聚类生成Paragraph Block]
E --> F[按CSS Box Model计算margin/padding/border]
F --> G[用python-docx构建Section/Paragraph/Table对象]
G --> H[注入Noto Sans CJK SC字体族与UTF-8编码]
H --> I[保存为.docx]

六、验证与兜底策略

• 自动化校验脚本：docx2python test.docx | grep -o "□\|" | wc -l 结果应为0
• 简繁体混排测试：使用opencc -i input.txt -o output.txt -c zhs2zht.ini验证转换前后字形一致性
• 兜底方案：当表格塌陷时，启用tabula-py独立抽取表格区域，再merge至docx的Table对象
• 性能监控：systemctl status fontconfig.service 确保守护进程活跃，避免fc-match超时

```