简介：这是一份面向 64 位 Linux 用户与运维开发者的 RAR 6.1.b1 命令行压缩工具安装包，适合需要在 Ubuntu、Debian、Fedora 等环境中处理 RAR 档案、多卷压缩或自解压文件的场景。压缩包共 11 个文件，约 590KB，以 5 个 txt 说明文档为主体，并包含 rar、unrar 可执行程序、自解压模块、makefile 及 htm 帮助页面，兼顾工具运行与使用参考。已有 200 人学习下载。读者可从中获得可部署的 rar/unrar 二进制文件、版本与授权说明、自解压模块及基础构建入口，便于完成压缩、解压、修复损坏档案与 AES 加密等操作，也适合作为 Linux 命令行压缩工具的学习样例。

1. 一个 tar.gz 换来 Linux 上的 RAR 读写能力

凌晨被叫起来处理一台机器，原因很朴素：业务方发来一个 .rar 包，服务器上unzip一敲就报错，装个 7z 能解开却打不回去。这种时候rarlinux-x64-6.1.b1.tar.gz是最省事的答案——RARLAB 官方出的 Linux x64 命令行版，解开来是rar和unrar两个可执行文件，不依赖图形环境，丢进容器、跳板机、离线机房都能直接跑。rar管打包、加密、分卷、加恢复记录，unrar管解包、列表、校验和修复；写备份脚本、跟外部交换大文件、给归档加一层密码，靠的就是这一对。文件名里的 b1 是 beta 1，说明它还没走到正式版，生产机上先拿小包跑通再替换旧版本比较稳妥。天天跟 .rar 打交道、又不想为一个压缩包去折腾桌面环境的人，往下读就够了。

2. 解包与安装：rar 和 unrar 两个二进制怎么放才不冲突

拿到 tarball 之后的第一件事不是急着make，而是先看一眼里面装了什么。很多人装完发现rar能跑、unrar却还是系统自带的那个老版本，或者解 RAR5 的包直接报“unsupported archive”，根子都在这一步没做。RAR 在 Linux 上没有安装器、没有configure、没有动态库依赖，本质就是“把两个可执行文件放到 PATH 里”，所以放哪儿、谁先被找到，全靠你自己安排。

2.1 拆开看每样东西各管什么

包解开后是一个rar/目录，里头几样东西分工很明确：

readme.txt和license.txt值得花两分钟扫过去：rar主程序是共享软件，有试用期；unrar的条款允许随包分发。这也解释了一个常见现象——很多基础镜像里只放unrar，把rar留在构建阶段用完就删。

2.2 三条安装路径，按环境挑一条

最省事的是走包里自带的 Makefile：

# 解压并进入目录 tar -zxvf rarlinux-x64-6.1.b1.tar.gz cd rar # 走 Makefile 安装（本质就是几条 install/cp） sudo make install

-z表示用 gzip 解压，-x抽取，-v打印文件列表，-f指定文件名。make install干的事情非常朴素：把rar和unrar拷进/usr/local/bin，把rarfiles.lst放进/etc，default.sfx放进/usr/local/lib。知道这一点，后面出问题就不用猜。

如果目标机器上没有make（最小化镜像里很常见），或者你不想污染/usr/local，手动装等价：

cd rar # 手动落盘，效果与 make install 一致 sudo install -m 755 rar /usr/local/bin/rar sudo install -m 755 unrar /usr/local/bin/unrar sudo install -m 644 rarfiles.lst /etc/rarfiles.lst sudo install -m 644 default.sfx /usr/local/lib/default.sfx

install -m 755一次搞定拷贝与权限，比cp再chmod少一步。rarfiles.lst是 rar 的全局名单配置，纯命令行打包用不到它也能跑，但放上去更保险，免得某些依赖默认名单的场景行为不一致。

第三条路是完全不装，解到固定目录直接调绝对路径：

# 解到 /opt/rar，去掉 tarball 顶层的 rar/ 目录 sudo mkdir -p /opt/rar sudo tar -zxvf rarlinux-x64-6.1.b1.tar.gz -C /opt/rar --strip-components=1 # 直接用绝对路径调用，不进 PATH /opt/rar/rar a -m5 demo.rar ./src/

