首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >System.IO.Compression邮编不使用协调时

System.IO.Compression邮编不使用协调时
EN

Stack Overflow用户
提问于 2014-09-26 02:21:14
回答 1查看 864关注 0票数 2

我刚开始在.NET 4.5中使用System.IO.Compression,发现了一个问题。它使用本地修改时间而不是通用UTC时间存储文件。

因此,如果您在一个时区压缩文件,然后在另一个时区解压缩它们,它将使用原始文件的本地修改时间(例如1 PM),并提取具有相同修改时间(也是1 PM)的文件,即使它应该早几个小时或晚几个小时。

我假设同样的问题也会存在于以标准时间或夏令时压缩的文件,以及稍后以其他时间解压的文件。

似乎在压缩过程中缺少设置,因为其他解压方法(WinZip,压缩文件夹解压)会产生相同的错误修改时间。

我测试过使用WinZip在不同时区压缩和解压缩文件,它没有这个问题。它必须在内部使用UTC进行修改。

除了在Zip和Unzip过程中建立自己的时移例程之外,还有什么方法可以解决这个问题吗?

此项目无法使用任何外部应用或库。我们仅限于使用.NET函数。

EN

回答 1

Stack Overflow用户

发布于 2019-04-08 15:43:56

正如Hans Passant在评论中提到的,zip文件格式使用MS-DOS Date & Time结构。

此结构被定义为两个单独的unsigned short值,如下所示:

代码语言:javascript
复制
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的链接,他发表了一条评论),包括各种时间戳。

代码语言:javascript
复制
0x000a        NTFS (Win9x/WinNT FileTimes)
0x000d        Unix

NTFS块是这样描述:

代码语言:javascript
复制
     -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块还包括两个时间戳:

代码语言:javascript
复制
     -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 ),因此它的存留时间也会更长。

票数 2
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/26045471

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档