企业官网建设流程全解析

简介：这是一款面向Linux 64位（x86_64）系统的RAR压缩工具测试版，对应版本6.1.b1，主要解决在纯命令行环境中创建、解压、修复RAR档案的需求，适合系统管理员、运维工程师以及经常处理跨平台压缩包的开发者。包内共11个文件，体积仅590KB，以rar与unrar两个可执行文件为核心，另有txt说明文档、htm离线帮助、makefile构建脚本、sfx自解压模板及lst列表文件，结构完整，解压后即可直接使用。已有197人学习浏览。除了常规压缩解压，该工具还支持多卷分割、自解压包生成、损坏档案修复和AES-128/AES-256加密，可在Shell脚本中批量调用，完成日志归档、备份文件加密、分包传输等任务；由于是测试版，核心功能完整，但个别边界情况仍需留意。与图形界面工具相比，这款命令行版本更轻量，便于在无桌面环境的服务器上集成到自动化运维流程中。

1. rarlinux-x64-6.1.b1：Linux 服务器处理 RAR 交付物的兜底方案

rarlinux-x64-6.1.b1 这个包，是我在 x64 Linux 服务器上处理 .rar 交付物时的兜底选项。Windows 那边发过来的压缩包，拿到服务器上一敲 tar 就报错，gzip 也解不动——这不是命令写错，而是 RAR 格式必须由 RAR 自己的程序来解。系统仓库里的 unrar-free 勉强能解，却不支持压缩和加密回传；折腾 7z 又要在每个环境里陪跑依赖。rarlinux-x64-6.1 的 b1 是 beta 1，虽是测试版本，命令行功能一个不少：解压、打包、加密、多卷拆分都有。适合定期处理 Windows 交付物的运维、需要在服务器上归档日志与数据库备份的工程师、经常在 Linux 下打开网盘数据的分析岗。这套包使用门槛不高，但部署位置、参数细节和边界条件，值得一步步理清楚。

2. 安装与部署：tar.gz 解压、二进制落位与 PATH 配置

2.1 为什么不用系统自带的 unrar：选型与架构确认

先回答一个常见疑问：为什么不直接用 yum install unrar 或 apt install unrar？原因是大多数发行版仓库里的 unrar 是 unrar-free，它是一个裁剪过的读取器，能解压一部分 RAR，但缺少压缩、加密、分卷等写入类子命令；p7zip 对 RAR 的支持也到不了官方实现的完整度，某些新版本格式会落后一拍。而这个包是 RAR 官方发布的 Linux 版本，把 rar 和 unrar 两个程序都带上了，rar 负责压缩，unrar 专注解压，功能闭环。选型定下来之后，再谈架构。

别急着解压。先跑 uname -m 确认架构是 x86_64。我见过有人在 ARM 服务器上硬解 x64 包，最终报 Exec format error，白白折腾半小时。如果你确实在 ARM 环境，需要找对应的 arm 版本，安装步骤一样，只是二进制架构不通用。确认无误后再解开包：

uname -m # 输出 x86_64 就对了，然后解包 tar -xzvf rarlinux-x64-6.1.b1.tar.gz ls -la rar/

tar 的参数拆开讲：-x 是解压动作，-z 表示处理的是 gzip 压缩的包，-v 把解压过程打印到终端，-f 后面跟文件名，这四个字母在实际运维里几乎绑定出现。解开后目录名通常不是 rarlinux-x64-6.1.b1，而是 rar/，这一点经常被脚本里的路径踩到，稍后配置时要注意。

2.2 二进制落位：复制法还是软链接法

把二进制放哪里，直接决定后续升级和卸载的体验。我见过有人把解压目录留在 /root，然后用绝对路径到处写，结果清理磁盘时误删，整个服务器再也找不到 rar 命令。常用做法是二选一：把可执行文件复制到 /usr/local/bin，或把整个 rar 目录放到 /opt，再用软链接暴露命令。

# 方案一：把两个可执行文件复制到 /usr/local/bin sudo cp -a rar/rar rar/unrar /usr/local/bin/ sudo chmod +x /usr/local/bin/rar /usr/local/bin/unrar # 方案二：把 rar 目录整体放到 /opt，软链接到命令目录 sudo cp -a rar /opt/rar sudo ln -sf /opt/rar/rar /usr/local/bin/rar sudo ln -sf /opt/rar/unrar /usr/local/bin/unrar