--strip-components=1剥掉顶层目录，避免出现/opt/rar/rar/rar这种别扭结构。这条路在容器里最常见：构建阶段用完整版打包，运行阶段只留unrar，镜像能小一截。

2.3 装完先验证：版本、路径优先级和 unrar 冲突

装完别急着写脚本，先确认三件事：找得到、是对的版本、行为正常。

# 1) 看 PATH 里到底有几个同名命令 which -a rar unrar # 2) 确认链接方式，排查后面的库依赖问题 file "$(command -v rar)" ldd "$(command -v rar)" 2>/dev/null | head # 3) 造一个包走完整链路：打包 -> 列表 -> 测试 -> 解包 cd /tmp && rm -rf rartest && mkdir rartest && cd rartest echo hello-rar > a.txt rar a demo.rar a.txt unrar l demo.rar unrar t demo.rar unrar x -o+ -y demo.rar ./out/ diff a.txt out/a.txt && echo "链路 OK"

which -a是关键。很多发行版的软件源里同时存在unrar（完整版）和unrar-free（只支持 RAR4 的简化实现），后者解不了 RAR5 存档，也解不了带加密头的包。如果which -a unrar打出/usr/bin/unrar和/usr/local/bin/unrar两行，而/usr/local/bin又排在 PATH 后面，那实际生效的就是系统那个。处理方式要么调整 PATH 顺序，要么在脚本里一律写绝对路径——我在备份脚本里就一直用/usr/local/bin/rar，图的就是不受环境变量影响。

file和ldd这两条是给老系统准备的。如果ldd打出not found或者运行时提示GLIBCXX_3.4.xx not found，说明这个二进制是按较新的工具链构建的，目标机的 C 库偏老。这种情况换机器、上容器，或者找低版本，硬凑库文件通常只会把问题推迟。

3. 打包参数：-m、-v、-rr 这套组合怎么定

rar a的默认参数对“随手压一下”够用，但一旦进了脚本、要给别人交付，默认值就不够了。真正需要你拍板的其实只有四组：压缩级别与字典、固实模式、分卷、恢复记录。这四组之间有取舍关系，参数调不好，要么体积没降下来，要么对方解压时内存爆掉。

3.1 压缩级别与字典：-m0 到 -m5 怎么选

-m控制压缩级别，-m0是仅存储，-m1到-m5逐级变慢变狠，默认是-m3。这不是玄学，选错场景的代价很直接：

-md<size>是字典大小，直接决定压缩率上限，也决定解压端要开多少内存。字典越大压得越好，但解压时内存占用大致与字典同量级。给别人交付的包，我一般把字典压在-md64m或更小；只有自己内部归档、明确知道解压端机器配置时才敢往上开。

-s是固实模式。开了之后多个小文件会被当成一个连续流来压，压缩率提升明显，尤其适合几万个源文件；代价是抽取单个文件时需要把前面的数据都解一遍，随机访问变慢，而且一旦中间出错影响范围更大。给“打包交付、对方整体解压”的场景开-s划算；给“对方只想取其中一个文件”的场景，老老实实-s-。

# 源码目录：追体积，开固实 + 较高压缩级别 rar a -m5 -s -md64m src_2024.rar ./src/ # 混合目录：不开固实，方便后续单文件抽取 rar a -m3 -s- logs.rar ./logs/ # 已是压缩格式的素材：只打包，不再浪费 CPU rar a -m0 media.rar ./media/

这三条命令里，-md64m只对开了压缩的档有意义，-m0下字典参数基本没用。另外-s与-v分卷同时使用时，卷边界会落在文件中间，这是正常行为，不是包坏了。

3.2 分卷：-v 的单位、-vn 与续卷的现实

-v是分卷开关，做磁盘镜像、给邮件系统传大文件、刻盘归档都要用：

# 每卷约 100MB，同时带 3% 恢复记录和 3% 恢复卷 rar a -v100m -rr3p -rv3p -m3 backup.rar ./data/

-v100m后缀是单位，b是字节、k是千字节、m是兆、g是 G，不带后缀按字节算。实际卷大小会有小幅出入，别拿它当精确切分工具用。默认生成的是 RAR5 风格卷名backup.part1.rar、backup.part2.rar；要兼容只认.r00、.r01的老工具，加-vn切回旧式命名。

