Linux批量解压zip全攻略：循环、乱码、密码与分卷的处理

Linux 下批量解压 zip 文件，我把能踩的坑都踩了一遍

想在 Linux 下批量解压一堆 zip，你第一反应是不是直接敲unzip *.zip？我当年就是这么干的，结果终端吐出一堆报错，半天没搞明白。后来因为经常要一次处理几百个压缩资源包、做数据迁移和日志归档，我把 Linux 批量解压 zip 这条路彻底走了一遍，从最简单的 for 循环到中文乱码、密码包、分卷包，再到解压之后的权限归属，踩过的坑比想象中多得多。

这篇文章就按我实际处理问题的顺序来写，内容包括：为什么unzip *.zip会失败、真正能用的批量解压脚本怎么写、如何应对中文文件名乱码、带密码的 zip 怎么批量解、z01/z02 分卷包怎么处理，以及解压完之后的清理和权限调整。运维、开发，还有天天跟压缩包打交道的普通用户，都能直接照着抄。

1. 别急着敲命令：先弄明白 unzip 到底怎么处理参数

1.1 为什么 unzip *.zip 总是解到一半就报错

先解释一个非常反直觉的事：unzip *.zip在绝大多数情况下是跑不通的。很多人以为它会把目录下所有 zip 一次性解压，但真实情况是，shell 会先把通配符展开。假设目录里有 a.zip、b.zip、c.zip 三个文件，你敲unzip *.zip，shell 实际执行的是：

unzip a.zip b.zip c.zip

unzip 这个命令会把第一个参数当作要解压的压缩包，后面的参数全部当作“压缩包内的文件名”。所以它的实际行为是：解压 a.zip，然后在 a.zip 内部去找名为 b.zip 和 c.zip 的文件，找不到自然就报错了。只有目录里恰好只有一个 zip 文件时，unzip *.zip才会碰巧成功，因为通配符只展开成一个参数。

这个细节不搞清楚，后面所有脚本都可能是“跑一次报一堆错，你还不知道错在哪”的状态。批量处理的第一步，就是忘掉“unzip 支持通配符”这个错觉。

1.2 真正能用的第一版脚本：for 循环 + unzip

既然 unzip 一次只处理一个包，那就老老实实让 shell 帮我们循环。最简单的批量解压脚本长这样：

#!/usr/bin/env bash # 将当前目录下所有 zip 解压到同名目录中 for zip in *.zip; do dir="${zip%.zip}" mkdir -p "$dir" unzip -o "$zip" -d "$dir" done

这里有几个关键点：

• ${zip%.zip}是 Bash 的参数展开语法，作用是去掉变量 zip 结尾的.zip四个字符，得到不带后缀的目录名。比如report-2025.zip会变成report-2025。
• -d "$dir"指定解压目标目录。我强烈建议每个压缩包解压到独立目录里，而不是直接解到当前目录。原因很简单：很多压缩包内部文件结构凌乱，几十个包直接解出来，当前目录瞬间被几百个文件淹没，后续根本没法管理。
• -o表示覆盖已存在文件时不提示。批量场景下如果每次都要确认，脚本会卡在半路等输入，所以-o几乎是必带参数。

如果是只解压部分类型或指定范围的 zip，也可以换成这样：

for zip in report-*.zip backup-*.zip; do unzip -o "$zip" -d "${zip%.zip}" done

1.3 给批量解压加上结果日志，坏了也知道是谁

单纯把包解完还不算完，几百个包里只要有一个损坏或密码不对，脚本的报错信息会淹没在滚动输出里。我习惯把结果记录到日志文件，方便事后排查：

#!/usr/bin/env bash for zip in *.zip; do if unzip -o "$zip" -d "${zip%.zip}" >> unzip.log 2>&1; then echo "[OK] $zip" >> unzip_result.log else echo "[FAIL] $zip" >> unzip_result.log fi done echo "处理完毕，失败项如下：" grep "FAIL" unzip_result.log || true

