就我所知, zip -T 选项仅确定是否可以提取文件——它并没有真正测试存档的内部完整性。例如,我故意破坏了文件的本地(不是中央目录)CRC,而 zip 根本不在乎,报告存档正常。有没有其他实用程序可以做到这一点?
ZIP 文件中有很多内部冗余,如果有办法检查所有内容就好了。当然,通常中央目录就是您所需要的,但是在修复损坏的存档时,通常您所拥有的只是一个碎片,中央目录被破坏或丢失。我想知道我创建的档案是否尽可能可恢复。
The*_*tus 36
解压 -t
测试存档文件。
此选项提取内存中的每个指定文件,并将扩展文件的 CRC(循环冗余校验,增强校验和)与原始存储的 CRC 值进行比较。
[来源:https : //linux.die.net/man/1/unzip ]
Ste*_*itt 24
尝试修复存档将比较本地和中央 CRC,并将其与存档测试相结合将允许检查所有 CRC。如果你跑
unzip -t archive.zip
Run Code Online (Sandbox Code Playgroud)
和
zip -F archive.zip --out archivefix.zip
Run Code Online (Sandbox Code Playgroud)
并且都没有抱怨,这意味着档案的内容与中央和地方 CRC 相匹配。(您可以archivefix.zip稍后删除。)
为了验证这一点,从zip3.0的 Info-ZIP 源代码开始,我创建了一个文件,如下所示:
zip -9 test.zip zip.txt zipup.c
Run Code Online (Sandbox Code Playgroud)
然后我zip.txt通过更改偏移量 0xB137 处的字节来破坏中央目录 CRC 。我的行为与你观察到的相反;unzip -v从中央目录报告更改的 CRC,但unzip -t并zip -T报告文件正常(对照本地 CRC 检查)。
但是跑步
zip -F test --out testfix
Run Code Online (Sandbox Code Playgroud)
报道
Fix archive (-F) - assume mostly intact archive
Zip entry offsets do not need adjusting
copying: zip.txt
zip warning: Local Entry CRC does not match CD: zip.txt
copying: zipup.c
Run Code Online (Sandbox Code Playgroud)
“更正”文件仍然列出了zip.txt.
更改zip.txt偏移量 0x10 处的本地 CRC 会导致unzip -t和zip -T报告 CRC 错误,但zip -F没有发现任何错误。
因此,根据我的实验,可以如下检测存档条目的内容与其 CRC 之间的不匹配:
zip -T和unzip -t;zip -F也会抱怨地方中央不匹配zip -T和unzip -tzip -T并unzip -t不会抱怨,而是zip -F将指示本地中央不匹配(请注意,默认情况下zip -T仅使用unzip -tqq, sozip -T和unzip -t真的是等价的。您可以阅读unzip源代码来检查测试档案是否真的比较了本地CRC,而不是中央CRC;在 中查找extract_or_test_files(), extract_or_test_entrylist()and extract_or_test_member(), all in extract.c。)