
原因:压缩包里的文件名编码"错位"了
Linux 和 Windows 对文件名的编码约定不一样:
- Linux 文件系统统一用 UTF-8 保存文件名(1 个汉字 = 3 字节);
- ZIP/TAR 格式本身默认不记录编码 ,Windows 解压时如果没看到 UTF-8 标记,就会按系统 ANSI 码页(中文 Windows 是 GBK,1 个汉字 = 2 字节)去解读文件名。
于是 UTF-8 的字节流被按 GBK 两两配对去"硬解",问题就出在配对错位上:
- 汉字部分是 UTF-8,每字 3 字节。如果汉字总字节数恰好能被 2 整除,后面的
.pptx是纯 ASCII,能侥幸保留 → 这就是你截图里第三个文件(名字是乱码但还认得是 PowerPoint); - 如果多出 1 个"落单"的字节,这个字节会把紧跟的
.(点)一起吞进一个乱码字符里 ,点号消失,剩下pptx连在乱码后面。Windows 认为"扩展名"是整串乱码,自然不认识,类型就显示为普通的"文件" → 截图里前两个文件就是这样。
所以这不是文件坏了,只是文件名(连同扩展名的点)被错误解码了,PPT 内容本身是完好的。
解决办法
把"顶层目录"作为打包对象
先 cd 到顶层目录的上一级,用相对路径打包整个目录树:
bash
cd /data/reports
zip -r -UN=UTF8 archive.zip 2026年度汇报/
这样:
- 完整保留
2026年度汇报/华东区/上海/xxx.pptx这种多层结构; -UN=UTF8对**所有条目(包括各级中文目录名)**都打上 UTF-8 标志位,Windows 解压后目录名、文件名、扩展名全部正常;- 用相对路径打包,压缩包里不会带上
/data/reports这种服务器绝对路径。
如果想把当前目录下所有内容都打包:
bash
zip -r -UN=UTF8 archive.zip .
只想打包 pptx、但保留目录骨架
用 find 找出所有层级的 pptx,喂给 zip -@(路径原样存入,解压时自动重建中间目录):
bash
cd /data/reports
find . -type f -name "*.pptx" | zip -UN=UTF8 archive.zip -@
文件名带空格也没问题(按行读取),只要文件名里没有换行符就行。
两个小提醒
- 如果服务器上的
zip是精简版(如 busybox)不支持-UN,改用 7z,效果相同:
bash
7z a -mcu=on archive.zip 2026年度汇报/
- 打包完可以先自检一下:
unzip -l archive.zip,在 Linux 终端里看到中文目录/文件名正常显示,就说明 UTF-8 存储没问题,Windows 那边双击解压即可。
核心原则就一句:递归靠"传目录"或 find,不要靠 *.pptx 通配符;中文靠 -UN=UTF8(或 -mcu=on)打标志位,两者结合,目录结构和扩展名就都保住了。