从ZIP提取的文件在重新保存之前无法识别

Question

问：为什么重新保存文件与直接从zip文件提取文件会有所不同？尤其是在Windows上？

上下文

我有一个角度应用程序，它准备一个文本文件以导入到商用计算机中。为了方便用户，我们在zip文件中提供了该文件，以便可以向用户提供所需的文件夹结构。他们将此文件写入USB驱动器，并使用该文件导入计算机。

问题

如果将下载的zip文件直接提取到USB上（以获取文件和所需的文件夹结构），则机器无法识别嵌入的文本文件。

问题排查

如果我在任何文本编辑器中打开文件，添加一个空格，删除该空格，然后将文件重新保存在USB上，则机器将识别该文件。或者，如果我将zip解压缩到本地文件系统上，然后将文件夹结构从本地文件系统复制到USB，则机器也将识别它。

如果我切换到Linux，则从nano进行“写出”将修复该文件。如果我在文件上使用touch命令，问题仍然存在。

怀疑是空格/行尾问题，我尝试了几种差异工具，这些工具没有明显的区别：

• $ diff original.txt resaved.txt（Linux）
• $ vbindiff original.txt resaved.txt（Linux）
• > fc /b original.txt resaved.txt（Windows 7）

其他信息：

• 角度版本：5.2.10
• Zip Utility中的角度：JSZip 3.1.5
• 解压缩实用程序：7压缩和本机Windows资源管理器摘录

JSZip代码：

const zip = new JSZip();
zip.folder('FolderA/FolderB/FolderC').file('FILE.TXT', new File([contentString], 'TEMP.TXT', { type: 'text/plain' }));
zip.generateAsync({ type: 'blob' })
  .then(function (content) {
    saveAs(content, 'ZipFile.ZIP');
  });

在这一点上，我没有主意。希望有人可以对这种奇怪的行为有所了解。

Answer 1

TL; DR：检查文件属性（例如，存档，只读，隐藏，系统等）。

我们的系统专门寻找“存档”位，并以任何方式设置该位来修改文件。

---

这很丑陋，但是与我们的嵌入式系统程序员聊了一下才找到答案。

我们的机器在搜索要导入的文件时专门在搜索存档位（Windows文件属性）。这一点是Windows NTFS的遗物，已经过时了。出于所有目的和目的，它是一个脏标志，用于指出应在下一次备份运行中存档/备份的文件。有很多更好的方法可以做到这一点，所以它已经过时了。

但是，由于某种原因，我们的系统仅搜索设置了该位的文件。这就是为什么打开/复制/移动文件会解决此问题的原因，因为以任何方式对其进行更改都会设置此存档位（脏标志）。

如果您想了解更多信息，请参见here和here。

因此，如果您遇到类似的问题，那么故事的寓意就是检查这些文件属性。

我们正在使用Microchip的Harmony USB驱动程序，因此这可能是该工具的细微之处（或者可能只是在线示例之一的工件）。

您可以使用Windows资源管理器中的文件属性或Windows命令提示符中的> attrib <file>命令来看到它。

---

要解决：

Windows ：您可以使用> attrib +a <file>在命令提示符下设置值，也可以使用> attrib -a <file>删除它。

如果在Windows主机上使用node.js，则可以使用the winattr library from NPM来操纵这些属性。

Linux：：您可以使用$ getfattr和$ setfattr来设置该位（请参见here和here）。

• 注意：我链接的答案说要使用$ setfattr -h -v 0x00000020 -n system.ntfs_attrib_be <target-file>，但是当我尝试执行相同操作时却得到了不支持的操作。我最终使用了Java解决方案，但是后来检查文件时，似乎等效的命令应该是$ setfattr -n user.DOSATTRIB -v 0sMHgyMAA= <target-file>。您的里程可能会有所不同，但如果有帮助，我会提供。

Java ：您也可以在任何系统上use Java。