那天下午，我在一台 2013 年的联想 G480 上，找回了一张只剩 640×480 的缩略图。

昨天下午，也就是 10 月 1 日两点半左右，我从柜子深处翻出那台 2013 年的联想 G480，它的电池早就鼓了，只能插着电源开机。我打开它，是因为我记得 2023 年 11 月在仙台青叶通拍的那组照片，最早是在这台机器上做过一次离线备份。开机等了将近四分钟，桌面出现的时候我几乎已经放弃了，直到在 D:\备份\2023\仙台 目录里看到一排带着 .tmp 后缀的残片文件，共 214 个。

这 214 个文件里，绝大多数只有几十 KB，用看图软件打开是一半灰一半正常。我最初的思路很朴素：既然要恢复49图库图片，那就先把所有以 FF D8 开头的数据段都找出来。于是我动手做了两件看起来有点笨的事——第一，用 打开49图库在线浏览器 的方式，把每张缩略图在浏览器里逐帧加载，观察 Network 面板里返回的 Content-Length 和实际解码尺寸是否一致；第二，用 WinHex 在整个 Cache 目录里搜索 JPEG 的头尾标记。前者花了我大约八分钟，后者花了将近一小时。

结果比预期复杂。214 段候选数据中，只有 39 段带有完整的 FF D9 收尾标记，其余都是被写入中断截断的残片。老周在下午三点十七分给我打了个电话，他说先别急着点任何软件里的"修复"按钮，先用 certutil -hashfile 对原始分区算一次 SHA-256，把值记下来——他报出的数字是 3f9a…c7e2，我原样抄在一张黄色便签上，贴到显示器右边边框。这个动作后来救了我：在我第二次尝试覆盖写入时，正是靠这个哈希值确认了原盘没有被污染。

接下来是比对。我把 39 段残片按拍摄时间排序，回到 49图库官方平台 检索同期相册，惊喜地发现其中 11 张在云端仍保留着 1280 宽的副本。这一发现改变了我整个恢复策略：与其对那几张最模糊的图做插值补偿，不如直接用云端副本替换。剩下的 28 张里，我又用 qq浏览器打开本地文件 的方式逐张试了一遍，它的解码器对截断数据有出人意料的容错，竟有 4 张在 Chrome 里显示破损的图，在这里被补齐了下半部分。

说实话，我不太认同市面上"一键恢复"这类工具的定位，它们被严重高估了。真正的问题不在软件版本，而在于多数工具对缩略图残片只做粗暴的 0 填充，出来的图边缘会出现整齐的灰块，肉眼一看就知道是伪造的。相比之下，《数字取证基础》2019 年第二版第 118 页关于"用相邻块 DC 系数估算截断位置"的讨论，虽然操作起来繁琐到让人烦躁——按那个思路我手工确认了一张又一张，成功率大概提升到六成——但至少它承认了恢复本身的不完美，而不是用漂亮的界面掩盖损失。

到晚上七点四十，最终可用的只有 4 张，平均分辨率 612×459，这个数字我写在便签背面，和那个哈希值贴在一起。失望是真的：176 张原始照片，最后只换回四张低分辨率的影子。但意外的收获也真实地摆在那里——其中一张拍到了我一直记不起名字的那家旧书店招牌，招牌上"青葉書房"四个字还能辨认。我把恢复结果按拍摄时间重命名，写成 202311_x_original.jpg 这样的格式，并另建了一个只读目录，旁边附一份 CSV，记录每张图的来源块偏移、恢复置信度和使用的解码器。恢复49图库图片走到最后，靠的不是某一个神乎其神的软件，而是一套能被别人复核、也能被自己复盘的过程。