>> unzip.log 2>&1把 unzip 的正常输出和错误输出都追加到日志文件，控制台只保留最终结论。这样即使不在终端前守着，事后看一眼grep "FAIL" unzip_result.log就能定位问题包。这个习惯帮我省了无数次盯着屏幕翻日志的时间。

2. 目录很深、名字里有空格？用 find 配合 while 才是稳妥方案

2.1 为什么 ls 配合循环在文件名带空格时容易翻车

for 循环处理当前目录没问题，但要处理子目录里的 zip，或者文件名本身就带空格时，事情就变得微妙了。直接写：

for zip in $(find . -name "*.zip"); do unzip -o "$zip" -d "${zip%.zip}" done

这段代码在文件名含空格时会当场翻车。$(find ...)会把每个换行或空格当作分隔符，我的 文档.zip会被拆成两个参数：我的和文档.zip。前者不是有效文件，后者虽然能解，但目录名也会被拆乱。

这种问题在工作机或服务器上太常见了，尤其从 Windows 拷贝过来的文件，名字里十个里面有八个带空格。所以批量脚本必须有更严谨的写法。

2.2 find -print0 与 read -d '' 的组合写法

正确处理含空格文件名的方式，是使用空字符作为分隔符。文件系统的文件名允许包含空格，但几乎不可能包含空字符\0，所以用空字符分隔是最安全的方案。

#!/usr/bin/env bash find /data/archives -type f -name "*.zip" -print0 | while IFS= read -r -d '' zip; do dir="/data/extracted/$(basename "$zip" .zip)" mkdir -p "$dir" unzip -o "$zip" -d "$dir" || echo "解压失败: $zip" done

逐段解释：

• -print0让 find 输出的每个文件名之间用空字符分隔，而不是换行。
• while IFS= read -r -d '' zip是配套读取方式。IFS=去掉默认的空格、Tab 分隔规则，-r防止反斜杠被转义，-d ''告诉 read 使用空字符作为行结束符。
• $(basename "$zip" .zip)取出文件名部分并去掉.zip后缀，用它作为解压目录名，避免把a/b.zip和a b.zip混在一起。

这个组合是处理任意文件名的最稳方案，不管是空格、中文还是特殊字符都不会出问题。我后来所有批量处理脚本都默认用这个模板，几乎没再出过文件名相关的幺蛾子。

2.3 顺手把解压目录规划好，而不是把文件全倒进当前目录

上一节脚本中我把所有解压结果统一放到/data/extracted/下，这是有意的规划。批量解压时，最忌讳的是不加区分地把所有文件解到同一层目录。我见过有人解压 200 个 zip 到当前目录，结果里面有两百个readme.txt、几十个data.csv，后面的查找和去重痛苦到怀疑人生。

推荐两种目录规划方式：

1. 按压缩包名建目录，就是前面脚本用的方案，每个 zip 对应一个独立目录，互不干扰。
2. 如果 zip 内部本身已经有一个顶层目录，那直接解到统一目录也行，先解一个包看一眼内部结构，再决定要不要加-d建目录。

unzip -l 包名.zip可以在解压前查看压缩包内部结构，这个命令我几乎每次批量操作前都会跑一遍，避免解出来一堆文件乱飞。

2.4 遇到“zip 套 zip”的嵌套包怎么递归处理

还有一种气人的情况：解压完一个 zip，发现里面还有一层 zip，有时甚至套了三层。如果只有几个包还能手动处理，几十个嵌套包就麻烦了。

嵌套结构不固定时，我喜欢用一层循环反复扫，直到没有 zip 为止：

#!/usr/bin/env bash # 解压当前目录下所有 zip，并递归处理解压出的新 zip while find . -name "*.zip" | grep -q .; do find . -name "*.zip" -print0 | while IFS= read -r -d '' zip; do dir="${zip%.zip}_解压" mkdir -p "$dir" unzip -o "$zip" -d "$dir" rm -f "$zip" # 解完就删，避免下一轮又扫到它 done done

