尧图网站建设 
简介一份面向 JPEG 修复工具 JPEG-Repair 2.8.254 的轻量源码包适合关注照片恢复、RAW 格式处理以及工具说明页搭建的开发者与技术编辑可作为产品介绍页或入门示例的起点。资源共 3 个文件以 index.html 页面文件为主辅以 .inscode 在线运行配置和 .gitignore 忽略规则压缩包仅 5KB结构极简便于直接查看和二次修改。目前已有 57 人浏览学习。工具包包含两个组件JPEG-Repair 负责修复 JPEG 标头损坏、无效标记、坏扇区损坏并支持从 NEF、CR2、ORF、RW2、ARW、DNG、CR3、RAF 等主流 RAW 中恢复 JPEGJpegDigger 则偏重从存储卡找回丢失图片。代码包适合把本地处理、不上传服务器、免费版可预览并保存低分辨率样本等功能点整理成网页既可作为简洁的产品介绍入口也能当开源仓库说明页或工具站点的参考实现还可作为学习 HTML 页面组织的轻量范例省去从零搭建的麻烦。 最近在整理一批从老硬盘里捞出来的照片差不多一半JPEG文件双击之后直接报“格式不受支持”。朋友问我能不能找个现成的修复工具我想了想Windows下大家习惯的是dll修复工具、directx修复工具这类系统级方案但JPEG文件损坏是数据层面的问题很多时候你等不到一个按钮式的“JPEG修复工具”真正能救回文件的反而是自己写几十行代码直接去改文件的二进制结构。这篇文章不打算讲那些“一键修复”的图形界面软件而是把我实际用过的JPEG修复思路、关键代码和踩过的坑完整拆开。文章会从JPEG的底层文件格式说起再给出一套可直接修改使用的Python代码适合有基础编程经验、需要批量处理损坏图片文件的工程师和运维同学。如果你只是偶尔遇到一张图打不开这篇文章也可以帮你理解“修复”到底修的是什么。1. JPEG文件损坏的四种典型形态与初步判断先明确一个概念JPEG损坏绝大多数不是像素“糊了”而是文件的容器结构出了问题。JPEG文件的解码过程像按图索骥解码器先读文件头找到各种标记段然后用标记段里记录的参数去解码后续的压缩数据。只要这条链路中任何一个环节断掉系统就会直接提示“无法打开”。我自己在实际处理中把损坏的JPEG粗分为四类损坏类型典型表现修复难度文件头丢失文件大小正常但系统不识别格式低补SOI标记即可标记段长度错误图片能打开一部分后半截花屏或报错中需要解析并修正各段长度文件被截断文件尾部缺失没有EOI结束标记低补EOI很多时候能显示已解码的部分关键段损坏DQT量化表或DHT霍夫曼表损坏解码器直接罢工中高需要从参考文件移植判断的方法也很直接用十六进制编辑器打开损坏文件先看开头两个字节是不是FF D8再看结尾是不是FF D9。如果头丢了绝大多数解码器连图片格式都认不出来如果只有结尾丢了很多解码器其实能在报错前渲染出大半张图补个EOI标记就能勉强救回来。但真正难处理的是第三、第四类。文件头尾都能补段长度也有规律可循唯独量化表和霍夫曼表这种“解码字典”坏了不能靠猜只能从别的正常JPEG文件里借。这是整个修复工具里最有价值的部分后面会专门展开。2. 修复工具的地基读懂JPEG标记骨架JPEG文件本质上是一串“标记 数据”的序列。每个标记由两个字节组成第一个字节固定是FF第二个字节是标记类型标识。为了写修复工具至少要把下面这些标记记熟它们是解码器的路标。标记含义说明FF D8SOI图像起始所有JPEG文件必须以此开头FF E0 ~ FF EFAPPn应用数据段常见JFIF、EXIF信息都在这里FF DBDQT量化表记录压缩时的量化步长非常关键FF C0 / FF C2SOF0 / SOF2帧参数记录宽、高、精度、分量信息FF C4DHT霍夫曼表解码压缩数据必须的字典FF DASOS扫描起始标记后面的数据是真正的图像压缩流FF D9EOI图像结束所有JPEG文件以此结尾每个标记段的结构有固定规律FF 标记类型 2字节段长度 段数据。这里有个容易踩的细节段长度是“大端”存储而且长度值包含了这2字节本身。也就是说如果段长度字段里写的是0x0008那整个段从长度字段开始共8个字节真正属于段数据的只有6个字节。理解了标记段结构写修复工具的第一步就是写一个扫描函数把文件里所有标记和它们的位置找出来。这个函数是整个工具的基础所有后续逻辑都建立在它之上。import struct def scan_markers(data): markers [] n len(data) i 0 while i n: if data[i] ! 0xFF: i 1 continue start i while i n and data[i] 0xFF: i 1 if i n: markers.append((0x00, start, i, False)) break marker data[i] i 1 if marker 0xD8 or marker 0xD9 or (0xD0 marker 0xD7) or marker 0x01: markers.append((marker, start, i, False)) if marker 0xD9: break continue if i 2 n: break seg_len struct.unpack(H, data[i:i2])[0] i seg_len markers.append((marker, start, i, True)) return markers这个函数返回一个列表每个元素是(标记类型, 段起始位置, 段结束位置, 是否带长度字段)。特别注意SOS之后的区域里面会有图片压缩数据这些数据里也可能出现FF开头的字节序列扫描时容易误判。所以真正重建文件时遇到SOS就要停手SOS之后的内容原样保留不做任何解析。3. 两个基础修复动作补全头尾与滤除异常段有了扫描函数最基础的修复工具就不难写了。我把修复过程拆成两个动作补全文件头和文件尾、滤除长度异常的标记段。补全头尾的思路很直接如果文件不以FF D8开头就在最前面拼接SOI标记如果文件不以FF D9结尾就在末尾补上EOI。很多人觉得这一步简单实际上有个细节要留心——不是所有丢头的文件都适合直接补FF D8。你先得确认文件开头部分没有被其他垃圾字节污染否则补完头解码器依然会读出一堆乱码。稳妥的做法是先用扫描函数找出第一个合法标记段把之前的垃圾数据都丢弃再补SOI。滤除异常标记段是更核心的步骤。当扫描函数发现的某个标记段其长度字段导致结束位置超出文件总长度这个段就是损坏的直接丢弃。更常见的场景是文件头区域混入了大量无意义的FF填充字节这些字节会被扫描函数误识别为标记也要一并丢弃。def repair_basic(data): if not data.startswith(b\xff\xd8): data b\xff\xd8 data markers scan_markers(data) sos_pos None for marker, start, end, has_len in markers: if marker 0xDA: sos_pos (start, end) break out bytearray(b\xff\xd8) if sos_pos is None: for marker, start, end, has_len in markers: if marker 0xD8: continue if marker 0xD9: out b\xff\xd9 break if has_len and end len(data): out data[start:end] return bytes(out) b\xff\xd9 sos_start, sos_end sos_pos for marker, start, end, has_len in markers: if marker 0xD8: continue if start sos_start: break if has_len and end len(data) and end start: out data[start:end] out data[sos_start:] if not out.endswith(b\xff\xd9): out b\xff\xd9 return bytes(out)这段代码的逻辑是扫描到SOS之后只把SOS段之前的合法标记段重新拼出来SOS及其后的压缩数据整体保留。这样既修复了文件头的结构问题又不会破坏真正的图像数据。我实测过对于“文件头损坏、尾部截断”这类问题这个函数基本都能处理成功救回的文件可以被主流看图软件正常打开。4. 进阶修复从正常JPEG移植量化表与霍夫曼表比头尾损坏更麻烦的是DQT和DHT段损坏。DQT是量化表决定了解码时的色彩和细节精度DHT是霍夫曼表是压缩数据解码的字典。这两个段要是坏了解码器就像一个没有密码本的人完全无法解读后续的压缩流。这个问题的解法听起来很“土”但非常有效找一张同型号相机、同批次软件生成的正常JPEG把它的DQT和DHT段提取出来原样移植到损坏文件里。为什么会有效因为绝大多数数码相机和图像处理软件用的都是标准量化表和标准霍夫曼表这些表在同类文件里几乎一模一样。提取段的代码很简单核心还是复用scan_markers函数def extract_segments(data, target_markers): segs b markers scan_markers(data) for marker, start, end, has_len in markers: if marker in target_markers and has_len: segs data[start:end] return segs把移植和基础修复组合起来就是一套更完整的修复逻辑def replace_segments(damaged, reference, target_markers): base repair_basic(damaged) ref_segs extract_segments(reference, target_markers) markers scan_markers(base) out bytearray(b\xff\xd8) out ref_segs for marker, start, end, has_len in markers: if marker 0xD8: continue if marker in target_markers: continue if has_len and end len(base): out base[start:end] if not out.endswith(b\xff\xd9): out b\xff\xd9 return bytes(out)这里有个关键细节移植的段要插到最前面紧跟在SOI之后。原因是原始文件的段顺序已经被破坏如果你把参考段的插入位置放在某些残存段的后面解码器扫描到DQT的时候可能已经因为其他错误段而放弃了。放在最前面最安全几乎所有解码器都允许APPn、DQT、DHT这类段在文件头区域以任意顺序出现。当然移植DHT不保证100%成功。如果原文件编码时用了非标准的霍夫曼表移植后虽然文件结构合法解码出来的也是一张花图。但从我处理过的案例来看至少七成以上的JPEG文件用的都是标准表这个方法值得优先尝试。5. 实测中的边界哪些情况不能硬修写修复工具最难的不是代码而是知道什么时候该停手。我在这上面栽过不少跟头总结几条实操边界供大家参考。第一条文件碎片化严重时不要硬补头尾。从磁盘恢复软件里捞出来的JPEG经常是多个碎片拼接的。这种文件补了SOI、EOI也毫无意义因为文件中间可能夹着其他文件的数据块。判断方法很简单补完头尾后用图片查看器打开如果整张图是均匀的乱码条纹说明压缩数据本身已经被破坏不是结构问题。第二条SOS之后的数据被裁掉越多修复价值越低。JPEG的压缩数据是自上而下逐行扫描的文件缺失部分越多能恢复的有效行就越少。如果文件被截断到只保留了前十分之一补EOI只能让你看到一条窄窄的画面实际意义不大。第三条EXIF信息修复是另一回事。我在测试中遇到过一些文件修复后能正常打开了但照片方向不对竖拍的照片横过来了。原因就是EXIF段里记录的方向信息在修复过程中丢失或损坏。这类元数据修复和像素解码是两套逻辑如果你的应用场景对EXIF有要求需要考虑额外处理。第四条渐进式JPEG和基线JPEG的处理策略不同。渐进式JPEG用SOF2标记编码数据分多个扫描每个扫描独立。修复这种文件时如果第一个扫描损坏后端扫描即使完整也无法解码。相比之下基线JPEG只有一个扫描修复成功率更高。扫描函数里可以通过识别0xC2标记来判断文件类型针对不同情况调整修复预期。6. 可直接运行的JPEG修复工具代码把前面几节的核心逻辑整合起来就是一个完整的命令行工具。它支持两种模式只做基础修复或者配合参考文件移植DQT/DHT段。import sys import struct SOI b\xff\xd8 EOI b\xff\xd9 def scan_markers(data): markers [] n len(data) i 0 while i n: if data[i] ! 0xFF: i 1 continue start i while i n and data[i] 0xFF: i 1 if i n: markers.append((0x00, start, i, False)) break marker data[i] i 1 if marker 0xD8 or marker 0xD9 or (0xD0 marker 0xD7) or marker 0x01: markers.append((marker, start, i, False)) if marker 0xD9: break continue if i 2 n: break seg_len struct.unpack(H, data[i:i2])[0] i seg_len markers.append((marker, start, i, True)) return markers def repair_basic(data): if not data.startswith(SOI): data SOI data markers scan_markers(data) sos_pos None for marker, start, end, has_len in markers: if marker 0xDA: sos_pos (start, end) break out bytearray(SOI) if sos_pos is None: for marker, start, end, has_len in markers: if marker 0xD8: continue if marker 0xD9: out EOI break if has_len and end len(data): out data[start:end] return bytes(out) EOI sos_start, sos_end sos_pos for marker, start, end, has_len in markers: if marker 0xD8: continue if start sos_start: break if has_len and end len(data) and end start: out data[start:end] out data[sos_start:] if not out.endswith(EOI): out EOI return bytes(out) def extract_segments(data, target_markers): segs b markers scan_markers(data) for marker, start, end, has_len in markers: if marker in target_markers and has_len: segs data[start:end] return segs def replace_segments(damaged, reference, target_markers): base repair_basic(damaged) ref_segs extract_segments(reference, target_markers) markers scan_markers(base) out bytearray(SOI) out ref_segs for marker, start, end, has_len in markers: if marker 0xD8: continue if marker in target_markers: continue if has_len and end len(base): out base[start:end] if not out.endswith(EOI): out EOI return bytes(out) def main(): if len(sys.argv) 3: print(用法:) print( python jpeg_repair.py 损坏文件 输出文件) print( python jpeg_repair.py 损坏文件 参考文件 输出文件) sys.exit(1) damaged_path sys.argv[1] if len(sys.argv) 3: ref_path None out_path sys.argv[2] else: ref_path sys.argv[2] out_path sys.argv[3] with open(damaged_path, rb) as f: damaged_data f.read() if ref_path: with open(ref_path, rb) as f: ref_data f.read() result replace_segments(damaged_data, ref_data, {0xDB, 0xC4}) else: result repair_basic(damaged_data) with open(out_path, wb) as f: f.write(result) print(f已输出: {out_path} ({len(result)} 字节)) if __name__ __main__: main()使用方式分两种。第一种只修复明显的头尾和结构问题直接执行python jpeg_repair.py damaged.jpg fixed.jpg。第二种如果修复后仍提示解码失败找一张同源正常图片作为参考执行python jpeg_repair.py damaged.jpg reference.jpg fixed.jpg工具会自动把参考文件里的DQT和DHT段提取出来替换掉损坏文件里对应的段。跑完代码之后建议再用十六进制编辑器打开输出文件确认一遍开头是FF D8结尾是FF D9中间SOS段之后的数据没有被改动。我自己的习惯是修复完先用系统自带查看器打开确认能渲染后再用Python PIL库做一次完整性校验把文件的宽高、色彩模式读出来比对。如果PIL能正常读取这个文件基本就恢复到了可分发、可归档的状态。最后分享一个小技巧。修复工具配参考文件时不要把参考文件选得太随意。最好是同一台相机、同一个批次拍摄的照片或者同一台设备导出的扫描件这样DQT和DHT的匹配度最高。我从旧硬盘里恢复照片时会先从同一天拍摄的正常照片里挑一张做参考批量修复的成功率比随便找一张网图高很多。JPEG修复说到底就是跟二进制结构打交道你越了解编码器的脾气越能多救回几张照片。本文还有配套的精品资源点击获取 JPEG文件损坏修复：从二进制结构到Python实现
简介一份面向 JPEG 修复工具 JPEG-Repair 2.8.254 的轻量源码包适合关注照片恢复、RAW 格式处理以及工具说明页搭建的开发者与技术编辑可作为产品介绍页或入门示例的起点。资源共 3 个文件以 index.html 页面文件为主辅以 .inscode 在线运行配置和 .gitignore 忽略规则压缩包仅 5KB结构极简便于直接查看和二次修改。目前已有 57 人浏览学习。工具包包含两个组件JPEG-Repair 负责修复 JPEG 标头损坏、无效标记、坏扇区损坏并支持从 NEF、CR2、ORF、RW2、ARW、DNG、CR3、RAF 等主流 RAW 中恢复 JPEGJpegDigger 则偏重从存储卡找回丢失图片。代码包适合把本地处理、不上传服务器、免费版可预览并保存低分辨率样本等功能点整理成网页既可作为简洁的产品介绍入口也能当开源仓库说明页或工具站点的参考实现还可作为学习 HTML 页面组织的轻量范例省去从零搭建的麻烦。 最近在整理一批从老硬盘里捞出来的照片差不多一半JPEG文件双击之后直接报“格式不受支持”。朋友问我能不能找个现成的修复工具我想了想Windows下大家习惯的是dll修复工具、directx修复工具这类系统级方案但JPEG文件损坏是数据层面的问题很多时候你等不到一个按钮式的“JPEG修复工具”真正能救回文件的反而是自己写几十行代码直接去改文件的二进制结构。这篇文章不打算讲那些“一键修复”的图形界面软件而是把我实际用过的JPEG修复思路、关键代码和踩过的坑完整拆开。文章会从JPEG的底层文件格式说起再给出一套可直接修改使用的Python代码适合有基础编程经验、需要批量处理损坏图片文件的工程师和运维同学。如果你只是偶尔遇到一张图打不开这篇文章也可以帮你理解“修复”到底修的是什么。1. JPEG文件损坏的四种典型形态与初步判断先明确一个概念JPEG损坏绝大多数不是像素“糊了”而是文件的容器结构出了问题。JPEG文件的解码过程像按图索骥解码器先读文件头找到各种标记段然后用标记段里记录的参数去解码后续的压缩数据。只要这条链路中任何一个环节断掉系统就会直接提示“无法打开”。我自己在实际处理中把损坏的JPEG粗分为四类损坏类型典型表现修复难度文件头丢失文件大小正常但系统不识别格式低补SOI标记即可标记段长度错误图片能打开一部分后半截花屏或报错中需要解析并修正各段长度文件被截断文件尾部缺失没有EOI结束标记低补EOI很多时候能显示已解码的部分关键段损坏DQT量化表或DHT霍夫曼表损坏解码器直接罢工中高需要从参考文件移植判断的方法也很直接用十六进制编辑器打开损坏文件先看开头两个字节是不是FF D8再看结尾是不是FF D9。如果头丢了绝大多数解码器连图片格式都认不出来如果只有结尾丢了很多解码器其实能在报错前渲染出大半张图补个EOI标记就能勉强救回来。但真正难处理的是第三、第四类。文件头尾都能补段长度也有规律可循唯独量化表和霍夫曼表这种“解码字典”坏了不能靠猜只能从别的正常JPEG文件里借。这是整个修复工具里最有价值的部分后面会专门展开。2. 修复工具的地基读懂JPEG标记骨架JPEG文件本质上是一串“标记 数据”的序列。每个标记由两个字节组成第一个字节固定是FF第二个字节是标记类型标识。为了写修复工具至少要把下面这些标记记熟它们是解码器的路标。标记含义说明FF D8SOI图像起始所有JPEG文件必须以此开头FF E0 ~ FF EFAPPn应用数据段常见JFIF、EXIF信息都在这里FF DBDQT量化表记录压缩时的量化步长非常关键FF C0 / FF C2SOF0 / SOF2帧参数记录宽、高、精度、分量信息FF C4DHT霍夫曼表解码压缩数据必须的字典FF DASOS扫描起始标记后面的数据是真正的图像压缩流FF D9EOI图像结束所有JPEG文件以此结尾每个标记段的结构有固定规律FF 标记类型 2字节段长度 段数据。这里有个容易踩的细节段长度是“大端”存储而且长度值包含了这2字节本身。也就是说如果段长度字段里写的是0x0008那整个段从长度字段开始共8个字节真正属于段数据的只有6个字节。理解了标记段结构写修复工具的第一步就是写一个扫描函数把文件里所有标记和它们的位置找出来。这个函数是整个工具的基础所有后续逻辑都建立在它之上。import struct def scan_markers(data): markers [] n len(data) i 0 while i n: if data[i] ! 0xFF: i 1 continue start i while i n and data[i] 0xFF: i 1 if i n: markers.append((0x00, start, i, False)) break marker data[i] i 1 if marker 0xD8 or marker 0xD9 or (0xD0 marker 0xD7) or marker 0x01: markers.append((marker, start, i, False)) if marker 0xD9: break continue if i 2 n: break seg_len struct.unpack(H, data[i:i2])[0] i seg_len markers.append((marker, start, i, True)) return markers这个函数返回一个列表每个元素是(标记类型, 段起始位置, 段结束位置, 是否带长度字段)。特别注意SOS之后的区域里面会有图片压缩数据这些数据里也可能出现FF开头的字节序列扫描时容易误判。所以真正重建文件时遇到SOS就要停手SOS之后的内容原样保留不做任何解析。3. 两个基础修复动作补全头尾与滤除异常段有了扫描函数最基础的修复工具就不难写了。我把修复过程拆成两个动作补全文件头和文件尾、滤除长度异常的标记段。补全头尾的思路很直接如果文件不以FF D8开头就在最前面拼接SOI标记如果文件不以FF D9结尾就在末尾补上EOI。很多人觉得这一步简单实际上有个细节要留心——不是所有丢头的文件都适合直接补FF D8。你先得确认文件开头部分没有被其他垃圾字节污染否则补完头解码器依然会读出一堆乱码。稳妥的做法是先用扫描函数找出第一个合法标记段把之前的垃圾数据都丢弃再补SOI。滤除异常标记段是更核心的步骤。当扫描函数发现的某个标记段其长度字段导致结束位置超出文件总长度这个段就是损坏的直接丢弃。更常见的场景是文件头区域混入了大量无意义的FF填充字节这些字节会被扫描函数误识别为标记也要一并丢弃。def repair_basic(data): if not data.startswith(b\xff\xd8): data b\xff\xd8 data markers scan_markers(data) sos_pos None for marker, start, end, has_len in markers: if marker 0xDA: sos_pos (start, end) break out bytearray(b\xff\xd8) if sos_pos is None: for marker, start, end, has_len in markers: if marker 0xD8: continue if marker 0xD9: out b\xff\xd9 break if has_len and end len(data): out data[start:end] return bytes(out) b\xff\xd9 sos_start, sos_end sos_pos for marker, start, end, has_len in markers: if marker 0xD8: continue if start sos_start: break if has_len and end len(data) and end start: out data[start:end] out data[sos_start:] if not out.endswith(b\xff\xd9): out b\xff\xd9 return bytes(out)这段代码的逻辑是扫描到SOS之后只把SOS段之前的合法标记段重新拼出来SOS及其后的压缩数据整体保留。这样既修复了文件头的结构问题又不会破坏真正的图像数据。我实测过对于“文件头损坏、尾部截断”这类问题这个函数基本都能处理成功救回的文件可以被主流看图软件正常打开。4. 进阶修复从正常JPEG移植量化表与霍夫曼表比头尾损坏更麻烦的是DQT和DHT段损坏。DQT是量化表决定了解码时的色彩和细节精度DHT是霍夫曼表是压缩数据解码的字典。这两个段要是坏了解码器就像一个没有密码本的人完全无法解读后续的压缩流。这个问题的解法听起来很“土”但非常有效找一张同型号相机、同批次软件生成的正常JPEG把它的DQT和DHT段提取出来原样移植到损坏文件里。为什么会有效因为绝大多数数码相机和图像处理软件用的都是标准量化表和标准霍夫曼表这些表在同类文件里几乎一模一样。提取段的代码很简单核心还是复用scan_markers函数def extract_segments(data, target_markers): segs b markers scan_markers(data) for marker, start, end, has_len in markers: if marker in target_markers and has_len: segs data[start:end] return segs把移植和基础修复组合起来就是一套更完整的修复逻辑def replace_segments(damaged, reference, target_markers): base repair_basic(damaged) ref_segs extract_segments(reference, target_markers) markers scan_markers(base) out bytearray(b\xff\xd8) out ref_segs for marker, start, end, has_len in markers: if marker 0xD8: continue if marker in target_markers: continue if has_len and end len(base): out base[start:end] if not out.endswith(b\xff\xd9): out b\xff\xd9 return bytes(out)这里有个关键细节移植的段要插到最前面紧跟在SOI之后。原因是原始文件的段顺序已经被破坏如果你把参考段的插入位置放在某些残存段的后面解码器扫描到DQT的时候可能已经因为其他错误段而放弃了。放在最前面最安全几乎所有解码器都允许APPn、DQT、DHT这类段在文件头区域以任意顺序出现。当然移植DHT不保证100%成功。如果原文件编码时用了非标准的霍夫曼表移植后虽然文件结构合法解码出来的也是一张花图。但从我处理过的案例来看至少七成以上的JPEG文件用的都是标准表这个方法值得优先尝试。5. 实测中的边界哪些情况不能硬修写修复工具最难的不是代码而是知道什么时候该停手。我在这上面栽过不少跟头总结几条实操边界供大家参考。第一条文件碎片化严重时不要硬补头尾。从磁盘恢复软件里捞出来的JPEG经常是多个碎片拼接的。这种文件补了SOI、EOI也毫无意义因为文件中间可能夹着其他文件的数据块。判断方法很简单补完头尾后用图片查看器打开如果整张图是均匀的乱码条纹说明压缩数据本身已经被破坏不是结构问题。第二条SOS之后的数据被裁掉越多修复价值越低。JPEG的压缩数据是自上而下逐行扫描的文件缺失部分越多能恢复的有效行就越少。如果文件被截断到只保留了前十分之一补EOI只能让你看到一条窄窄的画面实际意义不大。第三条EXIF信息修复是另一回事。我在测试中遇到过一些文件修复后能正常打开了但照片方向不对竖拍的照片横过来了。原因就是EXIF段里记录的方向信息在修复过程中丢失或损坏。这类元数据修复和像素解码是两套逻辑如果你的应用场景对EXIF有要求需要考虑额外处理。第四条渐进式JPEG和基线JPEG的处理策略不同。渐进式JPEG用SOF2标记编码数据分多个扫描每个扫描独立。修复这种文件时如果第一个扫描损坏后端扫描即使完整也无法解码。相比之下基线JPEG只有一个扫描修复成功率更高。扫描函数里可以通过识别0xC2标记来判断文件类型针对不同情况调整修复预期。6. 可直接运行的JPEG修复工具代码把前面几节的核心逻辑整合起来就是一个完整的命令行工具。它支持两种模式只做基础修复或者配合参考文件移植DQT/DHT段。import sys import struct SOI b\xff\xd8 EOI b\xff\xd9 def scan_markers(data): markers [] n len(data) i 0 while i n: if data[i] ! 0xFF: i 1 continue start i while i n and data[i] 0xFF: i 1 if i n: markers.append((0x00, start, i, False)) break marker data[i] i 1 if marker 0xD8 or marker 0xD9 or (0xD0 marker 0xD7) or marker 0x01: markers.append((marker, start, i, False)) if marker 0xD9: break continue if i 2 n: break seg_len struct.unpack(H, data[i:i2])[0] i seg_len markers.append((marker, start, i, True)) return markers def repair_basic(data): if not data.startswith(SOI): data SOI data markers scan_markers(data) sos_pos None for marker, start, end, has_len in markers: if marker 0xDA: sos_pos (start, end) break out bytearray(SOI) if sos_pos is None: for marker, start, end, has_len in markers: if marker 0xD8: continue if marker 0xD9: out EOI break if has_len and end len(data): out data[start:end] return bytes(out) EOI sos_start, sos_end sos_pos for marker, start, end, has_len in markers: if marker 0xD8: continue if start sos_start: break if has_len and end len(data) and end start: out data[start:end] out data[sos_start:] if not out.endswith(EOI): out EOI return bytes(out) def extract_segments(data, target_markers): segs b markers scan_markers(data) for marker, start, end, has_len in markers: if marker in target_markers and has_len: segs data[start:end] return segs def replace_segments(damaged, reference, target_markers): base repair_basic(damaged) ref_segs extract_segments(reference, target_markers) markers scan_markers(base) out bytearray(SOI) out ref_segs for marker, start, end, has_len in markers: if marker 0xD8: continue if marker in target_markers: continue if has_len and end len(base): out base[start:end] if not out.endswith(EOI): out EOI return bytes(out) def main(): if len(sys.argv) 3: print(用法:) print( python jpeg_repair.py 损坏文件 输出文件) print( python jpeg_repair.py 损坏文件 参考文件 输出文件) sys.exit(1) damaged_path sys.argv[1] if len(sys.argv) 3: ref_path None out_path sys.argv[2] else: ref_path sys.argv[2] out_path sys.argv[3] with open(damaged_path, rb) as f: damaged_data f.read() if ref_path: with open(ref_path, rb) as f: ref_data f.read() result replace_segments(damaged_data, ref_data, {0xDB, 0xC4}) else: result repair_basic(damaged_data) with open(out_path, wb) as f: f.write(result) print(f已输出: {out_path} ({len(result)} 字节)) if __name__ __main__: main()使用方式分两种。第一种只修复明显的头尾和结构问题直接执行python jpeg_repair.py damaged.jpg fixed.jpg。第二种如果修复后仍提示解码失败找一张同源正常图片作为参考执行python jpeg_repair.py damaged.jpg reference.jpg fixed.jpg工具会自动把参考文件里的DQT和DHT段提取出来替换掉损坏文件里对应的段。跑完代码之后建议再用十六进制编辑器打开输出文件确认一遍开头是FF D8结尾是FF D9中间SOS段之后的数据没有被改动。我自己的习惯是修复完先用系统自带查看器打开确认能渲染后再用Python PIL库做一次完整性校验把文件的宽高、色彩模式读出来比对。如果PIL能正常读取这个文件基本就恢复到了可分发、可归档的状态。最后分享一个小技巧。修复工具配参考文件时不要把参考文件选得太随意。最好是同一台相机、同一个批次拍摄的照片或者同一台设备导出的扫描件这样DQT和DHT的匹配度最高。我从旧硬盘里恢复照片时会先从同一天拍摄的正常照片里挑一张做参考批量修复的成功率比随便找一张网图高很多。JPEG修复说到底就是跟二进制结构打交道你越了解编码器的脾气越能多救回几张照片。本文还有配套的精品资源点击获取