两种做法都可以，但我倾向方案二。理由和踩过的坑相关：rar 运行时需要依赖同目录下的辅助文件，单独把 rar 二进制复制出去，一旦运行时要读取这些文件却找不到，就会表现出一些反常行为，比如某些参数不生效或命令直接退出。整个目录保留在 /opt，升级时只需要替换 /opt/rar 里面的内容，软链接不用动。方案一适合临时机，几分钟内启用的场景没问题；方案二适合长期使用的生产机，卸载时删掉 /opt/rar 和两条软链接，干净利落。

2.3 全局 PATH：profile、bashrc 与定时任务的差异

命令放好后，核心问题就是 PATH。用户的 .bashrc 只在交互式登录时加载，cron、systemd、CGI 类程序一概不读它。把 rar 目录写进全局 profile，比写入某个用户的 bashrc 更可靠：

echo 'export PATH=/opt/rar:$PATH' > /etc/profile.d/rar.sh source /etc/profile.d/rar.sh which rar # 输出 /opt/rar/rar 才算成功

用 /etc/profile.d/rar.sh 而不是直接改 /etc/profile，好处是职责单一，卸载时删除这个小文件即可。加进 PATH 后，root 和普通用户登录时都能找到 rar。但要注意一个边界：Web 面板定时任务、CI 流水线这类脚本，通常在非登录非交互 shell 下执行，profile 也不一定被读取。所以到了脚本内部，我一般不会靠 PATH，而是直接在脚本顶部声明：

RAR=/usr/local/bin/rar # 或者 RAR=/opt/rar/rar $RAR t /data/backup/weekly.rar

这种做法相当于给命令上了双保险：交互终端靠 PATH 用，脚本用显式变量用。前面说过的 command not found 问题，绝大多数是这一步没做到位。

2.4 权限与挂载选项：普通用户调用的隐藏门槛

权限问题比 PATH 更隐蔽。软链接指向 /opt/rar 后，root 能跑，nginx 或 www 用户跑却报权限错误。原因有两类：一是 /opt/rar/rar 的可执行位在复制过程中丢失，二是目录和文件本身的访问权限不足。先按下面顺序补权限：

sudo chmod 755 /opt/rar sudo chmod 755 /opt/rar/rar sudo chmod 755 /opt/rar/unrar ls -l /opt/rar/rar # 确认输出 -rwxr-xr-x

rarlinux 包解出来通常自带执行权限，但从 Windows 转过来的文件或某些压缩传输工具会把这些权限抹掉。另一个容易忽略的点是挂载选项：如果 /tmp 或 /opt 所在分区用 noexec 挂载，就算文件有执行位，内核也会直接拒绝运行，报错往往是 Permission denied。排查时先 df -h /opt 看挂载点，再用 mount -o remount,exec /opt 临时放行，长期方案是把 rar 放到非 noexec 的分区。这两条加起来，能避免许多「明明按教程装了却跑不起来」的玄学困扰。

3. 高频命令实战：解压、压缩、加密与多卷拆分

3.1 解压命令 x 与 e：保留目录 vs 全部拍平

RAR 命令行最常用的是 x 和 e 两个子命令。x 解压时保留压缩包里的目录结构，e 则把全部文件平铺到目标目录。二者的区别不只是目录结构，大量同名文件在 e 方式下会互相覆盖，这才是真正的翻车点。

# x：按原目录结构解压到 /data/restore rar x /data/backup/backup.rar /data/restore/ # e：舍弃目录结构，把文件全部摊平 rar e /data/backup/backup.rar /data/restore/

x 适合迁移和完整还原，它能保留原打包者在 Windows 下建的路径；e 适合从包里捞一个文件、或者包内只有一层结构的场景。目标目录不存在时 rar 会自动创建，省去 mkdir 一步。自动化脚本里我几乎必加两个参数：-o+ 表示覆盖已存在文件，-y 跳过所有确认提示。不加 -y 时，批量解压遇到同名文件会停下来问你，脚本就此挂住——这个细节最容易忽视，也是 cron 任务卡死的一大来源。

补充一个习惯：解压前先 rar l 或 rar t 预览一遍。x 在遇到包内路径名带危险层级时，可能给你解出一堆意想不到的目录结构，先看内容再解压，是我处理未知压缩包的铁律。

3.2 压缩命令 a：常用参数与压缩级别