思路是：外层 while 不断检查目录里还有没有 zip 文件，有就继续循环；内层把发现的 zip 全部解压并删除原件，这样下一轮只会发现新解出来的嵌套 zip。循环终止时，所有层级的 zip 都已经被解开。

注意：解完就删源文件这个操作有一定风险，如果中途磁盘满或包损坏，源码就没了。所以我通常会先把原始 zip 移动到 backup 目录，删除时改删备份，而不是直接rm -f "$zip"。生产环境务必有备份意识。

3. 解出来全是乱码？这是编码问题，不是 zip 坏了

3.1 先说清楚乱码是怎么来的

Linux 下解压 zip 出现中文文件名乱码，几乎可以肯定是编码不一致导致的。zip 这种格式对文件名的编码一直很随意：Windows 简体中文环境创建的压缩包，文件名默认按 GBK/GB18030 编码；而现代 Linux 默认使用 UTF-8 编码。解压工具如果按 UTF-8 去解读 GBK 字节，结果自然是一堆“锟斤拷”“烫烫烫”式的乱码。

注意，乱码只影响文件名，不影响文件内容。内容没有问题，只是你看不到正常的名字。所以别急着重新下载或重新打包，这个问题有解。

3.2 能直接指定编码就指定：unzip -O CP936

如果系统里的 unzip 版本较新，最简单的方式是直接用-O参数指定文件名编码：

unzip -O CP936 -o 中文.zip -d output/

CP936 是 GBK 在 Windows 代码页中的编号，加了-O CP936之后，unzip 会用 GBK 而不是 UTF-8 来解码文件名，解出来的文件名就是正常中文了。

Debian/Ubuntu 的 unzip 一般自带了-O，但如果系统是 CentOS 或较老的发行版，可能需要安装 p7zip 并用7z处理。这个参数的具体支持情况可以敲unzip -h看一下帮助里有没有-O一行。

3.3 unzip 版本太老或没有 -O 参数时的 Python 补救法

如果手里机器没有可用版本，另一个通用解法是用 Python 的 zipfile 写个小脚本，先修复 zip 内的文件名编码，再重新打包：

#!/usr/bin/env python3 # 修复 Windows 简体中文环境打包的 zip 文件名乱码 import zipfile src = "乱码.zip" dst = "fixed.zip" with zipfile.ZipFile(src, "r") as zin, \ zipfile.ZipFile(dst, "w", zipfile.ZIP_DEFLATED) as zout: for item in zin.infolist(): name = item.filename try: fixed = name.encode("cp437").decode("gbk") except (UnicodeEncodeError, UnicodeDecodeError): fixed = name data = zin.read(item.filename) zout.writestr(fixed, data)

原理说明：Python 在读取 zip 文件名时会尝试按 UTF-8 解码，失败则退回 cp437。这个 cp437 是 zip 规范里的历史遗留选项，它把原始字节逐个映射成拉丁字符。要还原真正的文件名，就需要把乱码字符串先 encode 回 raw 字节，再用正确的编码（GBK）解码。这个逻辑可能听起来绕，但实测对大多数 Windows 简体中文包都有效。

如果源头不是 GBK 环境，把decode("gbk")换成big5或其他代码页即可。

3.4 解完之后的文件名乱码，也可以用 convmv 批量纠正

如果已经解压完成，文件散在各处，不想重新打包，那还有一条出路：用convmv直接批量转换文件名编码。

# 安装 convmv，Debian/Ubuntu 示例 apt install convmv # 将当前目录下所有 GBK 编码的文件名转换为 UTF-8 convmv -f GBK -t UTF-8 --notest ./

--notest表示真正执行改名，而不是只预览。./指定处理当前目录。如果目录层级深，可以配合find使用：

