笔者在mac往windows传zip文件，以及在zip文件在win系统跨字符集解压上遇到了麻烦，故整理此贴。本文讨论的是俩个系统自带的压缩功能。

笔者对压缩解压的实现不熟，设置一些假设和前提，zip本身不带有编码格式信息，所以压缩的时候无法指定编码，解压的时候可以指定编码格式来解压。猜测第三方软件是读取了里面的内容再去分析编码，而不是压缩包固有的信息。

Windows上的压缩

windows 上集成 explorer 的压缩代码可以追溯到 2000 年出头，是微软外包出去的代码，到 win11 都没有人敢动敢修改这部分。但是 win11 开始提供了 zip 的 store 和 deflate 压缩级别调整的 gui 交互。

如果没有非ascii文字还好，一旦有，在另一个字符集系统下，默认右键解压出来就是乱码，不会处理识别压缩包里内容的编码。

win11 系统上，压缩后的文件通过 bandizip 检查，调整代码页 unicode 字符全部正确显示。任何方式压缩出来的文件（包括PowerShell），在另一个字符集上都能正常显示正常解压。可以通过 bandizip 验证，发现不论调整为何种编码，都能正常显示，这样的话就不轮系统可以随意解压了（可以推翻上面的一条假设吗？zip可以带编码信息）。但是 win7 的话压缩出来的 zip 仅能在当前系统编码正常显示。

右键压缩的压缩包是会抹掉顶层文件夹的日期信息的，但是默认压缩比很可能比一般压缩软件压缩zip差上很多。(store)

Mac上的压缩

• 通过命令行压缩

压缩出来的文件在 windows 内无法正常查看或者解压，会报错无效。

通过 bandizip 检查，可以确定压缩编码是 utf-8，调整为其他全部显示乱码。

• 在 finder 内右键压缩

与通过命令行压缩的表现完全一致，可以推测内部也是调用的命令行程序 zip。

会遇上恼人的 __MACOSX 文件夹，这个文件夹不是在压缩前产生的，而是压缩时给你增加的。另一个文件 .DS_Store 是由用户平时操作产生的。（这俩个文件是什么在这里不做解释了）

用到的命令行指令。

`unzip -l filename.zip` 仅查看压缩包内信息，unicode字符通常会显示乱码。

`zip -r dest.zip folder` 压缩folder到dest.zip