Linux解压zip中文乱码本质是文件名编码误读：Windows用GBK写、Linux用UTF-8读。unzip -O CP936仅在支持该选项的版本（如Debian/Ubuntu新版）可用；Manjaro、CentOS等多不支持，强行使用会报错。无-O时推荐7z+convmv组合：先7z x解压，再convmv -f GBK -t utf8 -r重命名文件名，安全通用。
Linux解压zip中文乱码，本质不是“解压失败”，而是文件名编码被误读——zip格式不存编码声明，Windows用GBK写，Linux用UTF-8读，自然对不上。
unzip -O CP936 能不能直接用？
能，但得看你的 unzip 版本是否支持 -O 选项。主流发行版中：
- Debian/Ubuntu 系统自带的
unzip（如 6.0+）通常支持-O CP936或-O GBK - Arch Linux 默认
unzip不带-O，需换装unzip-natspec（AUR） - Manjaro、CentOS 7/8 的
unzip多数不支持-O，强行加会报错unzip: invalid option -- 'O'
验证方式：运行 unzip --help | grep -o -E "-O[[:space:]]*"，有输出才表示可用。别盲目抄网上教程。
没有 -O 怎么办？用 7z + convmv 组合
这是最稳定、跨发行版通用的方案，尤其适合脚本化或批量处理：
- 先用
7z解压出原始字节名（它默认按 locale 解析，LANG=C 7z x archive.zip可强制原始二进制输出） - 再用
convmv批量重命名：convmv -f GBK -t utf8 --notest -r ./
注意：convmv 不改文件内容，只改文件名；--notest 是执行开关，首次建议先去掉测试输出；-r 表示递归处理子目录。如果不确定原编码，可先试 convmv -f GBK -t utf8 -r --list ./ 预览效果。
为什么不用 jar xvf？
jar xvf 确实能绕过 unzip 编码逻辑，但它有硬伤：
- 只解压，不创建目录结构（
jar默认不还原空目录） - 不保留原始权限（如可执行位）
- 遇到含非ASCII路径的 zip（比如含 emoji 或日文），
jar在部分 JVM 下仍会截断或报错
它适合临时救急单个简单包，不适合生产环境或自动化流程。
桌面环境点开还是乱码？file-roller 没走 unzip
Gnome 的 file-roller 默认优先调用 7z，即使你装了 unzip-natspec 也无效。验证方法：file-roller --version 看是否启用 7z 后端；若启用了，就只能：
- 卸载
p7zip（风险：影响其他依赖它的工具） - 或改用
ark（KDE）、engrampa（MATE）等明确支持UNZIP="-O GBK"环境变量的归档管理器 - 或在
/etc/environment中全局设UNZIP="-O GBK"，再重启file-roller进程（但新版 file-roller 已忽略该变量）
真正可靠的做法，是放弃图形界面解压，统一走命令行 + 7z + convmv 流程——毕竟，图形工具的“自动”背后，往往藏着不可控的编码猜测逻辑。