find . -depth -exec convmv -f gbk -t utf-8 --notest {} +

注意-depth让 find 先处理子目录再处理父目录，否则改完父目录名后路径就失效了。这个细节很容易踩坑。

4. 密码保护的 zip、分卷 zip，怎么批量处理

4.1 所有包共用一个密码的批处理

遇到一批压缩包都有密码，且密码相同时，批量解压就简单了。unzip 提供了-P参数直接传密码：

for zip in *.zip; do unzip -P '你的密码' -o "$zip" -d "${zip%.zip}" done

用 7z 也可以：

for zip in *.zip; do 7z x -y -p'你的密码' -o"${zip%.zip}" "$zip" done

提示：-P或-p指定密码的方式会让密码出现在进程列表里，在同一台机器上运行ps aux的其他人有可能看到。如果是自己的机器、临时处理，问题不大；如果是共享服务器或安全要求高的环境，建议用交互式输入或改用 7z 的-p配合参数文件的方式，避免密码明文暴露。

4.2 每个包密码都不同：密码表 + while 循环

实际工作中更常见的是每个包密码不一样，比如几百个用户发来的加密压缩包，每个包的密码各不相同。此时我习惯准备一个密码表文件，格式为“文件名 密码”，一行一条：

archive-001.zip password123 archive-002.zip 88abc@@ archive-003.zip qwerty2025

然后配合 while 循环批量处理：

#!/usr/bin/env bash while read -r zip pass; do [ -f "$zip" ] || continue dir="${zip%.zip}" mkdir -p "$dir" 7z x -y -p"$pass" -o"$dir" "$zip" > /dev/null \ && echo "[OK] $zip" \ || echo "[FAIL] $zip" done < passwords.txt

这里用 7z 而不是 unzip，是因为 7z 对密码错误和包损坏的报错信息更清晰，也更容易在脚本里判断成败。< passwords.txt把密码表作为循环的标准输入，文件名和密码被自动拆成$zip和$pass两个变量。这比我手动一个个敲命令快了一个数量级。

4.3 忘了密码和 zip 伪加密：能做什么、不能做什么

这部分要分两种完全不同的情况说清楚。

第一种：包真的加了密，但密码忘了。这种情况没有捷径，只有两条路：要么找到正确的密码，要么放弃。所谓“移除密码”的工具，本质上都是暴力破解或者字典攻击。Kali 里常用的 zip2john 配合 John the Ripper 就是干这个的：

# 把 zip 的密码哈希提取出来（先安装 john） zip2john encrypted.zip > hash.txt # 用字典跑 john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

fcrackzip 也是一个选择：

fcrackzip -u -l 1-6 -c a1 encrypted.zip

-l 1-6表示尝试 1-6 位密码，-c a1指定字符集为小写字母和数字。这类工具只应该用于处理自己创建的压缩包或者已获授权的文件，破解别人加密未授权的数据本身就是高风险操作，我不会在这里教唆，大家也别拿去做不该做的事。

第二种：zip 伪加密。这个问题有意思，所谓伪加密，是指 zip 包的 General Purpose Bit Flag 中加密标志位被设置为 1，但数据实际并没有经过加密。一些制作工具或手工修改包时会出现这种情况。特征是用zipinfo -v显示文件已加密，但用常规加密 zip 的密码尝试时又不对，或者任何密码都能被接受但解出来的文件是乱码。

伪加密的修复思路是把标志位清掉。zip 结构里有两处标志：局部文件头（Local File Header，签名PK\x03\x04）和中央目录头（Central Directory Header，签名PK\x01\x02），两处的 bit0 都要从 1 改回 0。下面是个简化版 Python 脚本：

