在处理设计资源和素材归档时，不少团队习惯用自动化脚本对PNG图片做体积优化。但优化完成后，原本能通过PNG Info这类工具读取的元数据突然消失，解析面板要么报错要么一片空白。这种现象背后的核心原因，往往是压缩工具在重编码过程中丢弃了承载元数据的辅助数据块，而非图像本身受损。PNG格式采用分块结构，除存储像素的IDAT块之外，还有tEXt、iTXt、zTXt等专门用于文本元数据的块，以及tIME、pHYs等辅助块，压缩工具若未显式保留，就会在输出时将其剔除。
理解PNG数据块结构与元数据存放位置
PNG文件由固定的八字节签名和若干个数据块链式组成。每个数据块包含长度、类型、数据和CRC校验四部分。真正决定图像内容的只有IHDR和IDAT，而我们在PNG Info里看到的作者、描述、版权、拍摄参数等，基本都写在tEXt、iTXt或zTXt块中。tEXt使用纯文本键值对，iTXt支持国际化与压缩标志，zTXt则是压缩后的文本。了解这一点就能明白，所谓元数据丢失，其实是这些特定类型的块被移除了。
很多初学者误以为PNG压缩只是改了像素编码，实际上大多数第三方工具为了极限瘦身，会重新生成整张图：读取解码后的像素，再用新参数编码输出。这个过程中，原文件里除IHDR、IDAT、IEND之外的块经常直接被忽略。例如某开源压缩库在默认配置下只复制关键块，导致用PNG Info打开时找不到任何文本块。我们可以用十六进制工具或Python的png模块打印块列表，确认是否还存在tEXt等类型。
下面这段Python代码可以遍历一个PNG文件的所有数据块类型，帮助我们快速判断元数据块是否被保留：
import struct
def list_png_chunks(path):
with open(path, 'rb') as f:
sig = f.read(8)
if sig != b'x89PNGrnx1an':
print('不是合法的PNG文件')
return
while True:
length_bytes = f.read(4)
if len(length_bytes) < 4:
break
length = struct.unpack('>I', length_bytes)[0]
chunk_type = f.read(4)
f.read(length)
f.read(4)
print('数据块类型:', chunk_type.decode('latin1'))
if chunk_type == b'IEND':
break
list_png_chunks('example.png')
常见压缩工具为何会剥离元数据
从实现角度看，压缩工具剥离元数据通常出于三点考虑。第一是体积，文本块虽小，但在海量小图标场景下累积可观；第二是隐私，部分用户不希望原图里的相机信息或作者名随文件传播；第三是兼容性，个别老旧解析器遇到非常规块会报错，工具方选择一刀切来保证通用性。但问题在于，很多工具把这做成默认行为，且未在界面明确提示，导致用户在不知情的情况下丢失了重要信息。
以命令行工具为例，某些流行方案在调用底层编码库时，只传入像素缓冲区和输出路径，完全不读取原文件块表。相对的，像pillow这类库在保存时可通过参数控制是否保留信息。如果我们用错API，例如直接新建图片再保存，那原来的tEXt自然无影无踪。对比来看，支持块白名单的工具会在压缩前扫描原块，按配置保留指定类型，这才是稳妥做法。
我们可以通过下表了解几类典型工具的行为差异：
| 工具类型 | 默认元数据行为 | 可否配置保留 |
|---|---|---|
| 在线极速压缩 | 全部丢弃 | 通常不可 |
| 本地命令行库A | 仅留关键块 | 需改源码 |
| 图像处理库B | 依调用参数而定 | 可显式保留 |
从表中可以看出，能否修复和避免丢失，很大程度上取决于我们选用的工具是否暴露了块控制能力。因此遇到PNG Info解析失败，第一步应是核查所用压缩工具的文档或源码，确认其数据处理流程。
修复与预防：提取、重写与工具替换
如果元数据已经因压缩而丢失，但原图尚在，最直接的修复是在压缩前用脚本提取文本块，压缩后再写回。Python的pillow配合第三方png插件可以做到：读原图时获取info字典里的文本项，压缩完成后用save方法的pnginfo参数重新注入。这样即便中间工具不支持保留，我们也能在流程末端补齐。需要注意的是，重写时应使用iTXt或tEXt中与原格式一致的块，避免PNG Info因编码差异再次无法解析。
若原图已删、仅剩压缩后文件，则元数据基本不可恢复，因为块内容并未被隐藏而是彻底未写入。此时只能从其他备份或数据库补录。为预防此类问题，建议在构建压缩流水线时，统一采用支持保留辅助块的方案，或在CI脚本里先调用提取逻辑存档，再执行压缩。如下代码展示了如何用pillow提取并回写文本元数据：
from PIL import Image
from PIL import PngImagePlugin
# 提取原图元数据
src = Image.open('original.png')
meta = src.info.get('text', {})
# 假设compressed.png是压缩后文件
out = Image.open('compressed.png')
png_info = PngImagePlugin.PngInfo()
for k, v in meta.items():
png_info.add_text(k, v)
out.save('repaired.png', pnginfo=png_info)
此外，团队内部应建立素材规范，明确哪些项目必须携带版权与描述块。开发阶段可用自动化测试扫描输出目录，一旦发现有PNG缺失tEXt或iTXt就告警。从工程角度看，把元数据视为资源的一部分而非附属品，才能从根本上解决PNG Info无法解析的尴尬。选用工具时，优先验证其块保留策略，远比事后修复更省成本。
PNG_metadataimage_compressionmetadata_repair修改时间：2026-08-15 10:03:31