根本原因是ZIP格式不声明编码，Windows打包多用GBK而Linux默认按UTF-8解析，宝塔调用unzip未指定-O参数导致文件名元数据读错；推荐SSH执行unzip -O GBK解压或改用tar格式传输。
宝塔用图形界面解压 ZIP 时中文文件名直接变乱码
根本原因是 ZIP 格式本身不强制声明编码，而 Windows 打包的 ZIP 多用 GBK 编码记录中文文件名，Linux 默认按 UTF-8 解析 —— 宝塔后台调用的 unzip 命令没指定解码方式，就硬生生把 GBK 字节当 UTF-8 解，结果目录名、文件名全变成一堆问号或方块。
这不是文件内容损坏，是文件名元数据被读错了。你点开那些“乱码文件”，里面的内容往往还是正常的（如果源文件内容编码本身没问题）。
- 别信宝塔右上角“解压成功”的提示，它不校验文件名是否可读
- Windows 下用 WinRAR/7-Zip 打包时若勾选了“UTF-8 编码文件名”，Linux 端才能正确识别；但国内多数人没这个习惯
- 宝塔文件管理器的图形化解压功能底层就是调
unzip，不带-O或-I参数，无法指定源编码
用 SSH 手动解压并指定 GBK 编码（最稳方案）
绕过宝塔图形界面，直接在终端里用 unzip 的编码参数解压，能 100% 还原中文文件名。
进 SSH，执行：
cd /www/wwwroot/your-site.com unzip -O GBK your-source.zip
注意：-O GBK 是关键，告诉 unzip 源 ZIP 里的文件名是 GBK 编码；如果原始打包用的是 GB2312，也写 -O GBK（二者兼容），极少部分用 UTF-8 打包的才换 -O UTF-8。
- 执行前先确认 ZIP 包确实含中文文件名：用
unzip -l your-source.zip | head -20看列表，如果已显示乱码，说明打包端就没用 UTF-8 记录文件名 - 解压后若仍有单个文件名异常，大概率是那个文件在打包时用了混合编码，需单独处理
- 解压完立刻
ls确认目录名是否正常，别急着刷新宝塔文件管理器 —— 它有时缓存旧状态
长期规避：改用 tar 替代 ZIP 传输网站源码
.tar（尤其是 .tar.gz）没有文件名编码问题，Linux 原生支持，路径名按字节原样保留。只要打包和解压都在 Linux 环境，中文名零出错。
以后传源码，优先这么做：
- 本地 Linux/macOS：用
tar -zcf site.tar.gz /path/to/site - Windows 用户：用 WSL 或 7-Zip 新建
.tar.gz（不是 .zip），选“UTF-8”编码选项（7-Zip 中叫“Use UTF-8 for file names”） - 上传到宝塔后，在 SSH 里执行
tar -zxvf site.tar.gz，不用任何额外参数
宝塔面板对 .tar 系列格式的识别和解压逻辑更干净，不依赖外部编码猜测。
已经乱码的文件名怎么批量修复
如果已经用图形界面解压出一堆乱码目录（比如 æµè¯），不要重命名，那是徒劳 —— 文件系统里名字本身就是错的字节序列。得用 convmv 工具反向转换。
先装工具：apt install convmv（Debian/Ubuntu）或 yum install convmv（CentOS）
再执行（假设乱码名是 GBK 字节被当 UTF-8 解出来的）：
convmv -f utf-8 -t gbk --notest -r /www/wwwroot/your-site.com
这个命令会把当前目录下所有文件/目录名，按“当前显示为 UTF-8 字符串，实际是 GBK 字节”来还原。
- 务必加
--notest前先跑一遍去掉它，看预览效果；convmv不会误操作，但得你确认映射关系对不对 - 如果原始 ZIP 是 GB2312 打包的，
-f utf-8 -t gb2312更准，但 GBK 覆盖面更广 - 执行后若发现部分文件名仍异常，说明那些文件在打包时用了不同编码，得单独挑出来处理
真正麻烦的从来不是解压动作本身，而是 ZIP 这个格式在跨平台时默认放弃编码声明 —— 你得清楚自己手上的包是谁、在哪、用什么编码打的，不然光靠宝塔点几下，永远在猜。