#!/usr/bin/env python3 # 修复 zip 伪加密：清除加密标志位（只适用于普通场景） import struct path = "fake_encrypted.zip" out_path = "fake_encrypted_fixed.zip" with open(path, "rb") as f: data = bytearray(f.read()) # 修改中央目录头 PK\x01\x02，通用标志位在签名后偏移 8 字节处 off = 0 while True: idx = data.find(b"PK\x01\x02", off) if idx == -1: break flags = struct.unpack("<H", data[idx+8:idx+10])[0] data[idx+8:idx+10] = struct.pack("<H", flags & ~0x0001) name_len = struct.unpack("<H", data[idx+28:idx+30])[0] extra_len = struct.unpack("<H", data[idx+30:idx+32])[0] comment_len = struct.unpack("<H", data[idx+32:idx+34])[0] off = idx + 46 + name_len + extra_len + comment_len # 修改局部文件头 PK\x03\x04，通用标志位在签名后偏移 6 字节处 off = 0 while True: idx = data.find(b"PK\x03\x04", off) if idx == -1: break flags = struct.unpack("<H", data[idx+6:idx+8])[0] data[idx+6:idx+8] = struct.pack("<H", flags & ~0x0001) off = idx + 1 with open(out_path, "wb") as f: f.write(data)

说明一下：这个脚本用find定位签名，理论上存在误匹配到压缩数据中相同字节的可能。处理普通的小文件问题不大，但严谨的做法是先解析 End of Central Directory Record 拿到中央目录偏移，再逐条遍历头。真出现诡异情况别硬改，先备份再说。

4.4 z01/z02 分卷 zip 的合并与解压

分卷 zip 和普通 zip 不一样，它不是“多个 zip 文件打成一个包”，而是把一个 zip 按大小切成多个分卷，文件后缀通常是.z01、.z02、.zip这样的组合。注意，最后一卷才是.zip后缀，前面的都是.z01、.z02这种数字后缀。

最常见的需求是把分卷合并成完整 zip 再解压。Linux 下用 zip 命令可以直接合并：

# 把 split.zip 及其分卷合并为 full.zip zip -s 0 split.zip --out full.zip # 合并后再正常解压 unzip full.zip -d output/

前提是所有分卷文件都在同一目录，且文件名保持原始命名规则（比如data.z01、data.z02、data.zip）。合并命令从.zip那个文件开始读取，自动寻找同名前缀的.z01等分卷。

如果不想合并，也可以直接用 7z 解压分卷，7z 支持读取 z01 系列分卷：

7z x data.zip -ooutput/

只要.z01、.z02都放在同一个目录，7z 会按顺序自动读取。这套方法我处理过一次 30 个分卷的数据库备份包，比逐个解压然后拼接省力太多。

5. 解压之后别急着走：权限、属主和收尾清理

5.1 为什么我解压出来的文件全是 root

批量解压时，如果使用了 sudo 提权，或者当前登录用户就是 root，解压出来的文件属主自然全是 root。这在服务器上很常见，但后续业务进程如果不是以 root 运行，就会出现文件不可读、不可写的诡异问题。

zip 包里的文件权限信息跟 tar 不一样，Windows 打的包通常不含 Unix 权限位，unzip 会按照当前用户的 umask 生成默认权限。所以“解出来全是 root”的本质是：你用什么身份解压，文件就归谁，完全没有“保留原属主”一说。

5.2 用 chown 与 chmod 一把梭调整权限

解压完大批量文件后，我通常会根据实际需要统一调整属主和权限：

# 将整个解压目录的属主改为 www-data 用户和组 chown -R www-data:www-data /data/extracted/ # 目录给 755，普通文件给 644，保证可读可进入 find /data/extracted -type d -exec chmod 755 {} \; find /data/extracted -type f -exec chmod 644 {} \;

如果里面有可执行脚本，再单独给特定文件加执行权限，而不是一刀切给所有文件777。chmod -R 777是新手最爱，也是后患最大的操作，生产环境千万别这么干。

5.3 校验解压结果：unzip -t 批量检测 zip 包完整性

