为什么很多文件格式都是伪装的zip文件？
Why do many file formats are disguised zip files?
这些年来，我有很多机会对专有文件进行“逆向工程”，而且我注意到很多时候这些都是“伪装”的 ZIP 文件，仅包含标准 XML、HTML 、配置和原始文本文件。但是，我不明白开发人员为什么要这样做。
我想到的这些“伪装”文件格式的几个例子是：
- PPTX、XLS、DOCX 以及可能所有 Microsoft 的文件格式
- EPUB
- JAR，WAR，虽然这个我能理解，因为它是一个存档
还有许多其他此类文件格式，有时甚至真的不想让他们的数据文件被公开阅读的公司也依赖这种伪装的 ZIP 来存储数据（如游戏存档）。
ZIP 文件相对于自定义文件类型的技术优势是什么？
在 ZIP 之上构建（有时是专有的）新文件格式的做法有名称吗？
如果您希望您的新文件格式能够与其他应用程序互操作，您需要完整地定义您的格式。建立在其他标准之上，例如 ZIP、XML 和 HTML 减少了大量的文档和维护工作。
格式设计者通常也是第一个实现者。使用现有标准意味着他们可以使用现有的、已知正确且有效的工具来创建和阅读。这意味着 Microsoft Office 文件格式设计器不需要调试序列化和反序列化逻辑，因为他们已经在使用经过行业验证的 XML.
使用压缩存档而不是 TAR 等普通存档意味着您的格式会尽可能自动减少所需的存储空间。 ZIP 是 ISO 标准且无专利（只要它未使用强大的算法加密），因此设计者和实施者无需支付许可证费用，这与 RAR 不同。
在不同的硬件或平台上实施消费应用程序可能需要重写大部分代码，除非它建立在已经流行的标准之上。例如，EPUB reader 可以与 ZIP reader 库（通常内置于各种框架中）和 HTML 查看器一起修补。开发人员方面的工作量几乎为零，然后他们可以专注于其他功能。由于框架和 CPU 可能针对处理 ZIP 压缩进行了优化，因此它们通常比自定义压缩格式执行得更好。另一个很少考虑的因素是安全性和可靠性。自定义存档格式可能看起来工作得更快或压缩更有效，但在实际数据上它可能会崩溃，或者更糟的是，return 错误读取可能导致安全漏洞或不正确的结果。
对于不希望其文件被读取的公司，可以在 ZIP 之上构建大量解决方案。 AES 加密可作为 AE-x 下 ZIP 的开放标准使用。也许他们不需要隐藏整个结构，只需要隐藏值，他们可以加密 XML/JSON 或文件中的各个条目。 EPUB DRM 很容易被破解，但无论电子书是否使用基于 zip 的格式，这种情况都会发生。
我不认为有一个基于 ZIP 构建新格式的特定名称。当你想存储一个字符串时，你可以选择一种可用的文本编码标准，如果你想保密这个值，你可以用另一种加密标准对其进行加密，而不是发明一种新的编码方案。这些设计师所做的只是简单地采用现有标准，他们不仅使用 ZIP，他们还使用 XML、Unicode、各种图像格式等
关于 Microsoft 格式是 ZIP，嗯，不是所有格式。 2007 年之前的 Office 文件不是，这部分是实施和改进格式困难的部分原因（另一个原因是 Microsoft 通过不记录它们来故意阻止人们首先这样做）。 XLSB 是 ZIP，但它使用二进制序列化而不是 XMLs，这加快了保存和打开的速度，但之后，它的运行速度和内存效率与 XLSX 文件一样。 ACCDB 与前身 MDB 一样，不是 ZIP 文件，数据库通常对压缩过敏。 Visio 转换速度较慢，Visio 2010 使用基于 XML 的 VDX（未压缩），然后在 2013 年，它添加了 VSDX（基于 XML 和 ZIP），而 Project 和 Publisher 似乎没有向新方向发展格式很快。 XPS、Nuget 和 Appx 是 zip，但 csproj、vbproj 等不是。 MSI 安装程序是 存档，但它们不是 ZIP 文件。
有趣的是你停在了 JAR & WAR，因为继续往下看，Android APK 文件是 ZIP 文件（它本身可能包含它引用的 JAR 的内容），所以也是总体 AAB。在 iOS 上，IPA 文件也是 ZIP 文件。 LibreOffice 默认格式 ODT、ODS 和 ODP 都是基于 ZIP 和 XML，与 Microsoft Office 的新格式大约同时设计。
这些年来，我有很多机会对专有文件进行“逆向工程”，而且我注意到很多时候这些都是“伪装”的 ZIP 文件，仅包含标准 XML、HTML 、配置和原始文本文件。但是，我不明白开发人员为什么要这样做。
我想到的这些“伪装”文件格式的几个例子是：
- PPTX、XLS、DOCX 以及可能所有 Microsoft 的文件格式
- EPUB
- JAR，WAR，虽然这个我能理解，因为它是一个存档
还有许多其他此类文件格式，有时甚至真的不想让他们的数据文件被公开阅读的公司也依赖这种伪装的 ZIP 来存储数据（如游戏存档）。
ZIP 文件相对于自定义文件类型的技术优势是什么？
在 ZIP 之上构建（有时是专有的）新文件格式的做法有名称吗？
如果您希望您的新文件格式能够与其他应用程序互操作，您需要完整地定义您的格式。建立在其他标准之上，例如 ZIP、XML 和 HTML 减少了大量的文档和维护工作。
格式设计者通常也是第一个实现者。使用现有标准意味着他们可以使用现有的、已知正确且有效的工具来创建和阅读。这意味着 Microsoft Office 文件格式设计器不需要调试序列化和反序列化逻辑，因为他们已经在使用经过行业验证的 XML.
使用压缩存档而不是 TAR 等普通存档意味着您的格式会尽可能自动减少所需的存储空间。 ZIP 是 ISO 标准且无专利（只要它未使用强大的算法加密），因此设计者和实施者无需支付许可证费用，这与 RAR 不同。
在不同的硬件或平台上实施消费应用程序可能需要重写大部分代码，除非它建立在已经流行的标准之上。例如，EPUB reader 可以与 ZIP reader 库（通常内置于各种框架中）和 HTML 查看器一起修补。开发人员方面的工作量几乎为零，然后他们可以专注于其他功能。由于框架和 CPU 可能针对处理 ZIP 压缩进行了优化，因此它们通常比自定义压缩格式执行得更好。另一个很少考虑的因素是安全性和可靠性。自定义存档格式可能看起来工作得更快或压缩更有效，但在实际数据上它可能会崩溃，或者更糟的是，return 错误读取可能导致安全漏洞或不正确的结果。
对于不希望其文件被读取的公司，可以在 ZIP 之上构建大量解决方案。 AES 加密可作为 AE-x 下 ZIP 的开放标准使用。也许他们不需要隐藏整个结构，只需要隐藏值，他们可以加密 XML/JSON 或文件中的各个条目。 EPUB DRM 很容易被破解，但无论电子书是否使用基于 zip 的格式，这种情况都会发生。
我不认为有一个基于 ZIP 构建新格式的特定名称。当你想存储一个字符串时，你可以选择一种可用的文本编码标准，如果你想保密这个值，你可以用另一种加密标准对其进行加密，而不是发明一种新的编码方案。这些设计师所做的只是简单地采用现有标准，他们不仅使用 ZIP，他们还使用 XML、Unicode、各种图像格式等
关于 Microsoft 格式是 ZIP，嗯，不是所有格式。 2007 年之前的 Office 文件不是，这部分是实施和改进格式困难的部分原因（另一个原因是 Microsoft 通过不记录它们来故意阻止人们首先这样做）。 XLSB 是 ZIP，但它使用二进制序列化而不是 XMLs，这加快了保存和打开的速度，但之后，它的运行速度和内存效率与 XLSX 文件一样。 ACCDB 与前身 MDB 一样，不是 ZIP 文件，数据库通常对压缩过敏。 Visio 转换速度较慢，Visio 2010 使用基于 XML 的 VDX（未压缩），然后在 2013 年，它添加了 VSDX（基于 XML 和 ZIP），而 Project 和 Publisher 似乎没有向新方向发展格式很快。 XPS、Nuget 和 Appx 是 zip，但 csproj、vbproj 等不是。 MSI 安装程序是 存档，但它们不是 ZIP 文件。
有趣的是你停在了 JAR & WAR，因为继续往下看，Android APK 文件是 ZIP 文件（它本身可能包含它引用的 JAR 的内容），所以也是总体 AAB。在 iOS 上，IPA 文件也是 ZIP 文件。 LibreOffice 默认格式 ODT、ODS 和 ODP 都是基于 ZIP 和 XML，与 Microsoft Office 的新格式大约同时设计。