我在 Apple Books 中有一本来自 iPad 本地文件的书（PDF）。我在 PDF 上记了 2 个月的笔记。
今天我无法打开它并出现错误：
“无法打开文档。无法打开''”
于是我将文件空投到 Mac 上，尝试在 Preview、Adobe 和 Acrobat 中打开它。无论我在哪里尝试打开它，都无法打开。它可能已损坏或损坏。
我尝试使用 Ghostscript ( gs) 来修复它，但是没有效果：
gs \
-o repaired.pdf \
-sDEVICE=pdfwrite \
-dPDFSETTINGS=/prepress \
corrupted.pdf
我得到的却是错误：
Catalog dictionary not located in file, unable to proceed
**** Error: Couldn't initialise file.
Output may be incorrect.
No pages will be processed (FirstPage > LastPage).
The following errors were encountered at least once while processing this file:
startxref offset invalid
xref table was repaired
**** This file had errors that were repaired or ignored.
**** Please notify the author of the software that produced this
**** file that it does not conform to Adobe's published PDF
**** specification.
我尝试更新 iPad 并重新启动，但似乎无法解决问题。
该文件大约有 150MB。我该怎么做才能恢复它？
答案1
59 年半以来，我一直是个处理计算机数据的男孩和男人，过去 40 年来，我一直在解决各种级别的数据丢失问题，包括不可靠的开关和继电器、撕裂的纸带和虫蛀的卡片、拉伸的磁带和电缆、弯曲或破裂的磁盘和不稳定的芯片。有些惊人的故事，我不能说，否则你会怀疑我的理智，怀疑雇用我的人，怀疑那些感染了他们数据的人。
因此，第一个建议是找出原因，哪怕是老生常谈的“你关掉墙上的电源了吗？”
下一步是评估恢复的机会与再次恢复的成本。
所以这是一个有趣的挑战，但答案并不好。
如果您认为编辑设备可能隐藏了已删除的副本，并且更换成本极高，那么可能值得花钱将断电的设备接入诊断系统，以便对磁盘进行镜像和扫描，以查找已删除的%PDF-标头。
现代磁盘往往无法实现这一点（固态），也无法像以前那样容易地实现，而是通过快速重新使用释放的空间来作为大内存存储缓存，从而覆盖丢失的数据。
现在来到“可疑”保存文件的中心。
它保留了大部分所需数据。然而，与未编辑的源文件相比，我们可以说损失非常严重。
源 PDF 已被编辑过两次（一次是新封面？还有一次是小调整），因此因添加不同的编辑而留下了一些奇怪之处（虽然不常见但应该避免）。
core /Size 39679 objects
edit /Size 39692
edit /Size 39694
如果我重新构造该源文件，工作计数将优化为 /Size 37546 个对象。这表明存在一些冗余，但同样并不罕见。
2 个月内每天添加的条目数应该不少于 40,000 或更多。但是它报告的条目数为 /Size 70957。确认文件一次应该非常大。因此，额外的约 32,000 个条目需要全部保存在保留文件中，但相对而言比要求的要小。
作为测试（为了进行比较），我只恢复了一页注释（不知道它覆盖了哪几页）。它可能并不典型，但一页大约有 120 KB。
这里可能没有什么意义，因为您无法脱离上下文看到这里的组件，但这是最后一页更改（参见日期），大概在右侧页面上。
我们可以将其放在新的封面上（仍然不是正确的未知已删除页面）
总结一下，我的直觉是，恢复成本低，保留对象数量少（/Annots 的数量 = 大约 57（页数？），表明恢复成本比“再做一次”的人工成本更高。诱人的是，从 67961 到 70957 有一个很好的组，因此这些组应该是可以恢复的。
我发现的最好的恢复应用程序https://superuser.com/a/1808687/1769247。仅显示从名义页码 180 到总计 849 页中的 240 页的对象，并且实际上复制了两倍以上的额外图像页面，因为从图形角度来看，一些页面将是软掩模的负片，因此 850-1845 可能是 180-240 的子图像副本，也可能是其他页面的片段？
这是剩余部件的 30 天修复链接https://filetransfer.io/data-package/nbXvfSBp#link
下一步建议
将主文件分成 4 个方便的部分，这有三重好处。
- 每个部分将更快地呈现和响应大量注释。
- 修复源文件中的任何基础问题。
- 将未来灾难损失一次性减少到仅 25%。
重新考虑注释软件处理所需的大量内存和“电压下降”损失的可能性的能力，任何暂时的故障都可能破坏打开的编辑文件。
在可靠的本地磁盘系统（如工作站）上工作，而不要使用同步的云驱动器。
不要使用修复后的文件本身，只需将其用作重复任务的提示。可能包括 PDF GUI 编辑器中的剪切和粘贴对象，这应该可以避免任何其他故障的延续。
具体情况可能不同。
您可能会发现页码不同步但顺序正确，或者幸运的是，顺序完美，适合传输到主文件中。如果是这种情况，那么有一些命令行工具“可能”通过从恢复文件导出 /Annots（例如 JSON）来加速传输，然后允许通过页码导入到经过适当优化的主文件中。一种这样的工具可能是 coherent cpdf，因为它有一个优化工具和 /Annots 导出导入。但我不能说它是否能很好地解决这个问题。