验证这些文档的完整性的步骤是什么？ doc,docx,docm,odt,rtf,pdf,odf,odp,xls,xlsx,xlsm,ppt,pptm验证文档的完整性
或至少是其中的一些。通常在上传到内容存储库时。
我猜inputStream始终是99,99％从MultiPart http请求中正确读取，否则就会抛出异常并采取行动。但用户可以上传已损坏的文件 - 我是否使用第三方库来检查？我没有在odftoolkit，itextpdf，pdfbox，apache poi或tika中看到类似的东西
对于上面列出的所有文件格式，都有可以打开的第三方库等 - 我不知道“只有验证”，但我认为能够毫无例外地打开它们，至少是一个基本的检查，该文件是在指定的格式...一个这样的（商业）图书馆是Aspose - 不附属，只是一个幸福的客户。 ..
大多数情况下没有“开放”，但提供输入流和解析或获取dom模型等，这可能由于各种原因失败，但文档没有被破坏。这是没有趣的:-)有一件事是肯定的，我不会支付Aspose的7497美元:-)有太多的数字 – lisak
您可以在上传之前对文件执行校验和/哈希（即安全哈希），然后单独上传校验和。如果随后下载的文件具有相同的校验和，则它并没有从原始数据改变（根据所使用的校验和/散列的不同而有所不同）。
我提到运输没有问题，但用户可能已经损坏上传它。也许我不应该使用“完整性”一词， – lisak
“腐败”有很多种。
一些腐败应该很容易检测。例如，当您试图打开它时，截断的ODF文件很可能会失败，因为ZIP阅读器无法读取它。
其他几乎不可能检测到。例如，RTF文件中的一个字符损坏将无法检测到，所以（我认为）会将大部分RTF文件截断。
我会感到惊讶，如果你发现一个（免费的）工具，所有这些文件类型的做好这项工作，甚至在某种程度上，这在技术上是可行的。目前用于阅读/编写文档格式的开源库往往只关注一种格式。如果你对此很认真，你可能需要使用商业图书馆。
去检查LibreOffice项目（已经处理这些档案），它有部分用Java编写，并且确定你可以找到并使用它们的机制来检查损坏的文件。
我想你可以从这里获取代码：
你在找什么样的腐败？商榷？偶然？单个字节损坏？文件被截断了吗？是否足以说“该文件看起来有点不安”，或者您是否只接受在Office 2003 build 12345或Office 2008 for Mac build 4321中声明未打开的文件？ – Gagravarr
我只是想知道如何处理TikaException，因为解析是你可能会发现这个问题的地方，但是你会在解析过程中发生什么样的问题。在这种情况下应该做什么？我真的对文档的交付负责，这不像我将文件存储在内容存储库中。我之前没有处理文档的经验，您能给出一些数字吗？概率？统计数据？ – lisak