创建 RAR 用 a 子命令，追加文件到已有包也是 a。压缩时最常用的开关是压缩级别 -m、固实模式 -s、递归 -r 和排除基础路径 -ep1。

# 把 /var/log/app 递归压缩，最大压缩级、固实模式、去掉根路径 rar a -r -m5 -s -ep1 /data/backup/app_$(date +%F).rar /var/log/app

参数逐个拆解：-r 递归进子目录，压缩目录时建议带上，避免有的版本只把目录本身加进去；-m5 是最大压缩级别，压缩时间最长但体积最小，-m0 只打包不压缩，速度最快，-m1 到 -m3 是日常档位；-s 开启固实模式，把包内文件作为一个整体数据流压缩，压缩率更高，代价是损坏后恢复难度和随机读取成本增加；-ep1 表示排除命令行传入的根目录路径，解压出来直接是 app 下的相对路径，而不是 /var/log/app/xxx 一层套一层。

备份日志这类重复内容时，用 -m5 -s 能压掉大部分重复字节；如果备份的是已经压缩过的视频、图片、数据库导出文件，-m0 反而更合理，能省掉大量 CPU 时间。表格化的选择逻辑大概是：-m0 存储级，适合已压缩内容；-m1 快速档，适合临时打包；-m3 标准档，日常均衡；-m5 最大压缩，适合日志和文本类。整体没有绝对正确答案，按内容类型决定就好。

3.3 加密与多卷拆分：-p、-hp 与 -v

RAR 的加密分两个层级，很多人压完发给对方，对方还是能在压缩包里看到文件名列表，原因就是只用了 -p 没加 -hp。单独 -p 只对文件内容加密，文件名和目录结构仍然可见；-hp 加密文件头，把文件名列表一起藏住。交付敏感资料时，我用的是文件头加密：

# -hp 同时加密数据与文件头，文件名列表不会暴露 rar a -hp'P@ssw0rd2024' secret.rar /data/secret/ # 每 100M 拆一个分卷 rar a -v100M /data/backup/large_$(date +%F).rar /data/backup/dump/

密码直接写在命令行里会留在 shell 历史中，生产脚本里建议用环境变量传入密码，或者运行时交互式输入；演示写法只是为了让你看清参数结构。多卷参数 -v 支持 k、m、g 单位，-v100M 就是每卷 100MB。拆分后文件名会自动带 part01、part02 后缀。解压多卷包时只要指定第一个分卷，rar 会自动找后续分卷，前提是它们都在同一个目录且命名没被改动。如果有人单独下载了 part02 想解压，rar 会提示缺少第一个分卷，这不是命令写错，是分卷规则如此。

3.4 查看与校验：l、t 子命令的排错价值

l 列出压缩包内容，t 测试压缩包完整性。这两个子命令在排错场景里使用频率最高。接别人压缩包的第一件事，我会先 rar l 把文件路径、大小、日期看一遍，确认里面没有诡异路径再解压。

rar l backup.rar rar t backup.rar echo $?

l 的输出包含原始路径、体积、压缩率和日期，能快速判断文件名编码是否正常、体积是否合理，也会提前暴露包内是否有危险路径。t 会把整个包在内部解压并比对 CRC 校验值，完整无误才返回 0。在脚本里，rar t 是承接下一步解压的可靠闸门：只有 t 通过，才允许 rar x 落地。对多卷包执行 t 同样只需指定第一个分卷，rar 会自动遍历其余分卷。我还会在 t 之后顺手看一遍 $?，因为有的脚本环境会把 rar 的非 0 退出码吞掉，显式 echo 一下更稳。

4. 进阶用法：日志归档、Web 面板集成与自动清理

4.1 把日志目录写成按期归档的备份脚本

「压缩完马上校验」是我写备份脚本时的固定动作。把日志目录递归打包、做最大压缩、去掉根路径，再立刻跑一趟 rar t，两步串联，保证落到磁盘的备份文件一定是完整可用的。脚本模板如下：

#!/usr/bin/env bash set -euo pipefail RAR=/usr/local/bin/rar LOG_DIR=/var/log/app BACKUP_DIR=/data/backup DATE=$(date +%Y%m%d_%H%M%S) TARGET="${BACKUP_DIR}/app_${DATE}.rar" mkdir -p "$BACKUP_DIR" $RAR a -r -m5 -s -ep1 "$TARGET" "$LOG_DIR" $RAR t "$TARGET" || exit 1 echo "backup finished: $TARGET"

