我正在使用 chilkat 从 FTP 服务器下载大型 .zip 文件。文件大小通常在 12-13GB 左右，下载后我需要验证文件是否未损坏。
我正在尝试使用 ICSharpCode.SharpZipLib.Zip
像这样 ZipFile zip = new ZipFile(path); bool isValidZip = zip.TestArchive(true, TestStrategy.FindFirstError, null);
但是验证需要很长时间甚至崩溃..
有没有更快的解决方案？
如果客户正在上传到 FTP，那么也许客户也可以上传 SHA256 哈希。例如，如果客户上传 x.zip，则计算 x.zip 的 SHA256 并上传 x.zip.sha256。然后您的应用程序可以下载 x.zip 和 x.zip.sha256，然后使用 Chilkat.Crypt2.HashFile 对 x.zip 进行散列并检查 x.zip.sha256。
如果无法获得预期的哈希值，那么您可能首先根据服务器上的内容检查文件大小。FTP 服务器在提供文件信息的方式上可能有所不同。较旧的服务器将提供人类可读的目录列表（LIST 命令），而较新的服务器（即在过去 10 年内）支持 MLSD。如果可能，Chilkat 将使用 MLSD。较旧的 FTP 服务器可能会提供准确（不准确）的文件大小信息，而 MLSD 将是准确的。可以调用Ftp2.Feat方法查看是否支持MLSD。如果是这样，那么您可以先验证下载文件的大小。如果它不是预期的大小，那么您可以跳过任何剩余的验证，因为您已经知道它是无效的。（你可以设置 Ftp2.AutoGetSizeForProgress = true，
假设字节数相等，或者如果您无法获得准确的字节数，并且您没有预期的哈希值，那么您可以测试以查看 zip 是否有效。第一个选项是调用 Chilkat.Zip.OpenZip 方法。打开 .zip 将遍历 zip 的本地文件头和中央目录头。如果 .zip 损坏，大多数错误都会被捕获。只有通过实际解压缩 zip 中每个文件的数据才能进行更全面的检查——这可能就是 SharpZipLib 需要这么长时间的原因。验证压缩数据的唯一方法是实际进行解压缩。损坏的字节可能会导致解压缩器遇到不可能的内部状态，这显然是损坏的。此外，未压缩数据的 CRC-32 存储在 .zip 中的每个本地文件头中。检查 CRC-32 需要解压。SharpZipLib 肯定会检查 CRC-32（在解压缩之后，它可能试图在内存中解压缩并耗尽内存）。Chilkat.OpenZip 不检查 CRC-32，因为它没有解压。你可以调用 Chilkat.Unzip 来解压到文件系统，解压的过程也会检查 CRC-32。
无论如何..您可能会决定检查字节数并能够成功调用 Chilkat.Zip.OpenZip 就足以进行验证检查。
否则，如果您正在处理大文件，最好在系统架构中设计验证（使用并行 .sha256 文件）。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句