当前位置：文江博客话题详情

ZIP 文件格式支持的最早时间戳值是多少？

发布于 2024-09-19 20:17:01 字数 298 浏览 6 评论 0原文

我正在尝试将日期存储为 ZIP 文件中的最新修改时间戳。看来 ZIP 格式仅支持 1980-01-01 之后的日期作为最后修改时间（至少通过 Java API java.util.zip.ZipEntry ）

这是正确的吗？最早支持的修改时间戳真的是 1980-01-01 00:00:00 吗？我试图找到一些参考资料来验证这一点，但我找不到任何参考资料。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

许仙没带伞 2024-09-26 20:17:01

仅记录邮政编码条目时间戳
精确到两个 2 秒。这
反映了DOS的准确性
PKZIP 时使用的时间戳
创建的。该数字记录在
Zip 会将时间戳截断，
不是最近的 2 秒。
当您归档和恢复文件时，
它将不再有时间戳
与原版完全一致。这
超越了类似的问题
Java 使用 1 毫秒
精度和 Microsoft Windows 使用
100 纳秒增量。 PKZIP
格式源自 MS DOS 时代并且
因此仅使用 16 位来表示时间
16 位日期。定义了一个
修订后的延长时间戳
PKZIP格式，但Java不使用
它。
在 zip 文件内，日期和时间是
以 16 位存储本地时间，而不是
与传统的 UTC 一样，使用
古老的 MS DOS 格式。位 0 是
最低有效位。格式为
小尾数法。里面没有空间了
16位精确表示时间
甚至到秒，所以秒
字段包含秒数除以
二、只给偶数提供准确度
第二。
这表示文件的表观时间
拉链内会突然有所不同
与他们相比一个小时
每次都是未压缩的对应项
您有夏令时变更。它
也意味着 zip 实用程序将
从a中提取不同的UTC时间
邮政编码会员日期取决于哪个
完成计算的时区。
这太荒谬了。 PKZIP格式需要
要避免的现代基于 UTC 的时间戳
这些异常现象。
更糟糕的是，标准工具
像 WinZip 或 PKZIP 总是四舍五入
到下一偶数秒的时间
当它们恢复时，因此可能
将文件从一秒变为两秒
年轻几秒。 JDK（即
ZipEntry 中的 javaToDosTime 舍入
时间减少，从而使文件成为一个
提前两秒。
该格式不支持日期
UTC 时间 1980 年 1 月 1 日 0:00 之前。避免
文件日期 1980-01-01 或更早
（本地或 UTC 时间）。
等等！情况变得更糟。菲尔·卡茨,
当他记录 Zip 格式时，
懒得指定是否
存档中使用的当地时间应该
为夏令时或标准时间。
最后……Info-ZIP、JSE 和
TrueZIP 应用 DST 时间表（天
任何给定的夏令时开始和结束的地方
年）对于转换时的任何日期
系统时间与DOS时间之间的时间
日期/时间。这是应该的。
Vista 的 Explorer、7-Zip 和 WinZip
仅适用 DST 节省，但不适用
应用时间表。所以他们使用
任何日期的当前夏令时节省
系统时间之间的转换
和 DOS 日期/时间。这只是
草率。

http://mindprod.com/jgloss/zip.html

tar文件如此好多了。

Zip entry timestamps are recorded only
to two 2 second precision. This
reflects the accuracy of DOS
timestamps in use when PKZIP was
created. That number recorded in the
Zip will be the timestamp truncated,
not the nearest 2 seconds.
When you archive and restore a file,
it will no longer have a timestamp
precisely matching the original. This
is above and beyond he similar problem
with Java using 1 millisecond
precision and Microsoft Windows using
100 nanosecond increments. PKZIP
format derives from MS DOS days and
hence uses only 16 bits for time and
16 bits for date. There is defined an
extended time stamp in the revised
PKZIP format, but Java does not use
it.
Inside zip files, dates and times are
stored in local time in 16 bits, not
UTC as is conventional, using an
ancient MS DOS format. Bit 0 is the
least signifiant bit. The format is
little-endian. There was not room in
16 bit to accurately represent time
even to the second, so the seconds
field contains the seconds divided by
two, giving accuracy only to the even
second.
This means the apparent time of files
inside a zip will suddenly differ by
an hour compared with their
uncompressed counterparts every time
you have a daylight saving change. It
also means that the a zip utility will
extract a different UTC time from a
Zip member date depending on which
timezone the calculation was done.
This is ridiculous. PKZIP format needs
a modern UTC-based timestamp to avoid
these anomalies.
To make matters worse, Standard tools
like WinZip or PKZIP will always round
the time up to the next even second
when they restore, thereby possibly
making the file one second to two
seconds younger. The JDK (i.e.
javaToDosTime in ZipEntry rounds the
time down, thereby making the file one
to two seconds older.
The format does not support dates
prior to 1980-01-01 0:00 UTC. Avoid
file dates 1980-01-01 or earlier
(local or UTC time).
Wait! It gets even worse. Phil Katz,
when he documented the Zip format, did
not bother to specify whether the
local time used in the archive should
be daylight or standard time.
And to cap it off… Info-ZIP, JSE and
TrueZIP apply the DST schedule (days
where DST began and ended in any given
year) for any date when converting
times between system time and DOS
date/time. This is as it should be.
Vista’s Explorer, 7-Zip and WinZip
apply only the DST savings, but do not
apply the schedule. So they use the
current DST savings for any date when
converting times between system time
and DOS date/time. This is just
sloppy.