我刚开始在.NET 4.5中使用System.IO.Compression,发现了一个问题。它使用本地修改时间而不是通用UTC时间存储文件。
因此,如果您在一个时区压缩文件,然后在另一个时区解压缩它们,它将使用原始文件的本地修改时间(例如1 PM),并提取具有相同修改时间(也是1 PM)的文件,即使它应该早几个小时或晚几个小时。
我假设同样的问题也会存在于以标准时间或夏令时压缩的文件,以及稍后以其他时间解压的文件。
似乎在压缩过程中缺少设置,因为其他解压方法(WinZip,压缩文件夹解压)会产生相同的错误修改时间。
我测试过使用WinZip在不同时区压缩和解压缩文件,它没有这个问题。它必须在内部使用UTC进行修改。
除了在Zip和Unzip过程中建立自己的时移例程之外,还有什么方法可以解决这个问题吗?
此项目无法使用任何外部应用或库。我们仅限于使用.NET函数。
发布于 2019-04-08 15:43:56
正如Hans Passant在评论中提到的,zip文件格式使用MS-DOS Date & Time结构。
此结构被定义为两个单独的unsigned short值,如下所示:
wFatDate
The MS-DOS date. The date is a packed value with the following format.
Bits Description
0-4 Day of the month (1–31)
5-8 Month (1 = January, 2 = February, and so on)
9-15 Year offset from 1980 (add 1980 to get actual year)
wFatTime
The MS-DOS time. The time is a packed value with the following format.
Bits Description
0-4 Second divided by 2
5-10 Minute (0–59)
11-15 Hour (0–23 on a 24-hour clock)在MS-DOS创建之时,这些计算机还没有使用时区(Unix从1970年起就有了这个概念)。使用MS-DOS的人通常在办公室或家里,不会通过计算机与其他州的人交流,更不用说其他国家的人了。内部网在当时也相当昂贵。
创建zip文件格式的公司犯了使用FAT文件系统日期格式的错误,并坚持了下来。因此,zip文件是使用本地时间创建的(它不需要这样做,但至少是预期的行为)。
压缩格式提供了添加extensions的方法(来自@user3342816的链接,他发表了一条评论),包括各种时间戳。
0x000a NTFS (Win9x/WinNT FileTimes)
0x000d UnixNTFS块是这样描述:
-PKWARE Win95/WinNT Extra Field:
==============================
The following description covers PKWARE's "NTFS" attributes
"extra" block, introduced with the release of PKZIP 2.50 for
Windows. (Last Revision 20001118)
(Note: At this time the Mtime, Atime and Ctime values may
be used on any WIN32 system.)
[Info-ZIP note: In the current implementations, this field has
a fixed total data size of 32 bytes and is only stored as local
extra field.]
Value Size Description
----- ---- -----------
0x000a Short Tag (NTFS) for this "extra" block type
TSize Short Total Data Size for this block
Reserved Long for future use
Tag1 Short NTFS attribute tag value #1
Size1 Short Size of attribute #1, in bytes
(var.) SubSize1 Attribute #1 data
.
.
.
TagN Short NTFS attribute tag value #N
SizeN Short Size of attribute #N, in bytes
(var.) SubSize1 Attribute #N data
For NTFS, values for Tag1 through TagN are as follows:
(currently only one set of attributes is defined for NTFS)
Tag Size Description
----- ---- -----------
0x0001 2 bytes Tag for attribute #1
Size1 2 bytes Size of attribute #1, in bytes (24)
Mtime 8 bytes 64-bit NTFS file last modification time
Atime 8 bytes 64-bit NTFS file last access time
Ctime 8 bytes 64-bit NTFS file creation time
The total length for this block is 28 bytes, resulting in a
fixed size value of 32 for the TSize field of the NTFS block.
The NTFS filetimes are 64-bit unsigned integers, stored in Intel
(least significant byte first) byte order. They determine the
number of 1.0E-07 seconds (1/10th microseconds!) past WinNT "epoch",
which is "01-Jan-1601 00:00:00 UTC".Unix块还包括两个时间戳:
-PKWARE Unix Extra Field:
========================
The following is the layout of PKWARE's Unix "extra" block.
It was introduced with the release of PKZIP for Unix 2.50.
Note: all fields are stored in Intel low-byte/high-byte order.
(Last Revision 19980901)
This field has a minimum data size of 12 bytes and is only stored
as local extra field.
Value Size Description
----- ---- -----------
0x000d Short Tag (Unix0) for this "extra" block type
TSize Short Total Data Size for this block
AcTime Long time of last access (UTC/GMT)
ModTime Long time of last modification (UTC/GMT)
UID Short Unix user ID
GID Short Unix group ID
(var) variable Variable length data field
The variable length data field will contain file type
specific data. Currently the only values allowed are
the original "linked to" file names for hard or symbolic
links, and the major and minor device node numbers for
character and block device nodes. Since device nodes
cannot be either symbolic or hard links, only one set of
variable length data is stored. Link files will have the
name of the original file stored. This name is NOT NULL
terminated. Its size can be determined by checking TSize -
12. Device entries will have eight bytes stored as two 4
byte entries (in little-endian format). The first entry
will be the major device number, and the second the minor
device number.
[Info-ZIP note: The fixed part of this field has the same layout as
Info-ZIP's abandoned "Unix1 timestamps & owner ID info" extra field;
only the two tag bytes are different.]正如我们所看到的,NTFS和Unix块清楚地将它们的时间戳定义为使用UTC。NTFS日期比Unix时间戳(1s)更精确(100ms),由于它使用64位(有关32位时间戳的更多详细信息,请参阅Year 2038 Problem ),因此它的存留时间也会更长。
https://stackoverflow.com/questions/26045471
复制相似问题