set -euo pipefail 三个开关各司其职：遇到错误立即退出、变量未定义报错、管道中间环节失败也退出；$RAR 指向 rar 绝对路径，避开了 cron 环境没有 PATH 的坑；带时间戳的文件名让同名文件不会互相覆盖。t 校验失败时 exit 1，脚本调用方可以通过退出码知道备份没成功。我还会把清理动作从压缩脚本里拆出去，不推荐在压缩脚本里顺手删老包，避免脚本中途失败连带把文件删了。

4.2 在 Web 面板与 CI 脚本中调用 rar

宝塔、AMH、GitLab CI 这类环境，定时任务默认用的可能是 sh 而不是 bash，环境变量极简。面板里填 rar 开头大概率 command not found，根源不是 rar 没装，而是执行环境不读 /etc/profile。处理办法只有两条路：脚本里显式写绝对路径，或者开头先把 PATH 铺好。

#!/usr/bin/env bash PATH=/usr/local/bin:/usr/bin:/bin export PATH # 面板任务里填这个脚本路径，用 bash 执行 if /usr/local/bin/rar t /data/backup/weekly.rar; then rm -f /data/backup/tmp_*.rar fi

这里有一个甄别技巧：面板默认用哪个 shell 解析脚本，决定了 $(date +%F) 这类语法能不能用。dash 对某些 bash 扩展语法支持有限，最好在面板的任务设置里显式写 bash /path/script.sh，或者让任务调用一个以 #!/usr/bin/env bash 开头的脚本文件。另一个隐藏问题是执行用户：很多面板用 www 用户跑任务，备份目录的写权限、rar 可执行文件的读权限都要提前放好。我遇到过脚本在 root 终端正常、面板定时任务一直报 Permission denied，最后发现是 www 用户对 /data/backup 没有写权限，chown 给 www 之后立刻恢复。

4.3 与 find、crontab 组合：保留最近 N 份备份

归档文件越积越多，手动清理不现实。把 crontab 与 find 组合起来，保留最近 30 天，更早的自动删除。我的习惯是把删除动作和备份动作分开，两个定时任务之间留出足够间隔，避免备份还没生成完就被清掉。

# 每天 2 点执行备份脚本，凌晨 4 点半清理过期文件 0 2 * * * /usr/local/scripts/backup_app.sh 30 4 * * * find /data/backup -maxdepth 1 -name 'app_*.rar' -mtime +30 -delete

find 的 -maxdepth 1 防止递归扫描子目录；-mtime +30 按修改时间过滤，超过 30 天的文件才会被删除。如果你不想让清理行为不可逆，把 -delete 换成 mv 到 /data/backup/archive 再定期处理，相当于多留一道后悔药。结合前面的 rar t 校验，可以认为磁盘上的每个备份包都是经过验证的，清理流程才敢放心跑。顺序记住一句话：先压缩、再校验、后清理，任何一步失败都停住，不自动进入下一步。

5. 避坑复盘：Linux 下 RAR 工具的四个典型翻车现场

这一章把我在不同服务器上实际遇到过的坑逐一拆开，每条按现象、原因、解决的顺序写，方便对照排查。四个问题相互独立，但都容易和上面的部署步骤混在一起出现。

5.1 command not found：PATH 没刷进去

现象：装完执行 rar 提示 rar: command not found，但切到 /opt/rar 目录用 ./rar 又能跑。

原因：二进制可能不在 PATH 覆盖的目录里，也可能是当前 shell 的 PATH 缓存还没刷新。cron 和 Web 面板里出现这个提示，则几乎一定是执行环境没有加载 profile 或 bashrc，而不是路径本身没设好。

解决：先用 which rar 或 ls /usr/local/bin/rar 确认文件在不在。文件存在但命令找不到，说明是 PATH 没生效，改用绝对路径调用最省心。我把 /usr/local/bin 和 /opt/rar 都写进 /etc/profile.d/，再在脚本里用 $RAR 变量，双保险之后 command not found 就很少出现了。

5.2 Exec format error：x64 包装到了 ARM 服务器

现象：执行 rar 时提示 bash: /usr/local/bin/rar: cannot execute binary file: Exec format error，文件明明存在，权限也是 755。

原因：标题里写着 x64，对应的是 x86_64 指令集。ARM 服务器、苹果 M 系列云主机上跑 x64 二进制，内核直接拒绝加载，跟文件权限无关。