分卷有两件事必须提前想清楚。第一，卷是有顺序的，缺了part1后面全解不了，所以传输和存储都要么整组发、要么打成一个外层包再发。第二，分卷归档不能单独改动其中一卷，新增文件只能在完整保留所有旧卷的前提下执行一次同样的rar a -v100m，rar 会从最后一卷续上；一旦中间某一卷被动过，续卷就会失败。我见过有人为了省空间删掉中间某卷，以为“反正里面有重复文件”，最后整组归档报废——分卷没有后悔药。

3.3 排除名单与文件清单：-x、-n、@ 列表

脚本化打包最容易翻车的地方不是压缩算法，是把不该进包的东西打进去了：.git、node_modules、几百兆的日志、临时文件。用-x排除：

# 递归打包 proj 目录，同时排除目录、通配符和一份名单 rar a -r -m3 \ -x'*.log' \ -x'node_modules/*' \ -x'.git/*' \ -x@exclude.lst \ proj_2024.rar ./proj/

这里有个细节值得说清：直接指定目录（如./proj/）时 rar 默认就递归；只有用通配符（如./proj/*.txt）时才需要显式加-r。-x<mask>是排除掩码，可重复出现；-x@listfile从文件读一批掩码，适合把排除规则版本化、跟着项目一起提交。exclude.lst一行一条，#开头是注释：

# exclude.lst *.tmp *.swp build/ dist/ .cache/

反过来还有-n<mask>/-n@listfile，只打包匹配的文件，做“只备配置文件和脚本”这类场景很顺手。两条一起用时注意顺序，-x的优先级高于-n，先包含再排除的直觉在这里是错的。

3.4 加密：-p 和 -hp 差一个字母，丢的是全部

# 只加密数据：文件名、目录结构可见，能列表 rar a -p'******' -m3 data_only.rar ./docs/ # 连文件名一起加密：不输密码连列表都做不了 rar a -hp'******' -m3 -s secret.rar ./docs/

-p只加密文件内容，unrar l仍能看到包内文件清单；-hp连头部一起加密，unrar l直接报错。判断一个包用的是哪种，不用问发送方，unrar l试一下就知道。

代价也很明确：-hp的密码丢了，整个包就是一块石头，没有后悔药，任何“修复工具”都救不回来。我在交付加密包时会强制做两件事——把密码单独走另一条通道发给接收方，以及本地留一份未加密的原始目录，至少保证自己这边还有源。

还有一点容易忽略：密码写在命令行上会同时留在 shell 历史（~/.bash_history）和进程列表（ps）里。脚本里我一般写成-hp不带值，让 rar 交互提示，或者干脆把带密码的那几行放进一个权限 600 的包装脚本里，跑完就unset。另外-k可以锁定归档，锁了之后rar a无法再往里加东西，适合做一次性的交付包。

4. 解包与校验：x / e / p / t 四个动作别用错

打包是可控的，解包往往不可控——包是别人给的，你不知道里面是什么结构、有没有危险路径、会不会把当前目录糊成一片。unrar的四个核心动作各有各的用途，混用之后出的问题往往不是报错，而是“文件都解出来了，但结构没了”。

4.1 x 与 e：路径保留的那点差别

# x：按包内相对路径完整还原到 out/ 下 unrar x -o+ -y pkg.rar ./out/ # e：把所有文件摊平到一层，不含任何目录 unrar e -o+ -y pkg.rar ./out_flat/ # -ad：在目标目录下自动建一个与包同名的子目录 unrar x -ad -o+ -y pkg.rar ./out/

-o+是覆盖，-o-是跳过，-or是自动改名，-oa是按时间决定；-y表示所有询问都答“是”。脚本里这三个几乎必须一起写，否则遇到重名文件就卡在交互提示上，日志里看着像“命令挂了”，实际是在等人按键。

-ad是我最常用的一个：不知道包里结构时先-ad解到独立子目录，不会把当前目录搞乱。如果还不放心，先unrar l pkg.rar看清单，或者-p直接把某个文件打到标准输出，不写入磁盘：

# 不解包，先看结构 unrar l pkg.rar # 不写入磁盘，直接看某个文件内容 unrar p pkg.rar path/to/config.ini | head -20

e用起来很爽，但代价是重名文件会互相覆盖，而且原始目录信息彻底丢失。只有当“我只要那批文件、不在乎结构”时才用它。

4.2 校验与修复：t、-rr、-rv、r

在数据相关的事情上，解包前先测一遍：

# 只读校验，不写磁盘；有问题会返回非零 unrar t pkg.rar # 修复损坏的归档，产出一个 rebuilt.rar rar r broken.rar # 修复时指定输出目录，避免覆盖原件 rar r broken.rar ./rebuilt/

-rr<N>p是恢复记录，写在归档内部，百分比形式，默认 3%。它能修的是“局部小范围损坏”，比如坏道啃掉了几个扇区；百分比给到 5% 大致能扛住这个量级。它修不了被截断的文件、也修不了丢掉一整卷的分卷归档。

-rv<N>是恢复卷，只在配合-v分卷时有效，额外生成.rev文件。分卷场景下这是唯一能补回整卷缺失的手段——丢了part2，用.rev能重建出来。这两个参数我一般成对写：-rr3p -rv3p，恢复记录管内部损坏，恢复卷管整卷丢失。

4.3 非交互与退出码：脚本里必须处理的返回值

# 静默模式只输出错误，靠退出码判断结果 if unrar t -idq pkg.rar; then echo "校验通过，开始解包" unrar x -o+ -y -idq pkg.rar ./out/ else echo "校验失败，退出码 $?" >&2 exit 1 fi

-idq是安静模式，只保留错误输出；-idv反过来打印完整信息。退出码比日志更可靠，常见的几个值：0 成功、1 有警告（如部分文件损坏但已解出）、2 致命错误、3 CRC 校验失败、11 密码错误。脚本里把 1 和 3 当作“要人工看一眼”处理，比无脑|| exit 1更合适。具体数值以unrar -?里的 Exit codes 一节为准，不同版本略有出入。

5. 避坑与排查：五条踩过的记录

5.1 环境类的两条：命令找到了，但不是你想的那个

记录一：解 RAR5 的包报unsupported archive。

现象：unrar x一个明明完好的包，返回 “Cannot open xxx.rar: unsupported archive” 或者 “No files to extract”。

原因：系统里存在两个unrar，实际生效的是软件源里的unrar-free。它是独立实现，只支持较早的归档格式，RAR5 和加密头一概不认。

解决：which -a unrar确认全部路径，unrar --version看具体版本；在脚本里改用绝对路径/usr/local/bin/unrar，或者把/usr/local/bin提到 PATH 前面。别图省事用alias，cron 里不加载你的交互配置。

记录二：运行时报GLIBCXX_3.4.xx not found。

现象：二进制能在新机器上跑，拷到一台老发行版上直接起不来，报缺GLIBCXX或GLIBC_2.xx。

原因：这个可执行文件是按较新的工具链构建的。file rar如果显示动态链接，就存在这个风险。

解决：先file和ldd确认链接方式，再决定是换机器、上容器跑，还是找低版本二进制。手动往/usr/lib64塞高版本libstdc++是最后手段，会影响同机其他程序，我在生产机上不这么干。

5.2 数据类的三条：参数用错就得返工

记录三：解出来的中文文件名是乱码。

现象：unrar x之后文件名变成一堆问号或者\xxx转义串，内容本身完好。

原因：老格式归档里文件名存的是本地编码字节（Windows 侧常见 GBK），而 Linux 终端按 UTF-8 解读。新格式默认按 UTF-8 存文件名，所以同一个包在新版本下重打就没问题。

解决：能在源头重打就在源头重打，用rar a -ma5出 UTF-8 的包；已经到手的乱码，先解出来再convmv -f gbk -t utf8 -r --notest ./dir批量改名。较新的版本提供了-sc<charset>这类字符集开关，具体写法以本机rar -?的输出为准，别照抄网上的旧帖，不同版本参数含义有出入。

记录四：密码明明对，就是解不开。

现象：同一个密码，别人的机器能解，你这边报 “Wrong password or corrupted data”。

原因：多半是-hp和-p记混了。-hp打的包连文件名都加密，unrar l会直接要求密码而不是列清单；另外从聊天工具里复制密码常带尾随空格或全角字符。

解决：先unrar l判断加密类型；密码手工重输一遍，别粘贴；确认输入法不是全角。如果确实是-hp且密码彻底丢失，直接放弃，别在修复工具上耗时间。

记录五：分卷解到一半报You need previous volume。

现象：目录里卷文件看着齐全，解包仍提示需要前一个卷。

原因：卷名被改过或卷序不连续。RAR5 的卷名是name.part1.rar这种带序号的形式，序号断了、或者中间某一卷被别的东西替换过，就会停在那里。

解决：unrar l name.part1.rar看卷信息，确认起始卷存在；有.rev恢复卷就用rar rc之类的方式重建缺失卷；没有的话只能回源头重新取整组。所以我在传分卷包时，一律先打成一个外层包再发，避免中间丢件。

6. 进阶：把 rar 塞进一条可验证的备份流水线

单条命令谁都会敲，真正省事的是把“打包—校验—留痕”三步串成一条能反复跑的流水线。我现在的习惯是：备份脚本自己不做任何假设，打完立刻用unrar t反向验证一遍，验证不通过就当这次备份没发生。

#!/usr/bin/env bash # backup.sh —— 打包并自校验，任一步失败立即退出 set -euo pipefail SRC=${1:?用法: backup.sh <源目录> <输出目录>} DST=${2:?用法: backup.sh <源目录> <输出目录>} STAMP=$(date +%Y%m%d-%H%M) BASE="backup-${STAMP}" mkdir -p "$DST" # 1) 打包：固实 + 每卷 500MB + 3% 恢复记录 + 3% 恢复卷 + 打包后自测 /usr/local/bin/rar a \ -m3 -s -md64m \ -v500m -rr3p -rv3p \ -t -ilog"${DST}/${BASE}.log" \ "${DST}/${BASE}.rar" "$SRC" # 2) 反向校验第一卷，通不过就删掉这次产物，避免留下半个备份 if ! /usr/local/bin/unrar t -idq "${DST}/${BASE}.part1.rar"; then echo "校验失败，清理本次产物" >&2 rm -f "${DST}/${BASE}".part*.rar "${DST}/${BASE}".part*.rev exit 1 fi # 3) 留一份清单，三个月后回来看还知道这包是什么 { echo "source: $SRC" echo "created: $STAMP" /usr/local/bin/unrar lb "${DST}/${BASE}.part1.rar" | wc -l } > "${DST}/${BASE}.manifest" echo "完成: ${DST}/${BASE}.part1.rar"

-t让 rar 在打包结束后自己做一次测试，-ilog把错误单独记一份日志，出问题时不用翻整段 stdout。第二步的unrar t是刻意重复的：-t是在打包进程内测，unrar t是另起一个进程从磁盘读回来测，能顺带发现写盘、传输环节的问题。校验失败就删产物，这个动作看着浪费，但比三个月后发现备份是半个要好得多。

参数上的取舍我整理成一张表，照着场景套就行：

还有个小技巧值得单独说：验证阶段别只测第一卷。分卷归档的每一卷都是独立可读的，写个循环把part*.rar全测一遍，代价只是多几秒 IO，换来的是“整组可用”而不是“第一段可用”。

# 逐卷校验，任何一卷失败立刻停 for v in "${DST}/${BASE}".part*.rar; do /usr/local/bin/unrar t -idq "$v" || { echo "坏卷: $v" >&2; exit 1; } done

从那以后我每次做归档，都强制走一遍“打完之后分开测试”的流程，哪怕是给同事临时传个包。吃过一次亏：-hp加密 + 分卷 + 没留原始目录，密码记错一位，二十多 G 的素材在硬盘上占着地方但等于不存在。现在我的规矩是——凡是上锁的包，本地必留一份未加密源；凡是分卷的包，传之前先打包成单个外层包；凡是脚本里跑的 rar，一律写绝对路径并处理退出码。希望帮到你。

本文还有配套的精品资源，点击获取