英文:
File Manager of windows 10 showing wrong timezone for zip preview
问题
在创建zip文件时，我将最后修改日期设置为当前时间（毫秒）以用于所有zipEntries。但是，在文件管理器中预览文件时，显示的最后修改日期是在WET时区（与创建zip的构建服务器相同时区）。
但是，如果我在Winrar应用程序中打开同一pdf文件，它会显示与本地相同的最后修改日期。
请查看下面的示例代码片段
ZipOutputStream zout = new ZipOutputStream(new BufferedOutputStream(new FileOutputStream(zipPath + fileName)), Charset.forName("UTF-8"));
ZipEntry zEntry = new ZipEntry("filePath");
zEntry.setLastModifiedTime(FileTime.fromMillis(System.currentTimeMillis()));
zout.putNextEntry(zEntry);
// 在zip文件中使用BufferedInputStream写入文件逻辑
zout.flush();
zout.closeEntry();
如何解决这个问题？
英文:
While creating zip I am adding the last modified date as the current time mili for all zipEntries. But previewing the file in file-manager shows the lastModifiedate in WET timezone (same timezone as the build server from where the zip is created).
But if I open the same pdf in Winrar application it shows the lastModifiedDate in same timezone as local
Please find the sample code snippet below
ZipOutputStream zout = new ZipOutputStream(new BufferedOutputStream(new FileOutputStream(zipPath + fileName)), Charset.forName("UTF-8"));
ZipEntry zEntry = new ZipEntry("filePath");
zEntry.setLastModifiedTime(FileTime.fromMillis(System.currentTimeMillis()));
zout.putNextEntry(zEntry);
//file write logic in zip file with BufferedInputStream
zout.flush();
zout.closeEntry();
How to resolve this issue?
答案1
得分: 2
我不知道你问题的解决方案，但我可以提供一些可能帮助你的提示。
基本的ZIP文件格式存储本地的最后修改时间，但没有时区信息。如果该时间用于显示或提取，它将在任何地方都是相同的本地时间，因此在与创建时的时区不同的地方查看时将不正确。
ZIP格式比较老旧，这个缺陷通过文件头和中央目录中的“额外”字段进行了纠正。通常情况下，Java的ZipOutputStream不会写入这样的额外字段。但是，如果你使用setLastModifiedTime，它会写入一个“扩展时间戳”（0x5455）字段，使用的是UT时间，而不是本地时间。该扩展时间戳字段使用Unix格式表示时间（自1970年1月1日UTC以来的秒数）。
现在，由查看或提取ZIP文件的工具决定是否查看和使用该额外字段。我不能确定你的文件管理器或WinRAR在这种情况下的具体操作。ZIP文件头中还定义了其他用于存储时间的额外字段，包括一个“NTFS”额外字段（0x000a），其中包含Windows的修改、访问和创建时间。不同的ZIP文件软件可能在ZIP文件头中查找这些和其他额外字段的一些、全部或没有。
英文:
I don't know the resolution to your problem, but I can provide some hints that may get you there.
The base zip file format stores a local last modified time with no time zone. If that time is used for display or extraction, it will be the same local time anywhere, and so will be incorrect if looked at in a time zone different from the one in which it was made.
The zip format is old, and that deficiency was corrected with "extra" fields in the file headers and central directory. Normally Java's ZipOutputStream does not write such an extra field. However if you use setLastModifiedTime, it does write an "extended timestamp" (0x5455) field with a UT time, not a local time. That extended timestamp field uses the Unix format for such a time (seconds since Jan 1, 1970 UTC).
Now it is up to whatever is viewing or extracting the zip file to look at and use that extra field. Or not. I cannot speak for what your file manager or WinRAR are doing in that case. There are other extra fields defined for storing times in zip files, including an "NTFS" extra field (0x000a), that has the Windows modification, access, and creation times. Different zip file software may be looking for some, all, or none of these and other extra fields in the zip file headers.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论