先说个我遇到过不止一次的场景一个六七 G 的素材包要发给合作方邮件收不了临时建个传输入口对方又嫌麻烦事情就卡在那里。真正把问题解开的不是去找更快的通道而是把这一坨东西切成几个能各自独立传过去的小块——这就是RAR 分卷压缩最朴素的用途。它不新鲜也不是什么高级技巧但每次到文件太大传不动的时候能想起来用它、并且参数填对的人其实没那么多。很多人第一次听说分卷压缩脑子里浮现的是把文件切成几段跟剪视频差不多。这两件事差别很大。剪开的视频要按顺序严丝合缝拼回去少一段就废了而分卷压缩出来的每一个卷都是压缩包的一部分卷齐了解压时它会自己按顺序接上还原成和原始文件一模一样的东西中间不用你手动拼接、不用担心顺序搞错。代价也很明确少任何一个卷整个包就打不开。这篇写的是我在实际项目里反复用过的一套RAR 分卷压缩技巧从卷大小该填多少这种最容易被拍脑袋决定的参数到命令行批量处理再到卷出问题时的排查顺序。零基础能照着做用过几次的人大概率也能从里面挑出一两个以前没注意的点。全文不需要你懂压缩算法但我会把几个关键参数背后的道理讲清楚——不知道道理参数就只能靠一次次试。1. 分卷压缩真正在解决的问题以及它解决不了的部分1.1 三种最典型的传不过去场景第一种是单文件体积上限而且这个限制藏得很深很多人第一反应是网络问题其实是下游根本不接收。最典型的是 FAT32 文件系统单个文件最大 4294967295 字节也就是 4GB 减 1 字节多一个字节都写不进去。老 U 盘、车载记录仪、部分相机的存储卡、不少嵌入式设备出厂就是这个格式。你把一个 5GB 的包往里拖系统直接弹文件过大无法复制连进度条都不给你看。第二种是邮件和部分传输通道的附件限制。多数邮件服务的单封附件总量在几十 MB 这个量级超过就退信。企业内部的一些传输系统也卡在类似的阈值上。第三种是断点续传的代价。一个 8GB 的文件传到九成断了很多工具要从头再来。切成 8 个 1GB 的卷坏哪卷重传哪卷代价小一个数量级。这个理由在网速不稳的环境里特别实际我在外地用临时网络传东西的时候基本都靠这一招。1.2 分卷和物理切割的本质区别理解这一点后面所有参数选择都会变得顺理成章。分卷压缩是把压缩数据流按固定大小切断每一卷开头都有自己的结构信息——卷头、卷号、校验值。解压时程序读第一卷的头知道总共有多少卷、每卷多大、下一卷叫什么名字然后一路读下去把数据流重新接成一整条再交给解压引擎。整个过程对用户是透明的你只需要指定第一卷。生活里最接近的类比是一套分册出版的书。每册有独立的封面和页码缺了第二册你读不完整但第一册和第三册本身不会因此变成废纸——你可以翻开、可以看目录、可以确认它没被水泡过。而把一张纸剪成三段拼不齐就是三片废纸没有任何自我描述能力。这个区别决定了分卷压缩的两个特性可校验和强依赖。每一卷都能单独验证完整性但少一卷就解不出完整结果。1.3 什么情况下用分卷反而是自找麻烦分卷不是万能钥匙有几个场景我劝你别用。第一种是我只想从大包里单独拿一个文件出来——分成二十卷之后为了取一个几十 MB 的文件你得先集齐所有卷。这种情况用普通压缩包加目录结构更合适。第二种是包里的文件需要频繁增删改。分卷包没法像普通压缩包那样追加更新改一个文件往往要整个重做一遍。第三种是包里全是已经压过的媒体文件——视频、照片、音频、安装包。这些东西熵已经很高了再压一遍可能只小 1% 到 3%白花时间。这种场景下如果只是想过体积限制用存储模式不压缩只打包分卷反而更快更稳后面会讲具体怎么设。2. 卷大小到底填多少一个不该拍脑袋的数字2.1 从下游限制倒推而不是从上游猜我见过太多人在这里随手填个100或者500然后发现对方收不了。正确的顺序是先问清楚对面能吃什么再定卷大小。填之前把这张表在脑子里过一遍传输/存储通道常见阈值建议卷大小说明FAT32 格式 U 盘、存储卡单文件 4GB 减 1 字节3900MB 或 4000MB 以下留几十 MB 余量别贴边邮件附件单封几十 MB 量级20MB 到 25MB多卷分别发多封注意总配额部分网盘单文件从几 GB 到几十 GB 不等按实际限制减 5%平台规则会变传之前确认光盘介质700MB / 4.7GB 级别690MB / 4400MB老项目归档还会遇到内部系统上传常见 100MB、500MB、2GB对应值减 10%服务端常有隐藏的请求体上限无明确限制只为断点续传无500MB 到 1GB兼顾重传成本和卷数表里减一点余量这件事别嫌啰嗦。我曾经按 4GB 整填过一次结果对方系统是按 4×10^9 字节算的不是 4×2^30 字节差了 7% 左右第一卷就超了。单位换算是分卷压缩里翻车率最高的一环下面还会专门说。2.2 卷数越多失败面越大每一卷都是一个独立的文件多一卷就多一个可能丢失、损坏、漏传的点。二十卷里丢一卷的概率粗略地说是单卷的二十倍。我给自己定的规矩是尽量控制在十五卷以内超过就说明该换通道了比如改用支持大文件直传的方式而不是硬切。另外一个容易被忽略的点卷数多的时候接收方解压失败的排查成本会指数上升。你得先确认卷齐不齐、命名对不对、有没有重复下载的副本混在里面。我曾经收到过一个 30 卷的包里面混进了两个同名但大小不同的第九卷解压程序读到一个就报错停下查了半小时才发现是对方重复点了两次下载。2.3 4GB 这条线为什么反复出现4GB 这个数字不是随便定的它来自 32 位文件系统对单文件大小的寻址上限。FAT32 的目录项里记录文件大小的字段是 32 位最大值 2^32-1 字节换成十进制就是 4294967295。很多老设备和精简系统至今只认这个格式所以你在做要给很多人用的包时按 4GB 以下切是最稳的选择。实际操作里我一般填3900MB。原因有两层一是留出 100MB 出头的余量防止不同工具对单位理解不一致二是最后一卷通常会小一些总体体积不会因此膨胀多少。提示图形界面里分卷大小这个输入框默认单位经常是字节不是 MB。你填100得到的是一百字节不是一百兆。填完一定要看一眼右边的单位下拉框或者干脆在输入框里直接带上单位写成100m。2.4 固实压缩和分卷之间那点微妙关系固实压缩solid的做法是把包内所有文件当成一条连续的数据流来压文件之间共享字典压缩率通常比非固实高几个百分点文件数量越多、类型越杂收益越明显。但它有个代价所有文件被绑在一起了想单独解出中间某一个文件得把前面所有数据都解一遍。分卷场景下这个代价会被放大。固实流被切成若干段之后如果中间某一卷损坏影响的不只是那一卷里的文件后面依赖同一段字典的数据也可能受影响。所以我给的建议是归档备份用固实需要分发和容错的分卷包慎用固实。还有个坑值得单独说。图形界面创建分卷时固实压缩那个勾选框往往是默认勾上的而命令行版不加-s参数时默认不固实。同一个原始文件用界面和用命令做出来的包体积和容错特性可能不一样。如果你要对同一批文件做多次归档、要求结果可复现这一点必须留意。3. 图形界面跑一遍完整流程先改对三处再看三个数3.1 打开添加到压缩文件之后先把这三格改掉右键选中文件或文件夹选添加到压缩文件弹出的面板里参数多得吓人但真正决定成败的就那么几处按顺序来第一格压缩格式。必须选 RAR。这一点很多人栽过跟头——ZIP 格式本身不支持分卷面板上的分卷输入框会直接变灰。你想做分卷格式只能是 RAR。第二格压缩分卷大小。就是上面 2.3 说的那个带单位的输入框。我习惯直接在里面敲3900m或者20m用带单位写法比事后选下拉框更不容易出错。第三格压缩选项里的创建固实压缩文件。按 2.4 的判断决定勾不勾。分发用取消勾选归档用勾上。剩下那些选项第一次做的话保持默认就行不要一上来就全调一遍。3.2 压缩等级、字典大小、恢复记录怎么搭配这三个参数经常被一起乱调其实各有各的适用面。压缩等级从存储到最好大概五档字典大小从 1MB 到几百 MB恢复记录是按百分比加到包里的冗余数据。参数取值范围常见什么时候往上调什么时候往下调压缩等级存储 / 最快 / 快速 / 标准 / 较好 / 最好文本、代码、日志、未压缩的位图已压缩媒体、时间紧、CPU 弱字典大小1MB 到 256MB 甚至更大大文件、重复模式跨度长的数据内存紧张、包本身很小恢复记录0% 到 10%再高收益递减传输通道不稳定、介质不可靠包内已有恢复卷、临时文件字典大小有个反直觉的地方它吃的是压缩和解压时的内存不是磁盘。字典设到 256MB解压端也得有相应内存才能顺利处理。给不确定环境的人发包字典别超过 32MB这是兼容性和压缩率之间比较舒服的位置。恢复记录我一般给 3%。它能修复的是卷内部的局部损坏比如几个扇区读错、传输中少量字节翻转。它救不了整卷丢失那是恢复卷的活。3.3 生成之后用三个数字对一遍账包做完别急着发看一眼这三处第一卷的数量。用原始总大小除以卷大小向上取整就是理论卷数。如果实际多出一卷通常是最后剩了一点点数据单独成卷正常如果少一卷说明你对原始大小的估计错了重新算。第二每一卷的实际大小。除了最后一卷其余应该都等于你设定的值误差在几十字节以内那是卷头开销。如果某一卷明显偏小可能是磁盘写满或中途出错得重做。第三跑一次测试。图形界面里有测试压缩文件的功能命令行是rar t。这一步我强烈建议养成习惯——压缩过程中出问题不一定当场报错磁盘满、权限不足、文件被占用都可能留下一个看起来正常但实际残缺的包。测试会逐卷校验几秒钟的事能省掉后面几小时的扯皮。4. 命令行这条路批量化、可复现、能写进脚本4.1 为什么做过几次之后我更愿意敲命令图形界面点几下很方便但它有三个绕不过去的短板参数不记录下次做同样的包还得凭记忆再点一遍没法批量十个目录就要点十次服务器环境根本没界面。命令行把参数变成一行文本可以存进文档、写进脚本、交给别人复现出了问题还能逐字检查当初到底设了什么。4.2 一条命令里每个参数在干什么最常用的骨架长这样rar a -v3900m -m5 -md32m -rr3 -rv3 -ma5 backup_data.rar ./data/逐个拆开看a是添加并创建压缩包。-v3900m指定分卷大小 3900MB生成backup_data.part1.rar、backup_data.part2.rar这样一组文件。单位可以是k、m、g不带单位就是字节。-m5压缩等级最高。想快就换成-m1只想打包不压缩用-m0。-md32m字典 32MB。文件很杂、重复模式跨度大的时候可以往上调但记得考虑解压端内存。-rr3加 3% 的恢复记录用来修复卷内局部损坏。-rv3额外生成 3% 的恢复卷.rev文件这个能重建整个丢失或严重损坏的卷比恢复记录更强。-ma5强制用 RAR5 格式。想要更好兼容老工具就换成-ma4但 RAR4 不支持超过一定大小的字典和某些加密特性。最后的./data/是要打包的源目录。注意命令行默认不启用固实压缩需要显式加-s。这一点和第 2.4 节说的界面默认值相反跨工具复用同一套参数时特别容易在这上面出偏差。4.3 文件列表、排除规则、密码真正干活的时候源目录往往没法整包打总有些临时文件、缓存目录要剔除。这里几个参数很实用rar a -v500m -m3 -s -rr3 \ -x*.tmp -x*.log -xcache/* \ -n*.csv -n*.json \ -p你的口令 -hp \ report_2024.rar ./export/-x是排除支持通配符可以写多条。-n是只包含匹配的文件适合从一个大目录里挑特定类型。-p设解压口令-hp连文件名一起加密——不加-hp的话别人不输密码也能看到包里有哪些文件名敏感场景下这算信息泄露。口令这件事我多说一句分卷加密码之后每一卷都参与解密链条任何一卷损坏或缺失都会导致整体打不开而且没有密码谁也救不回来。给外部发加密分卷包时密码走另一个通道传比如另一条消息、电话别和压缩包放在同一封邮件里这是基本的操作习惯。4.4 验证和解压只需要指定第一卷做完之后先测一遍rar t backup_data.part1.rar解压的时候同样只给第一卷程序会自己顺着找后面的rar x backup_data.part1.rar ./restore/如果只想看包里的结构不解压用rar l backup_data.part1.rar。这个命令在排查包到底有没有做全的时候特别顺手它会列出所有卷以及每卷包含哪些文件。5. 卷出问题时的排查链路按这个顺序走别乱试5.1 提示找不到下一个卷这是最高频的报错原因基本集中在三处按顺序排查效率最高。第一步看命名。RAR 分卷的命名是强约定的名字.part1.rar、名字.part2.rar这样递增。所有卷的前缀必须完全一致part后面的数字必须连续。改前缀一般没问题把十个卷的名字前缀统一改掉解压时指定新的第一卷它能找到新的第二卷但改数字一定出事。有人为了排序方便把part10改成part010程序就找不到了。第二步看目录。所有卷必须在同一个目录下不能分散在几个文件夹里。合并的时候经常有人把不同批次下载的卷放在不同子目录然后逐个别名解压。第三步看有没有多余副本。浏览器重复下载会自动加(1)、(2)后缀这会让目录里出现两个第一卷。程序读到哪个不确定读到小的那个就报缺失。5.2 某一卷校验失败如果报错明确指出某一卷损坏而其他卷都正常处理路径有两条。一是有恢复卷.rev文件。把这些文件放在同一目录用修复命令让它重建损坏的那一卷rar r backup_data.part3.rar程序会扫描同目录下所有.rev文件尝试重建。恢复卷的比例决定了能救回多少——3% 大概能重建一到两卷中小体积的损坏比例越高能救的越多但包的整体体积也越大。二是没有恢复卷但包内加了恢复记录。这种情况修复的对象是卷内的局部损坏不是整卷丢失。修复完通常会生成一个rebuilt.开头的文件内容可能有少量损失但大部分能拿回来。提示修复这件事越早做越好。发现某一卷有问题先把这一组卷原样复制一份再做修复操作不要直接在原始文件上动手。修复过程有可能覆盖原文件而万一修复失败你连原件都没了。5.3 换设备、换工具之后的兼容性问题同样的卷在自己机器上好好的发到对面就解不开这种问题我遇到过几次原因大多是格式版本对不上。RAR5 是较新的格式老版本的工具可能压根不认RAR4 兼容面广但压缩率和某些特性弱一些。给不确定环境的人发包用-ma4生成 RAR4 格式更保险。还有一种情况是编码问题。包里的文件名含非 ASCII 字符时不同系统下的解压结果可能有差异。这种场景我一般会在包里加一个纯 ASCII 命名的说明文件把原始目录结构写清楚万一文件名乱了还能照着重命名。5.4 分卷的独立性边界哪些操作是安全的整理一下我在实践中验证过的边界省得你一条条试操作是否安全说明统一修改所有卷的前缀名安全解压时指定新前缀的第一卷即可修改part后的数字不安全顺序链断裂找不到下一卷把所有卷换到另一个目录安全只要还在同一目录下拆散到多个目录不安全程序按当前目录找同组卷单独复制其中一卷备份不安全单卷没有独立可解性用不同版本的 rar 工具解压多数情况安全版本差异大时可能不认格式部分卷重新压缩替换不安全卷头信息对不上校验失败6. 几个我自己踩出来的经验6.1 别对已经压过的文件用最高压缩等级视频、照片、音频、已经打包过的安装程序这些数据的熵已经很高再用最高等级压一遍收益通常只有 1% 到 3%CPU 却要多跑几倍时间。我做过一次对比一个 5GB 的视频素材目录最高等级压了四十多分钟出来 4.89GB换成存储模式两分钟出结果4.98GB。差距不到 2%时间差了二十倍。这种场景直接用-m0配合分卷又快又省心。反过来代码仓库、文本日志、CSV 导出这类数据压缩等级拉满非常值。一个 3GB 的日志目录标准等级大概能到 300MB最高等级能到 180MB 左右差距相当可观而且字典调大之后收益还会继续涨。6.2 分卷必须一起走、一起备份、一起传这是我吃过最大的一次亏。当时做了 12 卷发出去之后对面只收到 11 卷问是哪一卷少了双方来回对了半天——因为没有一份完整的清单。从那之后我养成了习惯做完分卷立刻生成一份文件清单卷名、大小、校验值和包一起发。清单可以这样生成ls -l backup_data.part*.rar manifest.txt sha256sum backup_data.part*.rar manifest.txt对方收到之后跑一遍校验一行行比缺哪卷一眼就看出来。这几十秒的操作能省掉后面几十分钟的来回确认。6.3 参数写在文件里别只留在脑子里同一个项目往往要定期做归档每次的参数最好保持一致否则前后两批包的字典大小、固实设置不一样后面合并处理的时候容易出问题。我的做法是在项目目录下放一个纯文本的pack.txt里面写着这次用的完整命令和生成时间下次直接复制粘贴改日期就行。6.4 做完立刻测别等对方反馈这条经验最朴素也最有用。压缩完当场跑rar t几十秒的事。我见过太多发出去才发现包有问题的情况而那时候文件已经传完、对方已经下班重新来一遍要等第二天。如果包特别大、测试要跑很久至少测第一卷和最后一卷。第一卷能过说明卷头正常最后一卷能过说明收尾完整中间出问题的概率相对低——虽然不能完全排除但能挡掉大部分低级错误。6.5 关于卷大小的一个个人偏好最后分享一个纯个人习惯给别人发包我很少用超过 2GB 的卷哪怕对方说没有限制。原因很简单——卷越大单卷传输失败重来的成本越高而且一旦某卷损坏、又没有恢复卷损失的数据量就是整整一卷。1GB 到 2GB 这个区间在我看来是重传不吃力、卷数不失控的平衡点。当然如果你的通道特别稳定、文件又特别大往上调也没问题只是记得把恢复卷的比例一起提上去。