UniPDF：当PDF存在OCR文本层时，图片重新编码为JBIG2/CCITTFax格式失败

我之前处理带OCR文本层的扫描PDF时，刚好碰到过一模一样的问题！用UniPDF v3.69跟着官方的流处理器示例做图片重编码，结果要么图片压缩失败，要么直接把OCR文本层搞丢了，踩了好几个坑才解决。

问题根源 #

官方示例默认假设页面只有单一的图像XObject，完全没考虑带文本层的PDF结构——这类PDF的内容流里既有图像绘制的Do操作，也有文本绘制的Tj/TJ操作。如果直接照搬示例的全页面流替换逻辑，要么会因为文本操作干扰跳过图像处理，要么会把文本层的内容直接覆盖掉，导致图像重编码的上下文完全错误。

亲测有效的解决步骤 #

给你分享我调试出来的处理流程：

• 精准定位图像XObject：用pdfcore.NewContentStreamParser解析页面内容流，逐个遍历操作符。只对Do操作符对应的XObject做判断，通过XObject.Type()确认是Image类型后再进行重编码，完全忽略文本相关的操作符。
• 仅替换图像流，保留文本层：不要直接生成新的页面内容流，而是找到目标图像XObject的原始流，把重编码后的图像数据替换进去。比如拿到图像XObject后调用imageXObj.SetStream(encodedStream)，这样文本层的所有内容操作都会原封不动保留。
• 匹配图像参数再编码：带OCR的扫描PDF基本都是灰度图，先确认图像的颜色空间是DeviceGray、位深度是1位或8位。用CCITTFax编码时，要设置和原图像一致的宽高、K值（比如K: -1做自适应压缩）；用JBIG2编码的话，要启用上下文模式提升压缩率，同时确保编码后的图像参数和原图像完全匹配，避免页面布局错乱。
• 分步验证排除问题：先把页面中的图像XObject单独提取出来，用相同的编码逻辑测试。如果单独编码能成功，那问题肯定出在PDF内容流的整合上——这时候要检查内容流的操作顺序，保证图像绘制和文本绘制的先后顺序不变，只替换图像的流数据。

避坑提醒 #

别直接用官方示例里的GrayscaleTransform这类批量转换函数！这类函数会直接生成新的灰度图像页面，完全覆盖掉原有的OCR文本层，这也是很多人处理带文本层PDF时失败的核心原因。

内容来源于stack exchange