如何将PDF中/FlateDecode的zlib编码流转换为PNG图像？

首先得戳破你手动加头失败的核心原因：PNG的IDAT块里的zlib压缩数据，并不是单纯的原始RGB像素的zlib压缩结果——它是给每一行像素前面加了一个滤波字节之后，再做zlib压缩的产物。而你从PDF里拿到的FlateDecode数据，大概率是直接压缩的纯RGB像素（没有加这个滤波字节），直接塞到IDAT里自然会让PNG解码器报错。

接下来分两种情况给你解决方案，优先推荐用libpng，毕竟手动造PNG太容易踩坑，而且内存有限的场景下libpng也有流式方案：

一、用libpng实现（内存友好，推荐） #

你担心解压缩再压缩会占用太多内存？没问题，libpng支持流式处理，不需要把整个图像加载到内存里，每次只处理几行就行，内存占用可以控制得很低。具体步骤如下：

• 初始化libpng写结构：创建png_structp和png_infop对象，设置好输出的回调（比如写文件或者内存缓冲区）。
• 配置IHDR参数：把你已知的宽、高、8位深度、颜色类型设为PNG_COLOR_TYPE_RGB（对应RGB打包格式），压缩方法选PNG_COMPRESSION_TYPE_BASE（就是zlib），滤波方法用默认的PNG_FILTER_TYPE_BASE，交错关闭。
• 流式处理数据：
  1. 用zlib的流式API，一点点解压缩你拿到的FlateDecode数据（比如每次解一行或几行的RGB像素）；
  2. 给每一行的像素数据前面加一个滤波字节0x00（无滤波模式，是PNG的默认选项）；
  3. 调用png_write_row把这一行（滤波字节+像素数据）传给libpng，它会自动帮你做zlib压缩并写入IDAT块；
• 收尾工作：所有行处理完后，调用png_write_end结束PNG写入，再清理libpng的结构。

这种方式全程不需要把整个解压缩后的图像存到内存里，内存占用只取决于你每次处理的行数，非常适合资源有限的系统。

二、手动构造PNG（仅当原始数据符合要求时可行） #

如果你的FlateDecode数据恰好是已经加了PNG滤波字节的像素数据的zlib压缩结果（比如这个PDF图像本来就是从PNG转过来的），那你可以手动拼接PNG文件，步骤如下：

1. 写PNG签名：开头必须是固定的字节序列：\x89PNG\r\n\x1a\n
2. 构造IHDR块：
   • 块长度：13（IHDR数据区的字节数）
   • 块类型：ASCII的IHDR
   • 数据区：按大端顺序写4字节宽度、4字节高度，然后是1字节位深度（8）、1字节颜色类型（2，对应RGB）、1字节压缩方法（0）、1字节滤波方法（0）、1字节交错方法（0）
   • CRC32：对块类型+数据区计算CRC32，写4字节大端
3. 构造IDAT块：
   • 块长度：你手里的zlib数据的字节数
   • 块类型：ASCII的IDAT
   • 数据区：直接把你的FlateDecode zlib数据放进去
   • CRC32：对块类型+数据区计算CRC32
4. 构造IEND块：固定的内容，长度0，类型IEND，CRC是AE426082（大端）

但要注意：这种情况非常少见，绝大多数PDF里的FlateDecode RGB数据都是纯像素的压缩结果，没有滤波字节，所以手动拼接肯定会失败。如果不确定，可以先解压缩一小段数据看看，比如第一行的像素前面有没有0x00字节。

为什么你之前手动加头失败？ #

本质就是PNG解码器解压缩IDAT的数据后，会默认每一行开头有一个滤波字节，它会用这个字节去处理后面的像素数据。而你的数据里没有这个字节，解码器就会把像素的第一个字节当成滤波字节，后面的像素全部错位，自然无法正确解析图像。

内容的提问来源于stack exchange，提问作者akw