解压前先校验一遍，比解压之后再发现文件缺失要高效得多。unzip -t就是专门用来测试 zip 完整性的：

for f in *.zip; do unzip -t "$f" > /dev/null 2>&1 \ && echo "[OK] $f" \ || echo "[损坏] $f" done

输出里如果有[损坏]项，就单独处理，比如重新下载或联系文件提供方。我习惯把解压和校验分成两个阶段：先全部-t一次，再开始批量解压。坏包不进入解压流程，可以避免解压到一半报错、之后还得清理半成品目录的问题。

源包清理也是收尾的一部分。确认解压结果没问题后，我一般把源 zip 移动到一个_archived目录保留一段时间，而不是直接删除。这样万一发现问题还能回滚，对批量数据处理来说这个习惯很重要。

6. 混合格式、故障速查和顺手脚本

6.1 一次处理 zip、tar.gz、7z、rar 混合压缩包的 case 脚本

实际工作中一个目录里往往不只有 zip，还有 tar.gz、7z、rar 混在一起。逐个区分扩展名写多条命令很啰嗦，我写了一个 case 脚本统一处理：

#!/usr/bin/env bash # 批量解压混合压缩包到同名目录 shopt -s nullglob for f in *; do [ -f "$f" ] || continue case "$f" in *.zip) dir="${f%.zip}" mkdir -p "$dir" unzip -q -o "$f" -d "$dir" && echo "[OK] $f" || echo "[FAIL] $f" ;; *.tar.gz|*.tgz) dir="${f%.tar.gz}" dir="${dir%.tgz}" mkdir -p "$dir" tar -xzf "$f" -C "$dir" && echo "[OK] $f" || echo "[FAIL] $f" ;; *.tar) dir="${f%.tar}" mkdir -p "$dir" tar -xf "$f" -C "$dir" && echo "[OK] $f" || echo "[FAIL] $f" ;; *.7z) dir="${f%.7z}" mkdir -p "$dir" 7z x -y "$f" -o"$dir" > /dev/null && echo "[OK] $f" || echo "[FAIL] $f" ;; *.rar) dir="${f%.rar}" mkdir -p "$dir" unrar x -y "$f" "$dir/" > /dev/null && echo "[OK] $f" || echo "[FAIL] $f" ;; esac done

shopt -s nullglob是个容易被忽略但很关键的设置：当目录里没有匹配文件时，循环不会把*当成字面量去执行，避免一轮空转加莫名其妙报错。这个脚本在服务器上跑过很多次，基本能覆盖日常遇到的混合包场景。

6.2 常见报错速查表

把批量解压时最常见的故障和解决办法整理成一张表，收藏起来省很多事：

6.3 我最后留在终端里的“偷懒”脚本

如果你隔三差五就要批量解压，别每次都重新敲一遍循环。我把最常用的功能封装成一个函数写进~/.bashrc：

unzipall() { local dir for zip in "${@:-*.zip}"; do [ -f "$zip" ] || continue dir="${zip%.zip}" mkdir -p "$dir" unzip -O CP936 -o "$zip" -d "$dir" 2>/dev/null \ || unzip -o "$zip" -d "$dir" echo "已处理: $zip -> $dir/" done }

这个函数默认解压当前目录所有 zip，也支持指定文件，先尝试用 GBK 编码处理中文名，失败则回退到默认编码。原本要敲一整行的活，现在只需要输入unzipall几个字符。我自己用了很久，顺手也推荐给你。

批量解压这件事，本质上没有太高深的技术，但坑就藏在文件名编码、密码、分卷结构这些看似不起眼的小地方。把每一步想清楚，脚本写稳一点，后续管理文件能省下十倍时间。我处理过几百个压缩包的目录，靠的就是上面这套组合：for/find 循环做主体，unzip 负责解压，Python 兜底乱码，7z 处理分卷和密码包，最后 chown/chmod 收尾。按这个流程走，绝大多数批量解压场景都能稳稳拿下。