解决：先 uname -m 确认架构，再下载匹配的版本。用 file 命令验证一下是最稳的：

file /usr/local/bin/rar # 期望输出 ELF 64-bit LSB executable, x86-64 ...

我在一台 ARM 云主机上硬装过 x64 包，折腾半小时才发现方向错了。从那以后，拿到任何二进制，我都会先跑 file 确认格式，再考虑怎么部署。

5.3 中文文件名乱码：先看 l 的输出再决定怎么解

现象：rar x 解压后目录和文件名变成乱码，或者是一串问号，用 ls 看完全认不出。

原因：压缩包在 Windows 上生成时，文件名用的是本地编码，比如 GBK，Linux 侧按 UTF-8 解码就错位。RAR 6.x 版本对编码的兼容性好了一些，但老包、第三方工具打的包仍然很容易踩。

解决：解压前先 rar l 看看包内文件名在终端是否正常。如果 l 阶段就乱码，说明是源包编码问题，解压后用 convmv 转码文件名：

# 发行版先安装 convmv，再对解压后的目录做文件名转码 convmv -f gbk -t utf8 --notest /data/restore/

注意是转文件名，不是转文件内容，千万别对文件内容做同样操作。乱码目录里文件多了之后，手工 mv 会非常累，convmv 一条命令就能把整个目录树的文件名重写掉。这个经验帮我处理过好几份 Windows 交付物，价值很高。

5.4 unrar-free 冒充 unrar：只能解不能压

现象：执行 unrar a archive.rar dir 时报 unknown option，或者说不支持该操作，但解压却能正常用。

原因：系统发行版自带的 unrar-free 只是 RAR 读取器，功能被裁剪到只能解压，不支持 a、c 这类写入子命令。命令名字一样，能力完全是两个东西。

解决：在服务器上同时存在两套 unrar 时，我一般不会去卸载系统包，而是统一用 rar 前缀调用完整版。脚本里写 /usr/local/bin/rar a，从不用 unrar 去压缩，这样系统里的 unrar-free 是什么版本都不会被误用。如果你确认 unrar 指向的是本包拷过去的二进制，那它也是完整版；但为了消除歧义，全路径 rar 是最省心的写法，也方便团队其他成员接手时一眼看懂。

6. 验证与排错：陌生 RAR 也值得先过一遍 rar t 再解压

收到一份几十 GB 的交付 RAR，第一反应直接 x 解压，很容易在十分钟后才发现有文件损坏。压缩包损坏不会在解压一开始就全部暴露，而是解到某个文件时才报 CRC 错误，前面花的时间全部白费。我的固定流程是三步：先 l 看内容、再 t 验完整性、最后 x 解压。脚本化之后大概是这样的：

#!/usr/bin/env bash set -euo pipefail ARCHIVE=/data/delivery/xxx.part01.rar OUTDIR=/data/extracted /usr/local/bin/rar l "$ARCHIVE" if /usr/local/bin/rar t "$ARCHIVE"; then /usr/local/bin/rar x -o- -y "$ARCHIVE" "$OUTDIR" else echo "integrity check failed: $ARCHIVE" exit 1 fi

rar l 先输出包内文件清单，看看路径和数据量是否符合预期；rar t 校验整个包，失败立即停住，任何文件都不落地；rar x 用 -o- 跳过已有文件，避免覆盖服务器上的同名文件，-y 自动应答所有确认提示。多卷包同样适用，把 part01 传给 l、t、x 即可，后续分卷会按序号自动续上。

这套流程还能顺便排查三类问题：密码错误时 t 阶段就会停下；分卷缺失时 t 阶段会报缺卷；文件名编码问题在 l 阶段就能发现。相比直接解压，多花的时间只是先跑一遍 CRC，对几十 GB 的包也就几分钟。我在处理数据库逻辑备份、外部交付包时，几乎每份都强制走这个流程。

解压完成后，我会再抽查两个关键文件的 md5，和交付方发来的校验值比对一下，确认磁盘层面没有静默损坏。这一步是强迫自己在交付前做的，毕竟服务器上出了错，最后背锅的还是自己。从那以后我不管处理谁的 RAR 压缩包，都强制先走 rar l、rar t、rar x 这个顺序，已经养成肌肉记忆，几乎没再因为解压翻过车。希望帮到你。

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