Juh*_*älä 6 zip file-format specifications
我试图将日期存储为ZIP文件中的最新修改时间戳.似乎ZIP格式仅支持1980-01-01之后的日期作为最后修改时间(至少通过Java API java.util.zip.ZipEntry)
它是否正确？最早支持的修改时间戳真的是1980-01-01 00:00:00吗？我试图找到一些参考来验证这一点,但我找不到任何.
Del*_*ani 16
Zip条目时间戳仅记录两个2秒精度.这反映了创建PKZIP时使用的DOS时间戳的准确性.记录在Zip中的那个数字将是截断的时间戳,而不是最接近的2秒.
归档和还原文件时,它将不再具有与原始文件精确匹配的时间戳.这超出了他使用1毫秒精度的Java和使用100纳秒增量的Microsoft Windows的类似问题.PKZIP格式源自MS DOS天,因此时间仅使用16位,日期使用16位.在修订的PKZIP格式中定义了扩展时间戳,但Java不使用它.
内部zip文件,日期和时间以16位存储在本地时间,而不是传统的UTC,使用古老的MS DOS格式.位0是最不重要的位.格式是little-endian.在16位中没有空间来准确地表示时间,甚至到第二个,所以秒字段包含秒除以2的精度,仅精确到秒.
这意味着每次夏令时更改时,zip文件中的文件的明显时间与未压缩的文件相比会突然相差一小时.这也意味着zip实用程序将从Zip成员日期中提取不同的UTC时间,具体取决于计算完成的时区.这是荒唐的.PKZIP格式需要基于UTC的现代时间戳来避免这些异常.
更糟糕的是,WinZip或PKZIP等标准工具在恢复时总是将时间延长到下一秒甚至秒,从而可能使文件更年轻一秒到两秒.JDK(即ZipEntry中的javaToDosTime将时间向下舍入,从而使文件长一到两秒.
格式不支持1980-01-01 0:00 UTC之前的日期.避免文件日期1980-01-01或更早(本地或UTC时间).
等待!情况变得更糟.Phil Katz在记录Zip格式时,并没有费心去指定存档中使用的本地时间是白天还是标准时间.
为了限制它... Info-ZIP,JSE和TrueZIP在系统时间和DOS日期/时间之间转换时间的任何日期应用DST计划(DST在任何给定年份开始和结束的日期).这是应该的.Vista的Explorer,7-Zip和WinZip仅适用于DST节省,但不适用时间表.因此,在系统时间和DOS日期/时间之间转换时间时,它们会将当前的DST节省用于任何日期.这只是草率的.
http://mindprod.com/jgloss/zip.html
tar文件是这么好很多.