问题描述
我在尝试解压缩 zip 文件时遇到了这个问题.
I came up over this problem while trying to decompress a zip file.
-- zipfile.is_zipfile(my_file)
总是返回 False,即使 UNIX 命令 unzip 处理得很好.另外,当尝试执行 zipfile.ZipFile(path/file_handle_to_path)
时,我得到了同样的错误
-- zipfile.is_zipfile(my_file)
always returns False, even though the UNIX command unzip handles it just fine. Also, when trying to do zipfile.ZipFile(path/file_handle_to_path)
I get the same error
-- file
命令返回 Zip 存档数据,至少要提取 v2.0
并在它显示的文件上使用 less
:
-- the file
command returns Zip archive data, at least v2.0 to extract
and using less
on the file it shows:
PKZIP for iSeries by PKWARE长度方法大小 Cmpr 日期时间 CRC-32 名称2113482674 Defl:S 204502989 90% 2010-11-01 08:39 2cee662e myfile.txt2113482674 204502989 90% 1 个文件
有什么想法可以解决这个问题吗?如果我能让 python 的 zipfile
工作就好了,因为我已经有了一些单元测试,如果我切换到运行 subprocess.call("unzip") 就必须放弃这些测试
Any ideas how can I go around this issue ? It would be nice if I could make python's zipfile
work since I already have some unit tests that I'll have to drop if I'll switch to running subprocess.call("unzip")
推荐答案
在我的文件中遇到了同样的问题并且能够解决它.我不确定它们是如何生成的,就像上面的例子一样.最后,它们都有被 7z 忽略的 Windows 和失败的 python zipfile 的尾随数据.
Run into the same issue on my files and was able to solve it. I'm not sure how they were generated, like in the above example. They all had trailing data in the end ignored by both Windows by 7z and failing python's zipfile.
这是解决问题的代码:
def fixBadZipfile(zipFile):
f = open(zipFile, 'r+b')
data = f.read()
pos = data.find('\x50\x4b\x05\x06') # End of central directory signature
if (pos > 0):
self._log("Truncating file at location " + str(pos + 22) + ".")
f.seek(pos + 22) # size of 'ZIP end of central directory record'
f.truncate()
f.close()
else:
# raise error, file is truncated
这篇关于zipfile 无法处理某种类型的 zip 数据?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!