简介：面向图像恢复与RAW格式处理开发者的JPEG修复工具介绍代码包，以HTML页面为展示主体，围绕JPEG-Repair 2.8.254的两大组件——JPEG-Repair与JpegDigger——展开说明。内容涉及损坏JPEG标头修复、无效标记处理、坏扇区数据恢复，从损坏RAW照片中提取JPEG，以及从存储设备找回丢失文件的原理与适用场景，同时覆盖NEF、CR2、ORF、RW2、ARW、DNG、CR3、RAF等主流相机RAW格式。压缩包共3个文件，包括1个HTML预览页、环境配置文件和Git忽略规则文件，整体仅5KB，结构精简，便于快速理解代码组织方式并直接复用。目前已有63人学习下载，适合希望掌握JPEG修复底层逻辑、开发类似恢复工具或研究相机RAW格式的开发者阅读，也可作为构建工具介绍型页面的简洁示例。
1. JPEG修复工具介绍：图片打不开别急着删，先从字节层面把结构救回来
内存卡还在相机里就断电、SD卡拔得太快、微信传图传到一半关掉、从老硬盘拷照片时提示“文件已损坏”——这类场景里，JPEG图片打开报错几乎是最高频的电脑问题之一。多数人的第一反应是删除重新下载，但如果照片只有一份，就值得在删之前试一次JPEG修复工具。
JPEG修复工具和dll修复工具不一样：后者修补的是Windows系统的动态链接库，前者修补的是JPEG文件内部的段标记结构。它不负责调色、去噪或放大，只做一件事——让损坏的JPEG文件重新满足解码器的解析规则，把还能用的像素数据接回去。
本文要做的，就是拆开一个JPEG文件的字节结构，用Python写一个最小可用的修复工具，把“能打开”和“能修好”的边界讲清楚。适合手里有打不开的旧照片、又不想一上来就付费买恢复软件的人。
2. 先搞懂 JPEG 文件骨架再动手：标记段、长度字段和两种主要损坏模式
2.1 JPEG 不是一张“照片”，是一串带长度标签的数据块
JPEG文件本质上是二进制的标记段序列。解码器阅读这个序列，获取尺寸、量化表、哈夫曼表，然后读取压缩后的像素数据。每个标记由0xFF加一个字节的标记码组成，比如：
- FF D8：SOI，文件开始
- FF E0 / FF E1：APP0/JFIF、APP1/EXIF，元数据所在地
- FF DB：DQT量化表
- FF C0 / FF C2：SOF，帧头，里面包含宽高、色彩分量
- FF C4：DHT哈夫曼表
- FF DA：SOS，扫描开始，从这里往后的字节是熵编码数据
- FF D9：EOI，文件结束
除了SOI/EOI和RSTn重启标记，其余段都在标记码之后有2字节的大端长度字段，长度值包含长度字段本身。也就是说，读到FF DB后，后面紧跟的2个字节告诉解码器“这个量化表段总共有多少字节”，解码器据此跳过整段。
这里第一个关键点就出来了：长度字段如果损坏，解码器会跳错位置，把原本是图像数据的内容当成标记来读，进而报错。所以修复工具的第一项能力是能从一个损坏文件中把段切出来——这就是扫描器。
2.2 常见损坏模式：头坏、尾截断、长度错乱
以我经手过的损坏JPEG样本来看，90%落在三种模式里。
第一种是头部损坏。文件开头不是标准的FF D8，可能是文件恢复工具从扇区中间开始提取的，多出来几十个无关字节；也可能SOI被覆盖成别的字节。这时候解码器在一开始就认不出来，提示“无法识别图像格式”。
第二种是尾部截断。文件写到一半断电或传输中断，EOI标记FF D9缺失，或者后面还带着一截垃圾字节。很多解码器对缺失EOI的容忍度不一致，有的能出图但报警告，有的直接拒绝显示。
第三种是段长度错乱，常见于文件被覆盖写入或拼接处理之后。某个段的长度字段变成异常数值，解码器顺着它跑到错误偏移，后续所有解析都失去同步。
修复逻辑因此可以归纳成三步：找到或补出SOI，扫描全部段并校验长度，最后在安全位置收尾或补上EOI。
2.3 修复工具的能力边界：能修复的不等于能恢复
有一件事必须说清楚：JPEG修复工具不是万能的数据恢复软件。如果文件只有一半大小，或者熵编码数据整体被覆盖，任何结构层面的修复都救不回来——你无法凭空补出已被覆盖的像素数据。
修复工具能救的是“结构损坏但数据完好”的文件：头部错位可以纠正，缺失EOI可以补上，截断的数据可以切到最后一个有效位置。判断是否值得修，先看文件大小和损坏位置。一个500KB的JPEG如果剩余480KB，大概率能修；如果只剩80KB，建议直接去找原始文件。
这个边界决定了下面的实现怎么写：扫描器不追求恢复被覆盖的字节，只追求在现有字节里找出最能被解码器接受的合法序列。
3. 自己动手写一个 JPEG 修复工具：扫描标记段、截断损坏数据、重建 EOI
3.1 第一步：写一个能容忍脏数据的段扫描器
修复工具的第一步是从二进制数据里提取段结构。我一般不用现成的解码库来做这件事，因为它们在遇到损坏数据时倾向于抛异常而不是给出结构化信息。自己扫反而更可控。下面给出的示例代码就可以当作jpeg_repair.py的基础，直接保存就能跑。
import sys import struct # JPEG 标记码常量 MARKER_SOI = 0xD8 # 图像开始 FF D8 MARKER_EOI = 0xD9 # 图像结束 FF D9 MARKER_SOS = 0xDA # 扫描开始 FF DA MARKER_DQT = 0xDB # 量化表 MARKER_DHT = 0xC4 # 哈夫曼表 MARKER_SOF0 = 0xC0 # 基线 DCT 帧头 MARKER_SOF2 = 0xC2 # 渐进 DCT 帧头 MARKER_DRI = 0xDD # 重启间隔 def scan_segments(data: bytes): """扫描 JPEG 二进制，返回 [(offset, marker, payload_len), ...] offset 是段头 (FF xx) 的位置，payload_len 不含 2 字节长度字段。 遇到异常长度或文件截断时，记录负数长度并停止。 """ segments = [] i = 0 n = len(data) # 在文件头里找 FF D8，忽略前面的垃圾字节 while i < n - 1: if data[i] == 0xFF and data[i + 1] == MARKER_SOI: break i += 1 if i >= n - 1: print("[错误] 找不到 SOI 标记，文件不像 JPEG") return None segments.append((i, MARKER_SOI, 0)) i += 2 while i < n: # 跳过可能存在的连续 0xFF 填充 while i < n and data[i] == 0xFF: i += 1 if i >= n: # 文件在标记处截断 segments.append((i - 1, 0, -1)) break marker = data[i] i += 1 # 遇到 EOI，扫描完成 if marker == MARKER_EOI: segments.append((i - 2, MARKER_EOI, 0)) break # 无长度字段的段：TEM(0x01) 和 RSTn(0xD0-0xD7) if marker == 0x01 or (0xD0 <= marker <= 0xD7): segments.append((i - 2, marker, 0)) continue # 其余标记都带 2 字节大端长度 if i + 1 >= n: segments.append((i - 2, marker, -1)) break length = struct.unpack(">H", data[i:i + 2])[0] if length < 2: print(f"[警告] 偏移 {i - 2:#x} 长度字段异常: {length}，按 2 处理") length = 2 payload_len = length - 2 segments.append((i - 2, marker, payload_len)) i += length if i > n: # 段体超过文件末尾，记负数长度并在后续处理中截断 segments[-1] = (segments[-1][0], segments[-1][1], n - i + payload_len) break return segments扫出来的每个元组是(offset, marker, payload_len)。offset指向段头的0xFF位置，payload_len是长度字段之后的有效载荷字节数。我把负数长度当成“文件在这里截断”的信号，后续修复逻辑遇到负数就停止追加，而不是继续读。
这段代码里有三个要注意的参数。一是定位SOI时的扫描上限是n-1，防止越界；二是连续0xFF填充要跳过不止一个，很多硬盘提取件会在段与段之间塞多余的0xFF；三是长度字段用struct.unpack(">H")按大端读取，JPEG的标准就是网络字节序，不能按小端读。
3.2 第二步：实现修复逻辑，把损坏点切掉并补上 EOI
拿到段列表后，修复的核心算法只有两件事：复制所有合法的段，在文件末尾补上缺失的EOI。但有一个特殊区域需要单独处理——SOS之后的熵编码数据。
熵编码数据不遵循段结构。它里面允许出现0xFF这种字节，后面会跟一个0x00作为转义，表示这是个普通字节而不是标记。所以从SOS开始，不能用段扫描的方式解析，要用另一套规则来查找EOI。
def find_safe_eoi(data: bytes, start: int) -> int: """从 start 位置扫描熵编码数据。 返回安全截断点：通常是 EOI 结束后的位置；如果数据损坏， 返回最后一个可信字节的位置，把后面的垃圾字节切掉。 """ i = start n = len(data) while i < n: if data[i] != 0xFF: i += 1 continue # 遇到 FF，查看后面的字节 while i < n and data[i] == 0xFF: i += 1 if i >= n: break m = data[i] i += 1 if m == 0x00: # 转义字节，说明 FF 是数据的一部分，继续 continue if 0xD0 <= m <= 0xD7: # 重启标记，跳过 continue if m == MARKER_EOI: # 找到真正的 EOI return i # 出现其他标记字节，说明数据在这里损坏 # 回退到 FF 之前的位置，将其视为安全截断点 return i - 2 # 整个扫描完都没找到 EOI，数据被截断 return n这一段是修复工具里最容易翻车的地方。很多初学者会把整份文件丢给段扫描器，SOS之后的字节被当成段的组合来解析，结果在任意一个0xFF字节处错位。实际上，熵编码数据只允许三种0xFF组合：FF 00、FF D0-D7、FF D9，遇到其他组合就应该截断。
修复函数利用这两段逻辑组装最终结果：
def repair_jpeg(raw: bytes) -> bytes: """把损坏的 JPEG 字节修成可解码的 JPEG 字节""" segments = scan_segments(raw) if segments is None: return b"" out = bytearray() truncate_at = None for offset, marker, payload_len in segments: # 遇到负数长度，说明段体截断，停在这里 if payload_len < 0: truncate_at = offset break end = offset + 2 + payload_len out.extend(raw[offset:end]) if marker == MARKER_SOS: # SOS 之后是熵编码数据，用扫描器找安全结束点 safe_end = find_safe_eoi(raw, end) out.extend(raw[end:safe_end]) # 如果安全结束点就是文件末尾，需要补 EOI if safe_end == len(raw) or raw[safe_end:safe_end + 2] != b"\xFF\xD9": out.extend(b"\xFF\xD9") return bytes(out) if marker == MARKER_EOI: # 已经是正常结束，直接返回 return bytes(out) # 到这里说明没遇到 EOI，统一补一个 if truncate_at is not None: del out[truncate_at:] out.extend(b"\xFF\xD9") return bytes(out)参数选择上我习惯保留SOS之后找到的完整熵数据，只在确认EOI缺失时才追加。因为追加EOI不会破坏已经存在的有效数据，而删掉额外字节反而可能让原本能解码的图像花屏。如果扫描到安全截断点，把截断点之后的内容作废即可。
修复后输出的字节数可能比原始文件小，也可能大一点——小是因为切掉了损坏段，大是因为补上了缺失的EOI。这都是正常的。
3.3 命令行入口：一条命令跑通修复流程
工具的入口很简单，读文件、修复、写文件，顺带打印修复前后的字节数对比：
python jpeg_repair.py 坏照片.jpg 修好的.jpg对应的CLI代码：
def main(): if len(sys.argv) < 2: print("用法: python jpeg_repair.py <输入文件> [输出文件]") return 1 src = sys.argv[1] dst = sys.argv[2] if len(sys.argv) > 2 else src.rsplit(".", 1)[0] + "_fixed.jpg" with open(src, "rb") as f: raw = f.read() fixed = repair_jpeg(raw) if len(fixed) == 0: print(f"[失败] {src} 未被识别为 JPEG 结构") return 2 with open(dst, "wb") as f: f.write(fixed) diff = len(fixed) - len(raw) print(f"[完成] {src} -> {dst}") print(f"[信息] {len(raw)} 字节 -> {len(fixed)} 字节，变化 {diff:+d} 字节") return 0 if __name__ == "__main__": sys.exit(main())这个入口没有额外参数，因为修复逻辑本身不涉及可调阈值——段扫描器遇到损坏段会自行停止，熵数据扫描器遇到异常标记会自行截断。对大多数文件来说，这就是最稳妥的策略。
如果你要批量修复一个目录下的所有JPEG，在Shell里套一层循环就够：
for f in *.jpg; do python jpeg_repair.py "$f" "fixed_$f"; done输出文件名加了个fixed_前缀，避免覆盖原始文件。我建议任何情况下都保留原始文件不要覆盖，因为修复本身是有损操作，万一结果不理想，原始文件还在，就有换一种方式再修的机会。
4. JPEG 修复工具避坑与常见问题排查：修完打不开、花屏、没反应的 5 种现场
4.1 修复后能打开，但花屏或灰屏
现象：修复工具报告成功，图片也能被看图软件打开，但画面是一半正常一半马赛克，或者整张灰屏。
原因：截断点定得太靠后。SOS之后的熵编码数据里如果混入了损坏字节，修复逻辑可能把损坏点之后的数据也保留了下来，或者截断点恰好落在两个熵编码块之间的错误位置。解码器读到错误数据，颜色分量错位，画面就花掉了。
解决：把find_safe_eoi里遇到异常标记时的return i - 2改成return i - 1，或者更保守一点，从SOS段开始往前多留一个完整的DQT/DHT段体积。同时用PIL的Image.open().load()做校验，能成功读取像素数据才算过了第一关。
4.2 修复后的文件比原文件还大
现象：一个1.2MB的损坏JPEG修完变成2.3MB，打开却和原来一样模糊。
原因：没有把文件尾部的垃圾字节切干净。有的文件在损坏之后被覆盖写入过一段以0xFF开头的垃圾数据，扫描器把这些垃圾误当成新段收录进来，修复时全部保留，文件自然膨胀。
解决：修复函数里对EOI之后的字节直接丢弃。scan_segments里如果先遇到了EOI，直接break并返回，循环后面的内容一概不收。这是判断修复质量时一个很有用的指标：输出字节数应该接近原始文件，而不是暴涨。
4.3 修完还是提示“无法识别图像格式”
现象：修复工具运行后输出文件存在，但Windows照片查看器、PIL都打不开。
原因：文件名后缀是.jpg，但文件内容根本不是JPEG。很多从网上下载或从恢复软件里导出的文件只是被改了扩展名，实际可能是PNG、WebP，甚至是一个PDF的头部。
解决：修复之前先做魔数检查。JPEG的魔数是FF D8 FF，PNG是89 50 4E 47，WebP是52 49 46 46。在main()里读文件后先判断前三个字节：
if raw[:3] != b"\xFF\xD8\xFF": print("[错误] 文件头不是 JPEG 魔数，可能是其他格式") return 3如果魔数不对，就不要进修复流程，直接提示用户检查文件类型。
4.4 图片能打开，但拍摄信息、GPS、色彩空间全丢了
现象：修复后照片能看，但EXIF信息没了，相册软件里显示不出拍摄时间、光圈、快门。
原因：修复时为了“清理损坏”把APP1段也删了。很多修复脚本的逻辑是“只保留SOI、DQT、SOF、SOS、EOI”，把APP0和APP1当成可丢弃的东西。但APP1里装的恰恰是EXIF信息。
解决：修的时候注意保留APP0和APP1段。扫描器只要读到长度正常、内容完整的APP段的段头，就应该把它们原样复制到输出里。如果担心EXIF本身损坏，先解析APP1的长度字段，正常情况下它都是自洽的，不需要额外处理。
另外提醒一点：千万不要用“打开图片再另存为”的方式去修EXIF损坏的JPEG。另存为会重新编码像素，等于把原始压缩数据丢弃，画质和元数据都受影响。
4.5 批量修复同一批文件，只成功了一半
现象：一个文件夹里的200张损坏JPEG，跑完批量修复后只有120张能打开。
原因：这些“损坏”文件其实分属不同损坏模式。有的只是尾部缺EOI，有的是文件头被覆盖，有的在熵编码区有一大段0x00填充。同一个修复策略不可能对三种模式同时奏效——尾部缺EOI的加一个FF D9就好，头覆盖的需要回溯找SOI，而熵编码区被填0x00的要按转义规则处理才能避开。
解决：批量处理前先做分类。我一般用扫描器把每个文件的结构信息打印出来，看它缺什么元素：
python -c " import sys from importlib import import_module m = import_module('jpeg_repair') with open(sys.argv[1],'rb') as f: d = f.read() s = m.scan_segments(d) print([hex(marker) for _, marker, _ in s] if s else '无有效结构') " 坏照片.jpg这个命令把文件里的标记序列按顺序列出来，一眼就能看出是缺SOI、缺EOI，还是SOS之后根本没有有效熵数据。分类之后再决定用哪套修复参数，成功率会高很多。
5. 修复效果的验证与进阶玩法：不只看能不能打开，还要确认没修错
修复后的JPEG能不能算“修好了”，至少要过三重验证。第一重是结构验证：用PIL打开并解码成像素数据，确认尺寸、宽度、高度和原图描述一致。第二重是内容验证：看图像边缘是否出现异常的色带、马赛克块，通常我会把修复图和原图对应区域各截取一张小图对比。第三重是元数据验证：EXIF是否还在，色彩配置文件是否完整。
from PIL import Image def validate_jpeg(path: str) -> bool: try: with Image.open(path) as im: im.thumbnail((256, 256)) im.load() # 强制完成解码 return True except Exception as exc: print(f"[验证失败] {path}: {exc}") return Falsethumbnail在这里不是用来出缩略图，而是让PIL执行完整的解码流程，因为很多损坏会延迟到像素读取阶段才暴露。
进阶玩法上，我通常会把修复工具接在数据恢复流程的最末端：先用文件恢复工具把丢失文件从存储介质里提出来，再批量过一遍JPEG修复逻辑，最后用上面的验证函数自动筛选可打开的图片。这样既不用打开几百个文件手工检查，又能把恢复流程变成一条可重复执行的管道，配合调整熵数据截断的阈值参数，就能适应不同批次的损坏特征。
有个参数值得说一下，就是我前面提到的find_safe_eoi返回位置的微调。你要么选保守策略（保留更多损坏数据，给看图软件一点容错空间），要么选干净策略（严格截断到最后一个可信字节）。前者修完可能还能看到花屏边缘，后者更利于后期进一步裁剪。我个人的习惯是默认走保守策略，因为数据恢复场景里“保留所有可能”比“尽量干净”优先级高。
修复工具写到这里，它解决的是一个有限但极实际的问题：结构损坏的JPEG，不用重拍，不用付费软件，自己在本地就能修。从扫描段再到补EOI到验证，整条链路不超过150行Python代码，却能覆盖大多数日常遇到的“图片打不开”场景。希望帮到你。
本文还有配套的精品资源，点击获取
