我最近在整理一批旧项目的归档文件同事从Windows那边发过来的压缩包在Ubuntu下面解压时又是一堆乱码文件名加上自己这边要批量打包日志目录上传来来回回折腾了好几次。索性把在Ubuntu下用zip压缩和解压文件夹的完整操作、踩坑记录和替代方案一次性整理出来给同样被这事困扰的人一个参照。1. 为什么在Ubuntu里绕不开zip格式先说结论在Linux服务器和开发机之间传文件zip几乎是最省事的选择。原因很简单——Windows自带的资源管理器右键发送压缩文件默认就是zipmacOS的归档工具默认也是zip到了Ubuntu这边虽然自带的Archive Manager就是文件管理器里的“压缩/解压缩”右键菜单能处理zip但命令行下的zip工具反而是默认不安装的。这就造成了一个很尴尬的局面新手刚装完Ubuntu双击一个zip包能正常打开但一用终端敲zip命令系统直接提示command not found。这个现象背后的原因是Ubuntu的哲学是“最小化默认安装”桌面版会预装图形化解压工具但命令行工具链不会全给你铺好。对于日常在服务器上操作的人来说没有命令行zip就意味着没法写脚本批量打包、没法做定时备份归档所有操作都得依赖鼠标右键这在几十个文件夹的场景下效率实在太低。再说zip格式本身的价值它的兼容性极佳几乎覆盖所有操作系统和压缩软件而且相比tar.gzzip最大的优势是支持“直接访问单个文件”——解压时不需要把整个归档读取完毕随机访问速度更快。代价呢就是压缩率略低对文本代码这类文件同样内容的zip通常比tar.gz大几个百分点。但考虑到跨平台传递的便利性这点体积差异完全是可接受的。所以这篇内容的核心就是讲清楚三件事在Ubuntu下怎么用命令行把文件夹压成zip怎么把zip解出来还保证文件名不乱码以及什么场景下该加点别的参数、什么时候干脆换成tar.gz更合理。2. 最常用的压缩与解压命令拆解2.1 安装zip和unzip以及为什么系统不自带刚提到Ubuntu默认没有命令行zip第一步自然是装上。在Ubuntu 20.04及以后的版本包括22.04、24.04 LTS安装命令都一样sudo apt update sudo apt install zip unzip注意这里要sudo apt update先刷新一下软件源很多同学直接apt install报“Unable to locate package zip”就是因为本地包索引太旧压根不知道zip这个包存在。这也是Ubuntu安装软件最经典的一个坑比如“ubuntu安装gcc失败”“ubuntu安装docker失败”这类报错八成都是同一个原因。装完后可以用zip -v和unzip -v验证版本同时能看到编译时支持的压缩算法特性。2.2 压缩文件夹的基础命令与参数基础用法一句话就能说清zip -r 目标文件名.zip 要压缩的文件夹-r是recursive的缩写表示递归处理子目录。如果不加这个参数zip命令只会把文件夹本身放进去里面的文件一概不收压出来几乎是个空壳。举个例子我要把当前目录下的project文件夹压成project-2025-01-15.zipzip -r project-2025-01-15.zip project如果你已经在project目录内想压缩“当前目录所有内容”注意命令是zip -r ../project-2025-01-15.zip .这里有个细节路径中的.代表当前目录这样压出来的压缩包内部结构是./文件1、./子目录/文件2解压时会在当前位置还原所有内容而不会多嵌套一层project目录。很多脚本新人在这里犯迷糊搞不清解压后多了一层目录还是少了一层目录其实就是压缩时指定的路径决定的。我个人的经验是为了“可预期性”压缩前先想清楚解压后的目标结构压出去要在任意地方解压解压结果里最好有个独立顶层目录的那就压缩文件夹本身压的内容就是某个目录的全部文件希望解压后直接平铺的那就在目录内用.2.3 解压命令与常见参数解压就更简单了unzip 文件名.zip默认是解压到当前目录。想去指定目录加-d参数unzip 文件名.zip -d 目标目录这里要给Linux新手提个醒-d这个参数后面跟的是目标目录而且如果你指定的目录不存在unzip会自动创建不需要先mkdir。这个行为和Windows下的解压工具不太一样很多从Windows转过来的人会下意识先建文件夹再解压其实多此一举。解压时我想看看到底包含哪些文件不想立即操作用-l只是列出内容列表unzip -l 文件名.zip除了静默解压不打印过程用-qquiet后面测试脚本时配合得比较多unzip -q 文件名.zip -d 目标目录另外还有个特别实用的参数-o覆盖已有文件时不提问。非交互脚本里没有-o一旦目标文件已存在unzip会停下来问你是替换、跳过还是重命名脚本就卡死了。unzip -qo 文件名.zip -d 目标目录2.4 校验压缩包完整性防止解压到一半报错从网上下载的zip包经常出现“解压到99%突然报CRC错误”的情况尤其跨平台传输后文件损坏很常见。解压前先校验一下是种好习惯unzip -t 文件名.zip-t表示test integrity会逐个文件做CRC校验输出每个文件的校验结果。全绿再解压可以省掉一半的意外。顺带提一个判断压缩工具的小技巧如果服务器上没有zip命令但你有root权限也可以临时用Python来解压作为应急方案——python3 -m zipfile -e 文件名.zip 目标目录. 但平时还是用系统包管理器装好zip/unzip干净利落。3. 中文文件名乱码跨平台传递最容易踩的坑3.1 乱码问题的来龙去脉在Ubuntu里解压Windows传过来的zip中文文件名经常变成一堆类似绔熸埓的乱码。这个问题的根源不是用户操作错了而是两个操作系统对文件名编码的处理方式不一样。Windows的中文环境默认使用GBK编码Windows中文版的系统代码页是CP936它创建zip包时文件名是按GBK写入的。而Linux默认使用UTF-8编码unzip在解压时按UTF-8去解读文件名自然就对不上号显示出乱码。说白了就是编码表对不上同样一个“项目.zip”里的“项”字在GBK里的字节序列和在UTF-8里的字节序列完全不同解压工具拿UTF-8的规则去翻译GBK的字节出来就是天书。3.2 怎么解压才能不乱码解决思路有两个方向一是指定unzip用GBK解码二是先用工具把编码转换到UTF-8再解压。第一个方向上最常用的是unzip -O参数注意是大写字母O指定解压时使用的字符集unzip -O GBK 文件名.zip这样unzip就会按GBK去解析zip包里的文件名编码。但这里有个限制-O参数在部分发行版自带的unzip版本里并不支持比如用Info-ZIP的某些编译版本会直接报错。我查过这个问题Ubuntu官方源里的unzip一般支持-O但如果你的环境比较精简或者用的是BusyBox unzip那就得走第二条路。第二条路是用convmv或者Python脚本转换。实际项目中我更推荐用Python一次解决因为逻辑直观且不依赖unzip版本python3 -c import zipfile with zipfile.ZipFile(文件名.zip, r) as zf: for info in zf.infolist(): # 将GBK编码的文件名转成UTF-8字符串 name info.filename.encode(cp437).decode(gbk) zf.extract(info, path目标目录) 等等这里还有个隐藏问题zip标准规定文件名应该用UTF-8但Windows传统工具写入GBK时并不会在元数据里标注“我用的是GBK”导致很多工具在读取时把原始字节按Latin-1也就是cp437直接映射成Unicode字符串。所以上面代码里是先encode(cp437)拿回原始字节再用GBK解码。这个操作的原理我之后再细说。3.3 一个更通用的编码矫正方案上面的Python方案对“Windows中文版压缩出来的zip”有效但实际环境更复杂——有的是用WinRAR压的、有的是用7-Zip压的、有的压缩时专门选了UTF-8。所以更稳妥的方案是先用unzip -l看一眼文件名乱码模式再做针对性处理。实操时我的习惯是先直接unzip -l 文件名.zip | head -20观察文件名里中文部分是不是形如???或者连续乱码符号。如果乱码先试unzip -O GBK如果提示不支持-O再上Python脚本。Python脚本里我一般把cp437改成latin-1试试因为有些实现是直接按Latin-1反向映射的——这两种编码在0x80以下的字节完全相同差别只在扩展字符区所以哪个能还原出正常的GBK中文逐个尝试即可。这里给出我用的完整脚本版本支持指定输出目录和自动建目录import zipfile, os, sys zip_path sys.argv[1] out_dir sys.argv[2] if len(sys.argv) 2 else . os.makedirs(out_dir, exist_okTrue) with zipfile.ZipFile(zip_path, r) as zf: for info in zf.infolist(): try: raw info.filename.encode(cp437) # 尝试GBK解码失败就退回原始文件名 try: name raw.decode(gbk) except UnicodeDecodeError: name info.filename except UnicodeEncodeError: name info.filename target os.path.join(out_dir, name) if name.endswith(/): os.makedirs(target, exist_okTrue) continue os.makedirs(os.path.dirname(target), exist_okTrue) with zf.open(info) as src, open(target, wb) as dst: dst.write(src.read()) print(done. output in, out_dir)这段代码保存为extract_zip.py用python3 extract_zip.py 文件名.zip 目标目录运行即可。脚本的精髓在于利用Python可以灵活控制编解码过程先把Python读到的字符串还原成原始字节再按目标编码解码而不是被zipfile库默认的UTF-8假设牵着走。3.4 如何在压缩时就从源头避免乱码讲完解压再讲讲压缩。Linux下压中文文件名给Windows用户时直接zip -r 文件.zip 中文文件夹Windows端用资源管理器解压时大概率正常原因在于较新版本的zip工具默认按UTF-8写入并且设置了UTF-8标志位Windows 10/11的资源管理器都能识别。但如果对方用的是老版本WinRAR或者XP时代的工具就可能乱码。如果明确知道对方环境老可以主动用指定码表压缩zip -r 文件.zip 中文文件夹其实zip命令本身没有直接指定文件名编码的参数实际项目中我更建议用Python做跨平台打包工具彻底绕开编码争端import zipfile, os, sys src sys.argv[1] out sys.argv[2] with zipfile.ZipFile(out, w, zipfile.ZIP_DEFLATED) as zf: for root, dirs, files in os.walk(src): for f in files: full os.path.join(root, f) arcname os.path.relpath(full, start.) zf.write(full, arcname)这个工具压缩时使用的是Python默认的UTF-8文件名编码所以对现代Windows完全没有问题。4. 压缩率与内容选择zip的金牌搭档参数zip不只是“压缩”用好参数能显著改变效率和结果。下面这组是我实际工作中高频使用的参数组合。4.1 用压缩级别控制体积与耗时-0到-9是zip的压缩级别-0表示只打包不压缩-6是默认值-9是最大压缩率。对文本配置类文件-9能显著减小体积但耗时增加对已经压缩过的文件jpg、png、mp4所有级别都差不多纯粹浪费时间。运维备份场景里我通常用-6保持默认兼顾速度和体积归档长期存储的项目源码用-9临时打包上传用-0最快。用-9压代码目录的对比我实际测过一个包含node_modules的Node项目-0压出来是45MB-9压出来是12MB时间从2秒涨到35秒。如果只是快速传到服务器上再解压-0反而更划算。4.2 排除不需要的文件打包项目时经常需要排除node_modules、vendor这类超重目录或者.git、__pycache__这些中间产物。用-x排除模式zip -r 项目备份.zip 项目目录 -x 项目目录/node_modules/* -x 项目目录/.git/*排除多个目录就加多个-x参数注意引号内的通配符必须加引号否则shell可能自作主张先展开通配符导致匹配失败。这又是一个shell新手常见坑。如果用zip命令的--exclude也可以但-x是短选项写脚本更简洁。4.3 使用文件列表而非手动指定如果要打包的是一堆分散路径下的文件或目录把它们写进一个列表文件会更清晰zip - 选中的备份.zip 文件列表.txt-表示从标准输入读取要添加的文件列表每行一个路径。在自动化脚本里可以动态生成列表再打包比拼一长串文件名可靠得多。4.4 增量更新压缩包还有一种常见需求压缩包已经生成目录里只有几个文件改了重新全量压缩浪费时间。zip支持增量更新zip -u 备份.zip 目录-u是update模式只更新比压缩包内版本更新的文件。备份脚本里配合cron定时任务既保留历史版本又不会每次都做全量压缩。不过要注意这个更新模式不会删除压缩包中已经存在但源目录里已被移除的文件如果想同步删除用-d定向删zip -d 备份.zip 目录/旧文件.txt5. tar.gz与zip如何选择什么时候别再用zip5.1 tar.gz的真正优势Linux社区里tar.gz比zip更常见尤其在源码包、安装包、容器镜像上下文里。tar.gz的全称是先tar打包成单一存档再gzip压缩。它和zip的本质区别在于tar本身不做压缩只是把所有文件拼成一个连续字节流保留权限、属主、符号链接、时间戳等元信息gzip负责压缩这个连续字节流。这个结构带来的三大优势一是权限和链接信息完整打包源码后解压还能保持可执行权限二是压缩率通常比zip高一点三是对大量小文件的打包速度往往更快因为压缩的是连续数据流有更好的压缩窗口。测试过几百个小文件的目录tar.gz和zip的压缩时间几乎一样但tar.gz压缩率高了大概5%-10%。在磁盘和带宽更贵的服务器场景里这个差距值得考虑。5.2 在Ubuntu里打包tar.gz的标准操作# 创建tar.gz tar -czvf 备份.tar.gz 项目目录 # 解压tar.gz tar -xzvf 备份.tar.gz -C 目标目录 # 只查看内容不实际解压 tar -tzvf 备份.tar.gz参数拆解c创建x解压z使用gzip压缩/解压v显示过程f指定文件名。注意f必须是最后一个参数后面紧跟压缩包名字这是一个经典约定。如果不加z出来的就是tar裸包加j就变成tar.bz2压缩率更高但压缩速度更慢加J是tar.xz现代Linux发行版常用压缩率最高。5.3 什么时候坚持用zip什么时候果断用tar.gz一个简洁的判断标准要跨Windows/Linux/macOS传递、对方可能用图形界面双击解压的用zip纯Linux环境、命令行操作为主、关心权限和压缩率的用tar.gz。具体来说给同事发项目源码对方可能用Windows发zip省心服务器上备份日志、数据库导出文件用tar.gz保留权限还能省空间发布开源软件包惯例是tar.gz或tar.xz用户群体都在Linux上给客户交付打包好的素材资源zip仍是兼容性最好的选择容器镜像或系统镜像通常用tar裸包配合pipe使用而不是带压缩。5.4 终极技巧管道压缩和分卷压缩在Linux管道哲学下tar完全不落地文件实时压缩流到目标tar -czf - 项目目录 | ssh userserver tar -xzf - -C /远程目录这条命令直接实现本地打包加密传送到远程解压全程不产生中间文件对超大目录备份非常实用。另一个技巧是分卷压缩当zip包超出U盘FAT32的4GB单文件限制时用-s分卷zip -s 1000m -r 大文件备份.zip 大目录分卷后的文件名是备份.z01、备份.z02、备份.zip必须全部拿到才能解压。不过解压前需要先合并zip -s 0 大文件备份.zip --out 合并后的.zip把分卷合成一个完整zip。这个功能Windows下的工具不一定都支持跨平台时慎用。6. 进阶补充zip有密码保护与基于时间的增量备份思路6.1 给zip包加密码并正确使用隐私文件传给别人想要一层密码保护。zip命令直接支持zip -re 加密备份.zip 敏感目录-e会让zip交互式询问密码并确认一次。注意它只是用对称加密算法传统ZipCrypto或者AES-256取决于编译选项加密内容对文件名的隐藏能力有限。更好用的是配合-P参数在脚本中直接指定zip -rP MySecretPass 加密备份.zip 敏感目录不过-P方式会在进程列表和shell历史里留下明文密码安全性要打折扣。生产环境推荐用expect或sshpass这类工具做交互式密码输入或者干脆用GPG对称加密整个压缩包这超出了本篇范围先不展开。6.2 定时增量备份配合zip的-u参数前面说过zip -u能增量更新压缩包和cron配合可以做非常轻量级的备份方案#!/bin/bash # 每天凌晨1点备份项目目录到带日期的zip BACKUP_DIR/var/backups/project mkdir -p $BACKUP_DIR cd /var/www zip -rqu -9 $BACKUP_DIR/project-$(date %F).zip project-q静默模式适合脚本-u只更新变更文件-9最大压缩。日期后缀保证每天生成一个新包不会互相覆盖。6.3 处理压缩包内文件权限问题解压zip后可能遇到一个现象源目录里明明是755权限的可执行脚本解压出来变成644跑不动。这其实是zip格式的限制zip本身不保存Unix权限位除非使用了外部属性字段但跨工具支持不一致。应对方案是解压后统一修复find 目标目录 -type f -name *.sh -exec chmod x {} \;如果对整个目录都要恢复可执行位chmod -R x 目标目录也行但这会把所有文件都加上x不够精确。另外解压后文件属主是当前用户不会保留原来的uid/gid想保留完整权限和属主还是得用tar。6.4 一个大文件快速压缩的备选使用7z命令如果你觉得zip压缩率不够系统里还想多一个tool安装p7zip-full后可以用7zsudo apt install p7zip-full 7z a 档案.7z 项目目录 7z x 档案.7z -o目标目录7z的压缩率比zip高不少对大文件更明显代价是对方也得装7-Zip或者p7zip才能解压。跨平台场景下zip仍是最大公约数但处理内部备份时可以7z。7. 图形界面操作与命令行协作Ubuntu桌面用户的实际配合方式7.1 文件管理器自带的压缩功能与PLC格式差异Ubuntu桌面GNOME的文件管理器Nautilus右键菜单里有“压缩”选项选择“ .zip”格式就能打包文件夹。这个操作本质上调用的是file-roller后端最终生成的也是zip。但这个图形界面的压缩行为有个值得注意的细节它默认不会保留源目录内隐藏文件吗实际上file-roller会包含隐藏文件但你需要确认一下压缩文件里是否有.env这类敏感文件被无意打包。有次我把项目目录右键压缩发给别人事后发现.env数据库凭据被一起打进去了吓得赶紧改密码。图形界面压包前一定要先看一眼隐藏文件列表。7.2 双击解压与命令行解压的结果差异桌面环境下双击一个zip包Archive Manager默认解压到~/Downloads或者当前目录下的新文件夹文件名用UTF-8解码遇到Windows来的GBK包也会乱码。但图形界面的乱码比命令行更难处理——右键没有提供“指定字符集”这个选项。所以遇到乱码还是回到终端用unzip -O GBK或者Python脚本解压最靠谱。这再次说明命令行工具不可替代。7.3 拖拽与临时目录一个很小的优化建议在处理特别大的zip包时如果桌面环境解压长时间无响应换个思路先用命令行解压到临时目录再用文件管理器拖到目标位置。unzip -q 大包.zip -d /tmp/解压临时目录然后mv过去比在文件管理器里干等强得多。另外经常处理zip的人可以考虑安装nemo或nautilus的nautilus-extension-gnome-terminal这类扩展在文件管理器里直接打开当前路径的终端把命令行和图形界面串起来。8. 实战场景从一个项目归档需求看完整的命令设计最后用一个完整场景串起全文内容。假设有个同事需要把/home/user/webapp整个项目做一次归档要求排除node_modules和.git做成zip方便发给Windows端的项目经理查看文件里包含deploy.sh解压后要能直接执行不能丢失权限。按前面的知识最简洁的命令是cd /home/user zip -r9 webapp-archive.zip webapp -x webapp/node_modules/* -x webapp/.git/*但这样deploy.sh的权限在Windows端解压会丢前面说过zip不保存Unix权限。这里就要做一个取舍如果项目经理那边只是要代码查看、不会执行脚本这没问题如果对方也要在Linux环境里实际部署就必须转用tar.gz保留权限位。所以更合理的两种方案项目经理只需浏览代码用zip灵活、兼容、双击可看对方拿到后要直接部署用tar.gztar -czvf webapp-archive.tar.gz --excludewebapp/node_modules --excludewebapp/.git webapp解压后执行权限完整保留。顺带补充tar --exclude的写法要注意--exclude要放在源目录前面这是GNU tar的参数顺序要求放在后面可能不生效。打包完成后校验一下内容再发出去unzip -l webapp-archive.zip | tail -20 tar -tzvf webapp-archive.tar.gz | tail -20确认没有意外内容包含进去再走邮件或网盘发送流程。这套流程就是我日常归档项目的标准作业方式虽不复杂但每一步都是踩过坑之后的沉淀。下次再遇到打包需求直接套这个模板基本不会出错。