为什么有些 PDF 文件特别难压缩？聊聊 Inline Image 与 XObject 的冷门差异

有些 PDF 明明不大，看起来却“压不动”

我之前在做 PDF 压缩功能时，遇到过一个很奇怪的案例：文档里只有几页图片，肉眼看也不算清晰，但不管怎么处理，体积就是压不下来。后来深入分析结构，才发现罪魁祸首是 —— Inline Image。

PDF 里图片其实分两种

大多数开发者知道 PDF 能嵌入图片，却不知道图片实现方式不止一种：

1. XObject Image：图片被作为一个资源对象复用；
2. Inline Image：图片数据直接“塞”进内容流里。

这两个名字看起来差不多，但对压缩、渲染和后期处理的影响，非常大。

Inline Image 的隐蔽问题

Inline Image 就像把图片原始数据写在页面指令里，通常用于小图标、点位标记。但一些不太讲究的导出程序，会把大图也用 Inline 方式嵌入，结果就会出现几个问题：

• 图片无法在多个页面中复用；
• 压缩算法难以下手，因为内容流和图像数据混在一起；
• OCR 或再编辑工具识别成本变高。

你看到的是“几页 PDF”，实际上却像塞满了“散落在各处的图片碎片”。

而 XObject Image 更适合结构化处理

XObject 的设计更工程化：

• 图片是独立资源，可以复用；
• 压缩策略可单独优化；
• 清晰的尺寸、色彩空间、编码方式描述。

所以很多专业 PDF 编辑器更爱处理 XObject。

怎么判断你的 PDF 使用了哪种图片方式？

如果你手边没有专业检查工具，也可以从现象侧面判断：

• 压缩后几乎不变 —— 可能 Inline 居多；
• 拆分页面时体积不成比例地增大 —— 也很可疑；
• 编辑器很难选中单张图片 —— 大概率 Inline。

当然，最稳妥的方式还是用 PDF 结构查看工具，看是否存在 BI…EI 结构（典型 Inline Image 标记）。

开发中可以注意的几个细节

如果你参与 PDF 生产链的开发，这几点经验挺实用：

1. 能用 XObject，就不要让大图走 Inline；
2. 优先选择支持图像复用的导出库；
3. 归档类文档，尽量保持结构清晰，而不是只追求“显示正常”。

最后的小结

PDF 这个格式的有趣之处在于：同一效果，可以有多种实现方式。看起来只是“放了一张图”，背后却藏着结构、压缩、渲染和长期可维护性的问题。

当你下一次遇到“怎么压都压不下去”的 PDF，可以尝试看看 —— 会不会又是 Inline Image 在搞事情。

这是一个挺小众，但非常工程味儿的话题，希望你也会觉得有意思。