zipfile愚蠢地破碎了 [英] zipfile stupidly broken
问题描述
引用zipfile.py（2.4库）：
＃搜索文件的最后END_BLOCK字节以获取记录签名。 />
＃注释附加到ZIP文件，长度为16位。
＃所以注释可能长达64K。我们将搜索
＃签名限制在文件末尾的几千字节以提高效率。
＃也是，签名不得出现在评论中。
END_BLOCK = min（filesize，1024 * 4）
所以作者知道评论有64K的硬限制
大小，但感觉更重要的是，当你的b $ b不是一个zipfile或者一个完全合法的zipfile
没有观察到他的特殊4K限制。我没有时间
找到一个更温和的方式说出来因为我必须找到一个解决方法
这个任意限制（1）：这是愚蠢的。
（1）领先的候选人是复制并粘贴整个frigging
zipfile模块，所以我可以修补它，但这甚至比它更丑陋br />
愚蠢。 这个电池正在为峡湾而烦恼！
通常我鄙视在回复列表或团体流量时被CC'，但在这种情况下它是
可能是必要的，因为我已经没有时间和这个地方保持好几年了。 ： - /
-
为了活着，是不是一次又一次地惊讶？b $ b - Nicholas van Rijn
To quote from zipfile.py (2.4 library):
# Search the last END_BLOCK bytes of the file for the record signature.
# The comment is appended to the ZIP file and has a 16 bit length.
# So the comment may be up to 64K long. We limit the search for the
# signature to a few Kbytes at the end of the file for efficiency.
# also, the signature must not appear in the comment.
END_BLOCK = min(filesize, 1024 * 4)
So the author knows that there''s a hard limit of 64K on the comment
size, but feels it''s more important to fail a little more quickly when
fed something that''s not a zipfile - or a perfectly legitimate zipfile
that doesn''t observe his ad-hoc 4K limitation. I don''t have time to
find a gentler way to say it because I have to find a work around for
this arbitrary limit (1): this is stupid.
(1) the leading candidate is to copy and paste the whole frigging
zipfile module so I can patch it, but that''s even uglier than it is
stupid. "This battery is pining for the fjords!"
Normally I despise being CC''d on a reply to list or group traffic, but
in this case it''s probably necessary, as I haven''t had time to keep up
with this place for several years. :-/
--
To be alive, is that not to be
again and again surprised? -- Nicholas van Rijn
推荐答案
En Wed，2007年5月16日12:18:35 -0300，Martin Maney< ma *** @ two14 .net>
$ b $bescribió：
En Wed, 16 May 2007 12:18:35 -0300, Martin Maney <ma***@two14.net>
escribió:
所以作者知道评论中有64K的硬限制
大小，但感觉更重要的是，当你的b $ b不是一个zipfile或者一个完全合法的zipfile
没有观察到他的特殊4K限制。我没有时间
找到一个更温和的方式说出来因为我必须找到一个解决方法
这个任意限制（1）：这是愚蠢的。
So the author knows that there''s a hard limit of 64K on the comment
size, but feels it''s more important to fail a little more quickly when
fed something that''s not a zipfile - or a perfectly legitimate zipfile
that doesn''t observe his ad-hoc 4K limitation. I don''t have time to
find a gentler way to say it because I have to find a work around for
this arbitrary limit (1): this is stupid.
这不是报告错误的好地方 - 使用
http://sourceforge.net/bugs/?group_id=5470
-
Gabriel Genellina
This is not a good place for reporting bugs - use
http://sourceforge.net/bugs/?group_id=5470
--
Gabriel Genellina
Martin Maney写道：
Martin Maney wrote:
引用zipfile.py（ 2.4库）：
＃搜索文件的最后END_BLOCK个字节以获取记录签名。
＃注释附加到ZIP文件并且有一个16位长度。
＃所以评论可能长达64K。我们将搜索
＃签名限制在文件末尾的几千字节以提高效率。
＃也是，签名不得出现在评论中。
END_BLOCK = min（filesize，1024 * 4）
所以作者知道评论有64K的硬限制
大小，但感觉更重要的是，当你的b $ b不是一个zipfile或者一个完全合法的zipfile
没有观察到他的特殊4K限制。我没有时间
找到一个更温和的方式说出来因为我必须找到一个解决方法
这个任意限制（1）：这是愚蠢的。
（1）领先的候选人是复制并粘贴整个frigging
zipfile模块所以我可以修补它，但这甚至更加丑陋比它好b / b
愚蠢。 这个电池正在为峡湾而烦恼！
通常情况下，我鄙视在回复列表或团体流量时被CC'，但
在这种情况下，它可能是必要的，因为我没有时间跟这个地方保持好几年的b $ b。 ： - /
To quote from zipfile.py (2.4 library):
# Search the last END_BLOCK bytes of the file for the record signature.
# The comment is appended to the ZIP file and has a 16 bit length.
# So the comment may be up to 64K long. We limit the search for the
# signature to a few Kbytes at the end of the file for efficiency.
# also, the signature must not appear in the comment.
END_BLOCK = min(filesize, 1024 * 4)
So the author knows that there''s a hard limit of 64K on the comment
size, but feels it''s more important to fail a little more quickly when
fed something that''s not a zipfile - or a perfectly legitimate zipfile
that doesn''t observe his ad-hoc 4K limitation. I don''t have time to
find a gentler way to say it because I have to find a work around for
this arbitrary limit (1): this is stupid.
(1) the leading candidate is to copy and paste the whole frigging
zipfile module so I can patch it, but that''s even uglier than it is
stupid. "This battery is pining for the fjords!"
Normally I despise being CC''d on a reply to list or group traffic, but
in this case it''s probably necessary, as I haven''t had time to keep up
with this place for several years. :-/
你认真吗？一个带有注释4Kbytes的zipfile。我从来没有遇到过这样的野兽。
与任何开源产品一样，卷起袖子要好得多
和投入来解决问题，而不是关于如何愚蠢地打破b $ b $。欢迎您提交补丁或至少一个好的
描述问题和可能的解决方案。如果你从Python中获得了很多价值，你可以考虑这个回馈。你
没有为它提供的价值支付任何费用。
-Larry
Are you serious? A zipfile with a comment 4Kbytes. I''ve never encountered
such a beast.
As with any open source product it is much better to roll up your sleeves
and pitch in to fix a problem than to rail about "how it is stupidly
broken". You are welcome to submit a patch or at the very least a good
description of the problem and possible solutions. If you have gotten a
lot of value out of Python, you might consider this "giving back". You
haven''t paid anything for the value it has provided.
-Larry
5月17日上午5:38，Gabriel Genellina < gagsl -... @ yahoo.com.ar>
写道：
On May 17, 5:38 am, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
wrote:
这不是报告错误的好地方 - 使用 http://sourceforge.net/bugs/?group_id=5470
我不同意。鉴于大多数疑似错误都没有，新用户
特别明智的做法是在提交错误之前在这里发布他们的错误
报告。
I disagree. Given that most suspected bugs aren''t, new users
especially would be wise to post their "bugs'' here before filing a bug
report.
这篇关于zipfile愚蠢地破碎了的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
