1. 为什么我最后还是给压缩解压单独立了个工具位压缩和解压这件事看起来是最没有技术含量的活儿unzip、tar -zxvf、右键解压谁不会。但我自己统计过一周里光是处理各种包就占了十几分钟而且这十几分钟全是被打断的碎片时间——同事发来一个 zip解出来一堆乱码文件名线上导出的日志是.tar.gz里面还套着一层.gz别人给的素材包是 7z本机没装解压软件打个发布包给对面tar 包里的软链接全变成了实体文件体积翻了三倍。这些问题单拎出来都能解决问题在于每次都要现场回忆该用哪个命令、哪个参数、哪个工具脑子要切换一次上下文。x-cmd-mod里的zuz模块干的就是这件事把压缩和解压统一到一个入口格式自动识别参数尽量收敛省掉先看后缀再选命令的这一步。它的定位不是替代 tar、unzip、7z 这些底层工具而是当一层调度壳——判断这是什么格式、该调哪个后端、输出到哪儿、要不要建目录。对天天在终端里搬文件的人来说这一层壳的价值比想象中大。这篇内容适合三类人看一是经常在命令行里处理压缩包的后端、运维、数据同学二是刚上手 Linux、每次解压都要搜一遍命令的新人三是想给自己攒一套稳定文件搬运流程的人。下面我会把 zuz 的设计思路、实际命令、踩过的坑、以及几种我每天都在用的组合写法拆开讲命令都以我本地长期使用的形式给出具体短选项请以你本机的zuz --help为准因为这类工具的参数会随版本微调。2. zuz 的核心思路把选工具这一步交给程序2.1 压缩格式的碎片化才是真正的麻烦源头先把这个领域的现状说清楚才能理解为什么要多这么一层。压缩格式不是一种格式打天下而是历史包袱堆出来的生态zip 因为 Windows 友好活得最好tar.gz 是 Unix 世界的默认答案tar.xz 压缩率高但慢常见于发布包zstd 这两年因为解压速度极快在大目录快照和容器层里用得越来越多7z 压缩率最高但需要额外装后端rar 则是历史遗留能解不能压。每种格式背后对应一个不同的命令行工具参数风格还各不相同。这就带来了一个很实际的成本你得先知道后缀再回忆工具再回忆参数。.tar.gz要用tar -zxvf.tar.bz2要换成-jxvf.tar.xz要-Jxvf.zip用unzip.7z用7z x.gz单文件用gzip -d.zst用zstd -d。记混一个字母就是一次失败的解压和一次重新查文档。zuz 的第一层价值就在这里它把看后缀选工具变成了程序的分支判断。具体来说它做的判断大致分三步。第一步看扩展名这是最快的路径第二步遇到扩展名缺失、伪造、或者是多层后缀比如backup.tar.gz.001的情况会去读文件头部的魔数magic numberzip 是PK\x03\x04gzip 是1f 8bzstd 是28 b5 2f fdxz 是fd 37 7a 58 5a 00第三步根据判断结果去调对应的后端程序。注意魔数判断不是万能的。有些老式自解压包.exe 外壳包着的 zip头部是 PE 结构靠魔数识别不出来只能靠后缀或者手动指定。遇到这种包别硬试先用file命令看一眼真实类型。2.2 自动建目录这个默认行为救过我好几次在讲格式之前我想单独说说解压到哪儿这件事因为它比格式识别更容易出事故。裸用tar -xvf或者unzip的时候压缩包里的内容会直接铺在当前目录。如果包里没有顶层目录很多打包工具默认就不加你当前目录瞬间被几十个文件淹没找都找不回来更别提误覆盖同名文件。zuz 的默认行为是解压前先建一个和压缩包同名的目录把内容放进去。这个设计看起来很小但它把解压污染工作目录这个高频事故直接掐掉了。我现在的习惯是不管用哪个工具解压前先ls或者-l看一眼包里的结构确认有没有顶层目录没有的话一定手动指定输出目录。zuz 帮我省掉了这一步的犹豫但习惯还是保留着。2.3 和原生工具的关系调度层不是替代品这里要说清楚一个容易误解的点zuz 不是自己实现了 zip 和 tar 的编解码它是调度层。压缩率、速度、兼容性这些底层指标最终还是由后端决定的。所以你用它压出来的 zip和用zip命令压出来的本质上是一回事。它解决的是调用体验问题不是压缩算法问题。理解这一点很重要因为它决定了你什么时候该用它、什么时候不该用。日常解压、打包、批量处理用它最省事但如果你要做一些底层控制比如精确指定 zip 的压缩级别、控制 tar 的块大小、给 zstd 指定长距离匹配窗口那就得回到原生工具或者用 zuz 透传参数的方式调后端。我一般的原则是常规操作走 zuz需要精细调优才下沉到原生命令。下面这张表是我自己整理的格式选择参考日常打包前扫一眼就能定格式压缩率压缩速度解压速度跨平台友好度我一般什么时候用zip中快快极高发给非技术同事、需要 Windows 直接双击打开tar.gz中中中Linux/macOS 原生源码包、日志归档、通用交付tar.zst高很快极快需装 zstd大目录快照、本机备份、CI 缓存tar.xz高慢中需装 xz对外发布的固定版本包7z很高慢中需装 7z冷备份、长期归档、体积敏感场景tar不压缩无极快极快原生只做打包不做压缩比如保留权限和软链接3. 装好之后先跑通这几条命令3.1 安装与依赖检查x-cmd 的模块体系是按需加载zuz 作为其中一个模块通常不需要单独安装跟着主程序走就行。装完之后第一件事不是急着解压而是先确认后端工具齐不齐zuz --help zuz -V--help里会列出它支持的格式和后端依赖。如果某个格式的后端没装解压到那个格式时才会报错这时候补装就行。我自己机器上常备的后端是unzip、tar、gzip、zstd、xz7z 和 rar 按需装——这两个不是每天用装上占空间不装又会在关键时刻卡住我的做法是留着反正是几十兆的事。# 检查后端是否就位缺哪个补哪个 command -v unzip tar gzip zstd xz 7z提示不要在生产机上临时装解压后端。很多精简镜像里连tar都是裁剪版--exclude之类的高级参数可能不支持。上线前在目标环境里跑一次真实包的解压测试比事后排查便宜得多。3.2 解压三种最常见的使用姿势最基础的用法就是直接把文件丢给它zuz archive.tar.gz zuz package.zip zuz backup.7z它会自动判断格式、自动建同名目录、自动选后端。执行完你会看到一个和包同名的目录里面是解出来的内容。第二种是指定输出目录这是我在脚本里最常用的形式因为脚本里不能依赖自动建目录这种隐含行为zuz -o ./output archive.tar.gz第三种是只看不解先确认包里有什么再决定要不要解zuz -l archive.tar.gz-l这个动作我强烈建议养成习惯。原因有两个一是确认包里有没有顶层目录避免解压炸开二是排查解压出来一堆乱码文件名的问题时先看列表能立刻判断是编码问题还是文件本身有问题。还有一个容易被忽略的场景单文件压缩。比如app.log.gz这种它不是一个归档包就是一个文件被 gzip 压了。这种用zuz app.log.gz也能解出来就是app.log不会有目录。如果你的脚本里对输出结构有强假设记得区分归档包和单文件压缩两种情况。3.3 压缩参数怎么选才不返工压缩这块我的经验是先把给谁用想清楚再选格式最后才调参数。很多人反过来先纠结压缩级别结果压出来对面打不开。发给 Windows 用户无脑 zipzuz -c deliver.zip ./dist自己机器上做大目录快照我基本都用 zstd因为解压快得离谱恢复的时候不折磨人zuz -c snapshot.tar.zst ./workspace对外发布固定版本用 xz体积小虽然压得慢但压一次用很久zuz -c release.tar.xz ./build需要保留软链接和权限位的时候一定要用 tar 系格式不要用 zip。这是我最容易踩的坑之一项目里有个node_modules/.bin全是软链接用 zip 打出来解压之后软链接变成了实体文件副本体积直接从几百兆涨到一个多 G而且有些链接指向的文件在打包时根本不存在压出来是坏的。tar 默认保留链接zip 默认跟随链接这个差别必须记住。# 保留软链接、保留权限、保留属主信息 zuz -c -p release.tar.gz ./build具体的短选项名称在不同版本上可能有差异-p是不是保留属性要看 help。我的建议是涉及权限和链接的打包压完之后一定解压一次到临时目录ls -l看一眼链接是不是还是链接、可执行位还在不在。这个验证动作花十秒能省掉后面半小时的排查。4. 四个真实场景的完整写法4.1 批量解压一层目录下的所有压缩包这是最典型的重复劳动。手动一个个解二十个包就是二十次操作。批量处理的关键不是循环本身而是三个细节路径里有空格怎么办、解压失败要不要中断、输出目录怎么组织。#!/usr/bin/env bash set -uo pipefail src_dir./incoming out_root./extracted mkdir -p $out_root find $src_dir -maxdepth 1 -type f \ \( -name *.zip -o -name *.tar.gz -o -name *.tgz -o -name *.7z \) \ -print0 | while IFS read -r -d f; do base$(basename $f) name${base%%.*} target$out_root/$name echo $base - $target if ! zuz -o $target $f; then echo !! failed: $f 2 fi done几个点解释一下。-print0配合read -d 是为了处理文件名里的空格和特殊字符用for f in $(find ...)会在遇到空格时直接裂开这个坑我踩过不止一次。set -uo pipefail里我特意没加-e因为批量任务里单个包失败不应该中断整批失败信息打到 stderr 就行回头单独处理。name${base%%.*}是取第一个点之前的部分作为目录名这样data.tar.gz会解到data而不是data.tar避免目录名一层套一层。注意如果你的压缩包里有嵌套压缩包常见于数据分发场景不要图省事写递归解压。嵌套包的层级和命名没有统一约定递归很容易解出一堆同名目录互相覆盖。我的做法是先解一层看一眼结构再决定第二层怎么处理。4.2 打包时排除垃圾文件把体积压下来打包体积失控八成是因为把不该打的东西打进去了.git目录、node_modules、__pycache__、.DS_Store、各种.log和临时文件。一个几十兆的项目带上这些能到几百兆。zuz -c project.tar.zst ./project \ --exclude.git \ --excludenode_modules \ --exclude__pycache__ \ --exclude*.log \ --exclude.DS_Store排除规则有几个实践上的注意点。第一--exclude匹配的是相对路径的模式串写node_modules和写*/node_modules/*效果不一样前者是精确匹配目录名后者更宽泛建议先在临时目录试一次用-l看结果确认。第二排除顺序有讲究有些实现里后面的规则会覆盖前面的所以先全排除、再单独加回这种写法要谨慎。第三别用排除规则去处理必须存在但内容不需要的文件比如空的占位文件那应该用别的办法。我自己的经验是维护一份项目级的排除清单放在仓库里打包脚本直接读避免每次靠记忆临时敲。清单里固定加上这几类版本控制目录、依赖缓存目录、构建产物目录、系统生成的隐藏文件、日志和临时文件。这五类基本覆盖了 90% 的体积浪费。4.3 加密包和分卷包的处理加密压缩包在企业环境里很常见尤其是要过邮件网关或者走外部传输的时候。处理这类包有两个原则密码不要出现在命令历史里密码不要出现在脚本明文里。# 从环境变量读避免写进 history zuz -p $ARCHIVE_PASS -o ./out secret.7z # 或者从文件读文件权限设成 600 zuz -p $(cat ~/.archive_pass) -o ./out secret.zip命令行参数会被记录到 shell history也会出现在ps的进程列表里同机器上的其他用户能看到。所以密码走参数是下策走环境变量是中策走交互式输入或者受权限保护的文件是上策。具体 zuz 支持哪种读取方式看 help如果没有交互式读取那就用文件加权限保护。分卷包是另一个高频场景尤其是超过几百兆的备份。分卷的坑在于卷的顺序和卷的完整性少一个卷解不开卷被改过名解不开卷的顺序乱了也解不开。我的做法是先把所有卷收齐到同一个目录确认命名连续.001、.002这种然后指定第一个卷开始解工具会自动找后续卷。ls -1 backup.7z.* zuz -o ./restore backup.7z.001解分卷之前先确认磁盘空间这个听起来很废话但我真的见过解到一半空间满了留下一个半成品目录还得手动清理。粗略估算一下分卷包总大小乘以 2.5 到 3差不多是解压后需要的空间压缩率高的格式系数更大。4.4 管道流的玩法不解压就看内容有些场景你根本不需要落盘只是想在压缩包里搜个东西或者看一眼某个文件。比如线上日志归档你只想确认某个时间点有没有报错没必要把几个 G 解出来。# 从 tar.gz 里直接抽一个文件到标准输出 tar -xzOf archive.tar.gz path/to/app.log | grep -i error | head -50 # 列出包内文件按大小排序找出体积大头 zuz -l archive.tar.zst | sort -k1 -n -r | head -20这种流式处理的价值在于省 IO 和省磁盘。对于我们这种磁盘常年紧张的环境能不解压就不解压。tar的-O参数是把内容输出到标准输出而不是落盘配合 grep、awk、sort 能拼出很多有用的临时分析命令。不过要注意-O只适合单个文件或者小文件抽大文件到管道里再 grepCPU 和内存都会不太好看这种还是老老实实解出来再处理。5. 踩过的坑和排查思路5.1 文件名乱码几乎全是编码问题Windows 上打的 zip文件名默认用 GBK 或者 CP936 编码解到 UTF-8 环境里就是一串问号或者方块。这是压缩解压领域最高频的问题没有之一。排查顺序是这样的。第一步zuz -l看列表如果列表里就乱说明是包本身的文件名编码和当前环境不一致如果列表正常但解出来乱那问题在解压环节的转码。第二步判断来源Windows 打的包大概率是 GBK。第三步用带编码参数的方式重解unzip -O cp936 package.zip -d ./out # 或者 7z x -mcp936 package.zip -o./outzuz 这类工具在检测到文件名不是合法 UTF-8 时一般会有提示但自动转码这件事本身有风险——猜错了会得到更乱的结果。所以我的建议是能不自动转就不自动转先看提示再手动指定编码重解一次确认没问题再继续。提示自己往外发包的时候尽量用 tar 系格式tar 对文件名编码的处理比 zip 干净得多。如果对方只能用 zip那就提醒一句文件名是 UTF-8减少来回扯皮。5.2 权限和软链接丢失zip 的原罪前面提过一次这里展开说。zip 格式在设计上就没有完整保存 Unix 权限位和软链接的标准方式虽然有扩展字段但支持度参差不齐。所以用 zip 打包一个带可执行脚本和软链接的目录解出来大概率是坏的。表现有三种可执行文件变成不可执行需要手动chmod x软链接变成实体文件体积暴涨软链接指向的目标不存在时变成一个空文件或者干脆丢失。解决办法只有一个这类场景别用 zip用 tar。tar 从设计上就是为 Unix 文件系统备份而生权限、属主、时间戳、软链接、硬链接、设备文件都支持。# 打包 tar -czf release.tar.gz ./build # 解包注意 -p 保留权限 tar -xzpf release.tar.gz如果交付对象确实只能用 zip那就在包里附一个恢复脚本解压后跑一遍把可执行位补回去把软链接重建出来。这活儿麻烦但比让对方手动修要体面。5.3 路径穿越陌生压缩包先看再解这是一个安全习惯问题。压缩包里的文件路径是可以带../的也就是说一个恶意构造的包解压时可能把文件写到你的主目录、写到系统目录、甚至覆盖配置文件。这类问题在各类工具的 CVE 里反复出现。现代工具大多做了防护解压时会拒绝绝对路径和带..的相对路径。但防护不是百分百不同实现的行为也不一致。所以对来源不明的包我的流程固定是三步先-l列内容看有没有奇怪的路径再解到一个隔离的临时目录不要解到工作目录或者家目录确认内容正常之后再挪到目标位置。mkdir -p /tmp/inspect cd /tmp/inspect zuz -l /path/to/unknown.zip zuz -o ./unpacked /path/to/unknown.zip这个习惯看起来啰嗦但成本极低收益是避免一次灾难。尤其是从聊天工具、邮件附件里收到的包多花十秒看一眼列表很值。5.4 常见问题速查表下面这张表是我这几年攒下来的遇到问题先扫一遍能省不少搜索时间现象大概率原因处理方式解压报格式不支持后端工具没装或者后缀被改过file看真实类型补齐后端或手动指定格式文件名全是乱码源包用 GBK/CP936 编码用-O cp936重解或换 7z 指定代码页解压后目录被几十个文件淹没包里没有顶层目录解到了当前目录解压前用-l确认始终指定-o输出目录可执行权限丢失用了 zip 格式换 tar 打包或解压后批量chmod软链接变成实体文件zip 跟随链接换 tar或打包时明确不跟随链接解压到一半失败磁盘空间不足、包损坏、分卷缺失检查df -h用-t测试完整性确认分卷齐全解压速度极慢用了 xz 或高压缩比 7z换 zstd压缩率略降但解压快一个量级中文路径在 Windows 上打不开打包时用了 UTF-8 但对方按 GBK 解打包时就统一编码或在说明里注明6. 几条用久了才明白的实操心得第一条格式选择优先于参数调优。我见过太多人纠结 zstd 的压缩级别调到几结果交付的时候对面根本装不了 zstd。先把给谁、在什么环境用定下来格式定了参数基本没什么可调的余地。日常场景里压缩级别的收益远没有你想象的大从默认级别往上调体积可能只降几个点时间翻倍。第二条打包一定要可复现。同一个目录今天打的包和明天打的包如果内容没变但哈希变了那说明打包过程带进了时间戳或者顺序不稳定。做发布包的时候这个很重要因为你要能证明这个包就是那次构建的产物。tar 有排序参数也有统一的 mtime 归零技巧这些细节在需要做完整性校验的场景里是刚需。第三条永远验证一次。压完解一次解完看一眼。这个动作我坚持了很多年救过的次数已经数不清了。验证不需要多复杂解到临时目录比对文件数量抽查几个关键文件的内容和权限齐活。十分钟的验证换的是交付之后不用半夜被叫起来。第四条把常用组合写成脚本。批量解压、带排除规则的打包、分卷恢复这三个我都有对应的脚本放在~/bin里参数化之后调用。写脚本的过程本身就是一次梳理你会发现自己在哪些地方一直靠记忆硬撑哪些地方其实有更稳的写法。工具的价值不只是省一次输入更是把正确做法固化成默认行为。第五条别迷信任何单一工具。zuz 好用但遇到奇怪的包、奇怪的编码、奇怪的权限问题该退回tar、unzip、7z、file的时候不要犹豫。工具是手段把文件完整、正确地搬到该去的地方才是目的。我现在的状态是九成场景用 zuz 一把过剩下一成现场判断哪种手段最直接就用哪种不跟工具较劲。
1. 为什么我最后还是给压缩解压单独立了个工具位压缩和解压这件事看起来是最没有技术含量的活儿unzip、tar -zxvf、右键解压谁不会。但我自己统计过一周里光是处理各种包就占了十几分钟而且这十几分钟全是被打断的碎片时间——同事发来一个 zip解出来一堆乱码文件名线上导出的日志是.tar.gz里面还套着一层.gz别人给的素材包是 7z本机没装解压软件打个发布包给对面tar 包里的软链接全变成了实体文件体积翻了三倍。这些问题单拎出来都能解决问题在于每次都要现场回忆该用哪个命令、哪个参数、哪个工具脑子要切换一次上下文。x-cmd-mod里的zuz模块干的就是这件事把压缩和解压统一到一个入口格式自动识别参数尽量收敛省掉先看后缀再选命令的这一步。它的定位不是替代 tar、unzip、7z 这些底层工具而是当一层调度壳——判断这是什么格式、该调哪个后端、输出到哪儿、要不要建目录。对天天在终端里搬文件的人来说这一层壳的价值比想象中大。这篇内容适合三类人看一是经常在命令行里处理压缩包的后端、运维、数据同学二是刚上手 Linux、每次解压都要搜一遍命令的新人三是想给自己攒一套稳定文件搬运流程的人。下面我会把 zuz 的设计思路、实际命令、踩过的坑、以及几种我每天都在用的组合写法拆开讲命令都以我本地长期使用的形式给出具体短选项请以你本机的zuz --help为准因为这类工具的参数会随版本微调。2. zuz 的核心思路把选工具这一步交给程序2.1 压缩格式的碎片化才是真正的麻烦源头先把这个领域的现状说清楚才能理解为什么要多这么一层。压缩格式不是一种格式打天下而是历史包袱堆出来的生态zip 因为 Windows 友好活得最好tar.gz 是 Unix 世界的默认答案tar.xz 压缩率高但慢常见于发布包zstd 这两年因为解压速度极快在大目录快照和容器层里用得越来越多7z 压缩率最高但需要额外装后端rar 则是历史遗留能解不能压。每种格式背后对应一个不同的命令行工具参数风格还各不相同。这就带来了一个很实际的成本你得先知道后缀再回忆工具再回忆参数。.tar.gz要用tar -zxvf.tar.bz2要换成-jxvf.tar.xz要-Jxvf.zip用unzip.7z用7z x.gz单文件用gzip -d.zst用zstd -d。记混一个字母就是一次失败的解压和一次重新查文档。zuz 的第一层价值就在这里它把看后缀选工具变成了程序的分支判断。具体来说它做的判断大致分三步。第一步看扩展名这是最快的路径第二步遇到扩展名缺失、伪造、或者是多层后缀比如backup.tar.gz.001的情况会去读文件头部的魔数magic numberzip 是PK\x03\x04gzip 是1f 8bzstd 是28 b5 2f fdxz 是fd 37 7a 58 5a 00第三步根据判断结果去调对应的后端程序。注意魔数判断不是万能的。有些老式自解压包.exe 外壳包着的 zip头部是 PE 结构靠魔数识别不出来只能靠后缀或者手动指定。遇到这种包别硬试先用file命令看一眼真实类型。2.2 自动建目录这个默认行为救过我好几次在讲格式之前我想单独说说解压到哪儿这件事因为它比格式识别更容易出事故。裸用tar -xvf或者unzip的时候压缩包里的内容会直接铺在当前目录。如果包里没有顶层目录很多打包工具默认就不加你当前目录瞬间被几十个文件淹没找都找不回来更别提误覆盖同名文件。zuz 的默认行为是解压前先建一个和压缩包同名的目录把内容放进去。这个设计看起来很小但它把解压污染工作目录这个高频事故直接掐掉了。我现在的习惯是不管用哪个工具解压前先ls或者-l看一眼包里的结构确认有没有顶层目录没有的话一定手动指定输出目录。zuz 帮我省掉了这一步的犹豫但习惯还是保留着。2.3 和原生工具的关系调度层不是替代品这里要说清楚一个容易误解的点zuz 不是自己实现了 zip 和 tar 的编解码它是调度层。压缩率、速度、兼容性这些底层指标最终还是由后端决定的。所以你用它压出来的 zip和用zip命令压出来的本质上是一回事。它解决的是调用体验问题不是压缩算法问题。理解这一点很重要因为它决定了你什么时候该用它、什么时候不该用。日常解压、打包、批量处理用它最省事但如果你要做一些底层控制比如精确指定 zip 的压缩级别、控制 tar 的块大小、给 zstd 指定长距离匹配窗口那就得回到原生工具或者用 zuz 透传参数的方式调后端。我一般的原则是常规操作走 zuz需要精细调优才下沉到原生命令。下面这张表是我自己整理的格式选择参考日常打包前扫一眼就能定格式压缩率压缩速度解压速度跨平台友好度我一般什么时候用zip中快快极高发给非技术同事、需要 Windows 直接双击打开tar.gz中中中Linux/macOS 原生源码包、日志归档、通用交付tar.zst高很快极快需装 zstd大目录快照、本机备份、CI 缓存tar.xz高慢中需装 xz对外发布的固定版本包7z很高慢中需装 7z冷备份、长期归档、体积敏感场景tar不压缩无极快极快原生只做打包不做压缩比如保留权限和软链接3. 装好之后先跑通这几条命令3.1 安装与依赖检查x-cmd 的模块体系是按需加载zuz 作为其中一个模块通常不需要单独安装跟着主程序走就行。装完之后第一件事不是急着解压而是先确认后端工具齐不齐zuz --help zuz -V--help里会列出它支持的格式和后端依赖。如果某个格式的后端没装解压到那个格式时才会报错这时候补装就行。我自己机器上常备的后端是unzip、tar、gzip、zstd、xz7z 和 rar 按需装——这两个不是每天用装上占空间不装又会在关键时刻卡住我的做法是留着反正是几十兆的事。# 检查后端是否就位缺哪个补哪个 command -v unzip tar gzip zstd xz 7z提示不要在生产机上临时装解压后端。很多精简镜像里连tar都是裁剪版--exclude之类的高级参数可能不支持。上线前在目标环境里跑一次真实包的解压测试比事后排查便宜得多。3.2 解压三种最常见的使用姿势最基础的用法就是直接把文件丢给它zuz archive.tar.gz zuz package.zip zuz backup.7z它会自动判断格式、自动建同名目录、自动选后端。执行完你会看到一个和包同名的目录里面是解出来的内容。第二种是指定输出目录这是我在脚本里最常用的形式因为脚本里不能依赖自动建目录这种隐含行为zuz -o ./output archive.tar.gz第三种是只看不解先确认包里有什么再决定要不要解zuz -l archive.tar.gz-l这个动作我强烈建议养成习惯。原因有两个一是确认包里有没有顶层目录避免解压炸开二是排查解压出来一堆乱码文件名的问题时先看列表能立刻判断是编码问题还是文件本身有问题。还有一个容易被忽略的场景单文件压缩。比如app.log.gz这种它不是一个归档包就是一个文件被 gzip 压了。这种用zuz app.log.gz也能解出来就是app.log不会有目录。如果你的脚本里对输出结构有强假设记得区分归档包和单文件压缩两种情况。3.3 压缩参数怎么选才不返工压缩这块我的经验是先把给谁用想清楚再选格式最后才调参数。很多人反过来先纠结压缩级别结果压出来对面打不开。发给 Windows 用户无脑 zipzuz -c deliver.zip ./dist自己机器上做大目录快照我基本都用 zstd因为解压快得离谱恢复的时候不折磨人zuz -c snapshot.tar.zst ./workspace对外发布固定版本用 xz体积小虽然压得慢但压一次用很久zuz -c release.tar.xz ./build需要保留软链接和权限位的时候一定要用 tar 系格式不要用 zip。这是我最容易踩的坑之一项目里有个node_modules/.bin全是软链接用 zip 打出来解压之后软链接变成了实体文件副本体积直接从几百兆涨到一个多 G而且有些链接指向的文件在打包时根本不存在压出来是坏的。tar 默认保留链接zip 默认跟随链接这个差别必须记住。# 保留软链接、保留权限、保留属主信息 zuz -c -p release.tar.gz ./build具体的短选项名称在不同版本上可能有差异-p是不是保留属性要看 help。我的建议是涉及权限和链接的打包压完之后一定解压一次到临时目录ls -l看一眼链接是不是还是链接、可执行位还在不在。这个验证动作花十秒能省掉后面半小时的排查。4. 四个真实场景的完整写法4.1 批量解压一层目录下的所有压缩包这是最典型的重复劳动。手动一个个解二十个包就是二十次操作。批量处理的关键不是循环本身而是三个细节路径里有空格怎么办、解压失败要不要中断、输出目录怎么组织。#!/usr/bin/env bash set -uo pipefail src_dir./incoming out_root./extracted mkdir -p $out_root find $src_dir -maxdepth 1 -type f \ \( -name *.zip -o -name *.tar.gz -o -name *.tgz -o -name *.7z \) \ -print0 | while IFS read -r -d f; do base$(basename $f) name${base%%.*} target$out_root/$name echo $base - $target if ! zuz -o $target $f; then echo !! failed: $f 2 fi done几个点解释一下。-print0配合read -d 是为了处理文件名里的空格和特殊字符用for f in $(find ...)会在遇到空格时直接裂开这个坑我踩过不止一次。set -uo pipefail里我特意没加-e因为批量任务里单个包失败不应该中断整批失败信息打到 stderr 就行回头单独处理。name${base%%.*}是取第一个点之前的部分作为目录名这样data.tar.gz会解到data而不是data.tar避免目录名一层套一层。注意如果你的压缩包里有嵌套压缩包常见于数据分发场景不要图省事写递归解压。嵌套包的层级和命名没有统一约定递归很容易解出一堆同名目录互相覆盖。我的做法是先解一层看一眼结构再决定第二层怎么处理。4.2 打包时排除垃圾文件把体积压下来打包体积失控八成是因为把不该打的东西打进去了.git目录、node_modules、__pycache__、.DS_Store、各种.log和临时文件。一个几十兆的项目带上这些能到几百兆。zuz -c project.tar.zst ./project \ --exclude.git \ --excludenode_modules \ --exclude__pycache__ \ --exclude*.log \ --exclude.DS_Store排除规则有几个实践上的注意点。第一--exclude匹配的是相对路径的模式串写node_modules和写*/node_modules/*效果不一样前者是精确匹配目录名后者更宽泛建议先在临时目录试一次用-l看结果确认。第二排除顺序有讲究有些实现里后面的规则会覆盖前面的所以先全排除、再单独加回这种写法要谨慎。第三别用排除规则去处理必须存在但内容不需要的文件比如空的占位文件那应该用别的办法。我自己的经验是维护一份项目级的排除清单放在仓库里打包脚本直接读避免每次靠记忆临时敲。清单里固定加上这几类版本控制目录、依赖缓存目录、构建产物目录、系统生成的隐藏文件、日志和临时文件。这五类基本覆盖了 90% 的体积浪费。4.3 加密包和分卷包的处理加密压缩包在企业环境里很常见尤其是要过邮件网关或者走外部传输的时候。处理这类包有两个原则密码不要出现在命令历史里密码不要出现在脚本明文里。# 从环境变量读避免写进 history zuz -p $ARCHIVE_PASS -o ./out secret.7z # 或者从文件读文件权限设成 600 zuz -p $(cat ~/.archive_pass) -o ./out secret.zip命令行参数会被记录到 shell history也会出现在ps的进程列表里同机器上的其他用户能看到。所以密码走参数是下策走环境变量是中策走交互式输入或者受权限保护的文件是上策。具体 zuz 支持哪种读取方式看 help如果没有交互式读取那就用文件加权限保护。分卷包是另一个高频场景尤其是超过几百兆的备份。分卷的坑在于卷的顺序和卷的完整性少一个卷解不开卷被改过名解不开卷的顺序乱了也解不开。我的做法是先把所有卷收齐到同一个目录确认命名连续.001、.002这种然后指定第一个卷开始解工具会自动找后续卷。ls -1 backup.7z.* zuz -o ./restore backup.7z.001解分卷之前先确认磁盘空间这个听起来很废话但我真的见过解到一半空间满了留下一个半成品目录还得手动清理。粗略估算一下分卷包总大小乘以 2.5 到 3差不多是解压后需要的空间压缩率高的格式系数更大。4.4 管道流的玩法不解压就看内容有些场景你根本不需要落盘只是想在压缩包里搜个东西或者看一眼某个文件。比如线上日志归档你只想确认某个时间点有没有报错没必要把几个 G 解出来。# 从 tar.gz 里直接抽一个文件到标准输出 tar -xzOf archive.tar.gz path/to/app.log | grep -i error | head -50 # 列出包内文件按大小排序找出体积大头 zuz -l archive.tar.zst | sort -k1 -n -r | head -20这种流式处理的价值在于省 IO 和省磁盘。对于我们这种磁盘常年紧张的环境能不解压就不解压。tar的-O参数是把内容输出到标准输出而不是落盘配合 grep、awk、sort 能拼出很多有用的临时分析命令。不过要注意-O只适合单个文件或者小文件抽大文件到管道里再 grepCPU 和内存都会不太好看这种还是老老实实解出来再处理。5. 踩过的坑和排查思路5.1 文件名乱码几乎全是编码问题Windows 上打的 zip文件名默认用 GBK 或者 CP936 编码解到 UTF-8 环境里就是一串问号或者方块。这是压缩解压领域最高频的问题没有之一。排查顺序是这样的。第一步zuz -l看列表如果列表里就乱说明是包本身的文件名编码和当前环境不一致如果列表正常但解出来乱那问题在解压环节的转码。第二步判断来源Windows 打的包大概率是 GBK。第三步用带编码参数的方式重解unzip -O cp936 package.zip -d ./out # 或者 7z x -mcp936 package.zip -o./outzuz 这类工具在检测到文件名不是合法 UTF-8 时一般会有提示但自动转码这件事本身有风险——猜错了会得到更乱的结果。所以我的建议是能不自动转就不自动转先看提示再手动指定编码重解一次确认没问题再继续。提示自己往外发包的时候尽量用 tar 系格式tar 对文件名编码的处理比 zip 干净得多。如果对方只能用 zip那就提醒一句文件名是 UTF-8减少来回扯皮。5.2 权限和软链接丢失zip 的原罪前面提过一次这里展开说。zip 格式在设计上就没有完整保存 Unix 权限位和软链接的标准方式虽然有扩展字段但支持度参差不齐。所以用 zip 打包一个带可执行脚本和软链接的目录解出来大概率是坏的。表现有三种可执行文件变成不可执行需要手动chmod x软链接变成实体文件体积暴涨软链接指向的目标不存在时变成一个空文件或者干脆丢失。解决办法只有一个这类场景别用 zip用 tar。tar 从设计上就是为 Unix 文件系统备份而生权限、属主、时间戳、软链接、硬链接、设备文件都支持。# 打包 tar -czf release.tar.gz ./build # 解包注意 -p 保留权限 tar -xzpf release.tar.gz如果交付对象确实只能用 zip那就在包里附一个恢复脚本解压后跑一遍把可执行位补回去把软链接重建出来。这活儿麻烦但比让对方手动修要体面。5.3 路径穿越陌生压缩包先看再解这是一个安全习惯问题。压缩包里的文件路径是可以带../的也就是说一个恶意构造的包解压时可能把文件写到你的主目录、写到系统目录、甚至覆盖配置文件。这类问题在各类工具的 CVE 里反复出现。现代工具大多做了防护解压时会拒绝绝对路径和带..的相对路径。但防护不是百分百不同实现的行为也不一致。所以对来源不明的包我的流程固定是三步先-l列内容看有没有奇怪的路径再解到一个隔离的临时目录不要解到工作目录或者家目录确认内容正常之后再挪到目标位置。mkdir -p /tmp/inspect cd /tmp/inspect zuz -l /path/to/unknown.zip zuz -o ./unpacked /path/to/unknown.zip这个习惯看起来啰嗦但成本极低收益是避免一次灾难。尤其是从聊天工具、邮件附件里收到的包多花十秒看一眼列表很值。5.4 常见问题速查表下面这张表是我这几年攒下来的遇到问题先扫一遍能省不少搜索时间现象大概率原因处理方式解压报格式不支持后端工具没装或者后缀被改过file看真实类型补齐后端或手动指定格式文件名全是乱码源包用 GBK/CP936 编码用-O cp936重解或换 7z 指定代码页解压后目录被几十个文件淹没包里没有顶层目录解到了当前目录解压前用-l确认始终指定-o输出目录可执行权限丢失用了 zip 格式换 tar 打包或解压后批量chmod软链接变成实体文件zip 跟随链接换 tar或打包时明确不跟随链接解压到一半失败磁盘空间不足、包损坏、分卷缺失检查df -h用-t测试完整性确认分卷齐全解压速度极慢用了 xz 或高压缩比 7z换 zstd压缩率略降但解压快一个量级中文路径在 Windows 上打不开打包时用了 UTF-8 但对方按 GBK 解打包时就统一编码或在说明里注明6. 几条用久了才明白的实操心得第一条格式选择优先于参数调优。我见过太多人纠结 zstd 的压缩级别调到几结果交付的时候对面根本装不了 zstd。先把给谁、在什么环境用定下来格式定了参数基本没什么可调的余地。日常场景里压缩级别的收益远没有你想象的大从默认级别往上调体积可能只降几个点时间翻倍。第二条打包一定要可复现。同一个目录今天打的包和明天打的包如果内容没变但哈希变了那说明打包过程带进了时间戳或者顺序不稳定。做发布包的时候这个很重要因为你要能证明这个包就是那次构建的产物。tar 有排序参数也有统一的 mtime 归零技巧这些细节在需要做完整性校验的场景里是刚需。第三条永远验证一次。压完解一次解完看一眼。这个动作我坚持了很多年救过的次数已经数不清了。验证不需要多复杂解到临时目录比对文件数量抽查几个关键文件的内容和权限齐活。十分钟的验证换的是交付之后不用半夜被叫起来。第四条把常用组合写成脚本。批量解压、带排除规则的打包、分卷恢复这三个我都有对应的脚本放在~/bin里参数化之后调用。写脚本的过程本身就是一次梳理你会发现自己在哪些地方一直靠记忆硬撑哪些地方其实有更稳的写法。工具的价值不只是省一次输入更是把正确做法固化成默认行为。第五条别迷信任何单一工具。zuz 好用但遇到奇怪的包、奇怪的编码、奇怪的权限问题该退回tar、unzip、7z、file的时候不要犹豫。工具是手段把文件完整、正确地搬到该去的地方才是目的。我现在的状态是九成场景用 zuz 一把过剩下一成现场判断哪种手段最直接就用哪种不跟工具较劲。
