通过文件头和%%EOF标记可快速验证PDF合法性：先读开头最多1024字节查找%PDF-及版本号，再反向扫描末尾1024字节确认%%EOF存在；但仅此不足以保证可渲染，高可靠性需用libpoppler或pdfium做轻量加载校验。
如何通过文件头（Magic Number）快速验证PDF合法性
直接读取文件前4–8字节，比打开解析快得多，也更安全。PDF规范要求每个合法文档以%PDF-开头（ASCII码），后面紧跟版本号（如%PDF-1.7）。但注意：仅检查开头不够——有些恶意文件会伪造头部，而真正合法的PDF还必须在文件末尾存在%%EOF标记（虽不强制在最后1024字节内，但绝大多数阅读器只认靠近结尾的这个标记）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::ifstream以std::ios::binary模式打开，不加载全文，只读前8字节判断是否匹配"%PDF-" - 若匹配，再跳转到文件末尾约1024字节范围，反向扫描找
%%EOF（避免整文件扫描） - 别依赖
stat()或扩展名——report.pdf.exe或invoice.bin都可能实际是PDF
为什么不能只靠fopen + fread简单读5字节就下结论
因为PDF允许在%PDF-前插入任意数量的空白、注释或二进制垃圾（比如某些生成工具会在开头嵌入版权声明或加密标识）。标准明确允许“header line前最多1024字节的垃圾数据”（ISO 32000-1 §7.5.2）。所以只读前5字节可能错过真实header。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 读取文件开头最多1024字节，逐行查找以
%PDF-开头的行（注意行尾可能是\r\n或\n） - 用
std::string::find配合"%PDF-"子串搜索，而非固定偏移读取 - 找到后，检查其后是否为数字+小数点+数字（如
1.7），避免误判%PDF-ATTACK这类伪造字符串
用libpoppler或pdfium做深度校验的适用场景
当业务要求100%确认可被渲染（比如服务端预览、批量转图），光看magic number和%%EOF仍不够。例如：交叉引用表损坏、对象流解压失败、关键对象缺失，都会导致PDF无法打开——但文件头和结尾依然合规。
实操建议：
立即学习“C++免费学习笔记（深入）”；
-
libpoppler的PDFDoc构造函数会执行轻量初始化，失败则返回nullptr；它比完整渲染快，适合做“可加载性”判断 -
pdfium需调用FPDF_LoadDocument，成功返回非nullptr句柄，失败时FPDF_GetLastError()可区分是格式错误还是内存不足 - 二者都需链接大型库、处理线程安全（如
FPDF_InitLibrary只能调一次），不适合高频、低延迟校验场景
常见误判案例与绕过检测的PDF变体
有些PDF故意破坏常规结构来规避扫描：比如把%%EOF拆成两段写在不同位置、用/ObjStm压缩流隐藏关键对象、甚至将整个文件AES加密后再加PDF头（此时%PDF-真实存在，但内容不可解析）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对安全敏感场景（如邮件附件过滤），不要仅依赖客户端校验逻辑——服务端应结合
file命令（调用libmagic）、静态特征+轻量解析双校验 - 警惕
%PDF-后紧跟异常字符（如%PDF-\x00\x01），这常是混淆手法 - 用
hexdump -C filename | head -20手动验证时，注意Windows记事本保存的PDF可能被转成UTF-16并插入BOM，导致开头变成ff fe 25 00 50 00 44 00...
