C#怎么压缩并解压ZIP文件_C#如何管理压缩包【实战】

C#怎么压缩并解压ZIP文件_C#如何管理压缩包【实战】

说到在C#里处理ZIP文件，一个核心原则是：System.IO.Compression 是最稳妥的 ZIP 压缩方案。这意味着，你需要显式设置压缩级别为 CompressionLevel.Optimal，使用正确的 ZipArchiveMode.Create 模式，并妥善管理流生命周期。解压时，路径安全校验是重中之重，而压缩过程中，中文编码、时间戳和符号链接这些细节，往往才是决定成败的关键。

用 System.IO.Compression 压缩 ZIP 文件最稳妥

在 .NET Framework 4.5 及以上，或者 .NET Core 2.0 及以上的版本中，内置的 System.IO.Compression 命名空间无疑是首选。它无需引入任何第三方依赖，不调用外部工具，从根本上避免了因权限不足或路径含空格等环境问题导致的意外错误。

不过，这里有几个关键点必须把握住。首先，务必显式指定 CompressionLevel.Optimal。很多人不知道，其默认值是 Fastest，这会导致压缩率极低，文件体积远大于预期。其次，创建归档时，文件路径要用 ZipArchiveMode.Create 模式打开，并且要确保所有数据写入完成、归档被正确关闭后，才能释放底层文件流。如果直接写入流后就关闭，ZIP文件结构很可能损坏，导致无论是WinRAR还是系统自带的解压工具都无法打开。

一个典型的错误现象就是抛出 InvalidDataException: End of Central Directory record could not be found。遇到这个异常，十有八九是没正确调用 archive.Dispose()，或者在所有 ZipArchiveEntry 条目写完之前就提前关闭了流。

• 源文件路径含中文？ 这本身没问题，但要确保创建 FileStream 时使用 FileMode.Create 和 FileAccess.Write，避免使用 FileShare.Read 模式。
• 要压缩整个文件夹？ 你需要自己递归遍历目录。虽然 ZipFile.CreateFromDirectory 方法很方便，但它不支持自定义条目名称，例如去掉冗长的父路径前缀。
• 处理大文件（>1GB）？ 切忌一次性将整个文件读入内存。正确的做法是使用 entry.Open().CopyTo(stream) 进行流式处理，分块读写。

解压 ZIP 时如何避免路径穿越漏洞

直接使用 ZipArchive.ExtractToDirectory 方法存在一个严重的安全隐患：它默认不会对压缩包内的路径进行校验。想象一下，如果一个恶意的ZIP包里包含一个名为 ../../../etc/passwd 的条目，解压时它就可能跳出目标目录，覆盖或读取系统关键文件。因此，在生产环境中，必须手动校验每一个 ZipArchiveEntry.FullName。

核心的校验逻辑可以这样构建：在 .NET Core 2.1+ 中，可以使用 Path.GetRelativePath 方法，或者用正则表达式如 ^\.\./ 来检查路径是否包含上级目录跳转符。同时，还要确认 entry.FullName 不以 / 或 \ 开头，并且不包含任何控制字符。

• 还在用旧版 .NET Framework？ 可以用 entry.FullName.StartsWith("..") || entry.FullName.Contains("../") 进行初步筛选，然后再用 Path.IsPathRooted 排除掉绝对路径。
• 解压到临时目录？ 更安全的做法是，先通过 Path.GetTempPath() 创建一个唯一的子目录，然后将所有通过校验的条目，使用 ExtractToFile 方法解压到这个子目录下。
• 遇到代表空目录的条目（entry.FullName.EndsWith("/")）？ 可以选择跳过，或者单独调用 Directory.CreateDirectory 来创建它。

ZipFile.CreateFromDirectory 的隐藏坑：时间戳和符号链接

ZipFile.CreateFromDirectory 这个方法用起来确实顺手，但它有两个不容忽视的“硬伤”。第一，所有被打包的文件，其在ZIP内部的时间戳会被统一设置为打包操作发生的时刻，原始的 LastWriteTime 信息会彻底丢失。第二，它会完全忽略符号链接（Symbolic Link），在Linux或macOS系统下，symlink 会被静默跳过，且不会抛出任何错误。

所以，如果你的应用场景需要保留文件的原始修改时间，或者需要处理跨平台项目（例如在CI构建过程中打包包含符号链接的Node.js依赖目录），就必须绕开 ZipFile 这个快捷方式。转而使用 ZipArchive 手动添加每一个条目，并精确设置 entry.LastWriteTime 属性。

• 设置时间戳： 获取源文件的 File.GetLastWriteTimeUtc(path)，然后将其赋值给对应条目的 entry.LastWriteTime。
• 符号链接处理： 在Linux系统上，可以通过 File.GetAttributes(path) 判断是否包含 FileAttributes.ReparsePoint 属性来识别符号链接。需要注意的是，ZIP标准本身并不支持存储符号链接，通常的变通方案是读取链接指向的目标路径，并将其作为普通文本文件存入ZIP。
• 压缩级别无效？ 是的，ZipFile.CreateFromDirectory 方法没有暴露 CompressionLevel 参数。如果你需要精细控制压缩率，只能使用底层的 ZipArchive 类。

遇到 NotSupportedException: No data is a vailable for encoding 936 怎么办

这是一个非常经典的报错，通常出现在非中文系统（如英文版Windows Server、默认的Docker容器）上解压包含中文路径的ZIP文件时。其根源在于，早期的ZIP文件规范并未强制要求使用UTF-8编码存储文件名，而.NET在解析时，默认会尝试使用系统的OEM编码（对于简体中文系统就是GBK，代码页936）。当系统没有安装对应的编码包时，就会抛出此异常。

解决方案需要从压缩和解压两个层面入手。对于压缩端（需要.NET 6+），可以在创建 ZipArchive 时，通过构造函数传入 new ZipArchiveOptions { Encoding = Encoding.UTF8 } 来主动声明使用UTF-8编码。对于解压端，则需要强制使用UTF-8来解析文件名，以兼容旧版ZIP包。

• .NET 5 及以下版本？ 很遗憾，这些版本的API没有提供设置编码的参数。一个“黑科技”是，在解压时通过反射获取 ZipArchiveEntry 内部 _name 字段的原始字节数组，然后手动调用 Encoding.UTF8.GetString(bytes) 进行解码。
• 使用Docker部署？ 务必在 Dockerfile 中添加一行 ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false。如果将其设为true，整个全球化子系统会被禁用，连UTF-8编码器都可能变得不可用。
• 别信“改系统区域设置”这种方案，它在容器化环境中往往不生效，而且可能会影响容器内其他应用的正常运行。

总而言之，路径安全校验、编码处理和时间戳控制，这三块内容最容易在线上环境，尤其是ZIP文件来源不可控或部署环境异构的情况下突然“爆雷”。一个值得牢记的经验是：宁可多写几行防御性的校验逻辑，也尽量不要完全依赖框架的默认行为。