驗證這些文檔的完整性的步驟是什麼？ 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