企业官网建设流程全解析

如果你在一个 Linux 环境里干活超过五年，多半遇到过这种场面：有人抱着一台报废电脑的硬盘，或者从角落里翻出一张发黄的光盘，里面全是 .arj 文件。打开看一眼，系统自带的 unzip 不认识，tar 更不搭理，甚至连图形界面的解压工具都拿它没办法。而这个场景，我在帮朋友恢复旧数据时至少经历过三次。这时候最靠谱的办法，就是找一个专门的命令行工具 unarj，老老实实把数据刨出来。

.arj 是九十年代红极一时的压缩格式，到今天已经算得上古董。这篇内容不绕圈子，直接讲清楚：为什么现在还会碰见它、在 Linux 上怎么把 unarj 装起来、它的常用参数怎么用，以及真正解压老归档时那些文档里根本不会写的坑。不管你是偶尔需要处理历史数据的开发，还是长期维护旧系统的运维，应该都能从我这些实操记录里找到可以直接“抄作业”的命令。

1. 为什么今天还要跟 unarj 打交道

1.1 ARJ 格式的前世今生

ARJ 这个格式诞生于上世纪 90 年代初，作者是 Robert K. Jung。那个年代压缩软件属于群雄混战，ZIP、ARI、RAR、LHA 各有各的用户，而 ARJ 硬生生在 ZIP 的阴影下抢下一大块市场，靠的就是两样东西：压缩比和分卷能力。当年一张软盘 1.44MB，一个大文件动辄几 MB，ARJ 的分卷压缩功能可以直接把数据切成 a.arj、a.a01、a.a02 这样的体积，拷满一张盘就换下一张，对那个时代的人来说简直是救命功能。

而且 ARJ 是共享软件，用起来也简单，一条命令行就能完成压缩、分卷、加密、自解压等一系列操作。对比当时的 WinZip，ARJ 在批处理里调用的时候灵活得多，很多单位内部的备份脚本都直接基于 ARJ，这也是为什么 90 年代的工程资料、财务数据、图纸档案里极其常见 .arj 文件。

后来 Windows 图形界面普及，压缩软件也开始变成鼠标点一点的操作方式，ARJ 那种纯命令行的交互模式渐渐失去市场。加上 RAR、7z 后来居上，ARJ 从 2000 年前后基本就停止了主流更新，现在只剩少数怀旧工具还在兼容它。但注意，“停止更新”和“数据消失”是两回事——当年那批单位的备份光盘、软盘、磁带，至今还躺在仓库里，里面的 .arj 文件不会因为格式过气就自动消失。

1.2 现实中会在哪些地方遇到 .arj 文件

讲一个我自己的例子。有一次接手一个很老的项目资料迁移，客户从仓库里翻出几箱 CD，里面是九十年代末的扫描图纸，每张图都压缩成了 .arj 分卷，还带密码。当时接手的管理员换了好几茬，所有人都知道这批资料很重要，但没人知道怎么把它打开。我折腾了一个下午，最后用 unarj 配合官方 ARJ 工具把数据完整捞了出来。

类似场景并不少见，常见的有这么几类：

• 单位早年用 ARJ 命令做的系统备份，刻在光盘或存进磁带，后来备份软件换了，归档没换。
• 从老工业设备、检测仪器、行业软件里导出的历史数据，固件开发商当年就是把导出格式定义成 arj。
• 个人用户从旧硬盘、老镜像、校友 FTP 上翻出来的共享软件、电子书、扫描杂志，很多也是 arj。
• 车机、工控机、嵌入式设备的出厂升级包，偶尔能看到 arj，因为那套流程是从 DOS 时代一直沿用下来的。

这些事情有一个共同点：你平时根本不需要 .arj，但一旦需要，可能就是唯一备档。手里没有趁手工具，数据就永远躺在那里。

1.3 unarj 和 ARJ 官方工具的区别

很多人在网上搜“unarj”会一脸懵：它到底是官方软件还是一个山寨工具？准确说，unarj 是一个独立开发的开源兼容工具，专门用来解压 ARJ 格式。官方 ARJ 软件当年确实也提供过 Unix 版本，但 Linux 生态里的打包维护早就停掉了，发行版软件源里基本找不到官方二进制。

而 unarj 保留了 ARJ 命令行工具的核心体验，但不包含压缩功能，只负责解压和查看归档。它的好处非常直接：体积小、依赖少、行为稳定，而且大多数发行版的软件仓库里都有。无论是 CentOS 还是 Debian，一条包管理命令拉下来直接能用，完全不需要你去折腾老掉牙的共享软件注册码。

另外，官方 ARJ 在很多 Linux 发行版里已经无法编译，除非你专门去跑一个 DOS 模拟器，否则在纯 Linux 环境下，unarj 就是处理 .arj 最顺手的入口。

2. 先把 unarj 装到 Linux 上

2.1 Debian/Ubuntu 系安装方式

在 Debian 和 Ubuntu 上安装最好记，直接：

sudo apt install arj

注意，包名是 arj，不是 unarj。装完之后你会发现 /usr/bin 下面多了 arj、unarj、lsarj 三个命令。实际上 Debian 的 arj 包把这些二进制都打进去了，unarj 就在里面，直接用即可。记住这个细节可以少走挺多弯路，我第一次也以为要单独装一个叫 unarj 的包，结果 apt 搜索出来的东西乱七八糟。

Ubuntu 的系统版本如果比较老，可能在默认软件源里也能找到，但如果你用的是最新 LTS 版，直接 apt 安装包名，装不上再走源码编译路线。

2.2 Red Hat 系、Arch 和国产发行版

CentOS / RHEL / Fedora 这一系，建议先启用 EPEL 仓库，然后尝试：

sudo yum install unarj

不同源的打包情况不太一样，如果提示找不到包，也别硬搜，直接换源码编译方案就行。Arch Linux 用户就简单了，AUR 里直接搜 unarj，用 yay 或者 paru 拉下来安装即可。另外一些国产系统，比如基于 Debian 或 CentOS 的本地化发行版，通常也能用对应的包管理工具装上，只是包名可能略有不同，先search unarj和search arj各试一遍，基本能定位。

2.3 源码编译也不难

软件源没有包的时候，源码编译是兜底方案。unarj 的源码在 SourceForge 上有个老项目，也在 GitHub 上有民间维护版本，下载 tar 包之后步骤非常简单：

tar xzf unarj*.tar.gz cd unarj* ./configure make sudo make install

这个工具的代码量很小，编译过程一般十几秒就完成，基本不会缺依赖，因为它的核心就是用标准 C 写的。如果你的 Linux 环境连 gcc 都没装，那就得先处理基础编译环境，比如 Debian 系sudo apt install build-essential，CentOS 系sudo dnf groupinstall "Development Tools"。

需要提醒一下，源码包可能来自多年没更新的老项目，编译时偶尔会遇到小瑕疵，比如 Makefile 里的某些变量过时。遇到这种问题别慌，直接打开 Makefile 手工调整一下编译选项，或者选择 GitHub 上活跃维护的分支，一般都能顺利通过。

2.4 装完先验证环境

安装完成之后，在命令行敲一个unarj，不带参数。正常情况下会打印出简短的用法说明，列出支持的选项。看到这些输出，就说明命令已经能用了。

如果敲进去显示 command not found，先确认安装是否成功：

which unarj

在 Debian 系如果安装的是 arj 包，通常会在 /usr/bin/unarj 有一个硬链接或单独二进制。某些发行版可能把可执行文件放在 /usr/local/bin，手动编译的时候尤其容易忽略这一点，导致 shell 路径没找到。这时候要么把路径补进 PATH，要么直接 ln -s 做软链。

3. 命令拆解：列档、解压、测试

3.1 最常用的三个动作

unarj 的命令格式非常规矩，基本是“工具 + 参数 + 归档文件”。日常用最多的是下面三条：

unarj l archive.arj unarj x archive.arj unarj t archive.arj

• l（list）是列档，查看压缩包内部有哪些文件，但不解压。这一步务必养成习惯，先看再动手，能避免很多不必要的麻烦。
• x（extract）是真正解压，并且会重建归档里记录的子目录结构。
• t（test）是测试完整性，遍历整个归档并校验 CRC 校验值，不生成实际文件。

其中t参数在网上很多教程里被一笔带过，但实际处理老数据时它的价值非常高。解压之前先测试一遍，可以提前发现哪个卷有损坏、哪个文件不完整，避免解压到一半才发现数据不对，到时候还得返工。

3.2 x 和 e 的选择，是解压经验的分水岭

这里必须好好唠唠 x 和 e 的区别，因为踩坑的人实在太多。unarj 的x会保留归档内的路径结构，比如归档内部记录的是docs/2024/plan.doc，解压后就会真的生成 docs/2024 两层目录。而e参数会把所有文件直接平铺到当前目录，忽略内部路径。

听起来好像 e 更方便，但实际用起来很危险。如果归档内部有两个不同目录下的同名文件，比如a/data.txt和b/data.txt，用 e 解压时后解出来的那个会直接覆盖先解出来的那个，数据就这么悄无声息丢了。这种问题在年代久远、文件管理混乱的老归档里不是小概率事件，我见过不止一次，当事人最后只能对着缺失的文件发愁。

所以我的建议是：日常操作一律用 x，除非你能确认归档内没有重名文件。善用 x，才是对数据负责的做法。

3.3 测试与列档输出怎么看

执行unarj l之后，输出大致是一个文件清单，包含文件名、原始大小、压缩后大小、压缩率和时间戳。看这个清单的时候，重点留意两个地方。

第一是文件名的结尾。如果归档里带目录结构，会有以/结尾的条目；如果你发现列出来的路径全是类似docs\2024\plan.doc这样的反斜杠，说明这个归档是 DOS/Windows 时代生成的，unarj 在解压时一般会帮你转换，但某些旧版本未必处理得干净，这时候解压完可能要手动修正路径。

第二是原始大小和压缩后大小的对比。如果所有文件压缩率都异常低，比如原始大小和压缩后大小几乎一样，那说不定归档本身就是存储模式打包的，也可能是数据原本就是不可压缩的格式（比如 JPEG 图像、视频）。不要看到压缩率小就以为文件损坏。

3.4 只想解压归档里的某几个文件

有时候拿到一个大归档，只需要里面几个文件，不必全解。unarj 支持指定文件名：

unarj x archive.arj docs/plan.doc image/001.jpg

也可以使用通配符批量提取：

unarj x archive.arj *.doc

注意，在通配符匹配时，尽量把归档内部的实际路径搞清楚再做筛选。尤其老归档里文件名可能有大小写混用、空格甚至特殊字符，建议先用l列档确认具体名称，再拿文件名去匹配，不然匹配不上就白白浪费时间。

4. 实操全过程：从一堆老归档里把数据挖出来

4.1 一次真实的恢复场景

说一次具体的恢复操作。当时拿到手的是一批从旧光盘里复制出来的 .arj 文件，共 12 个，体积从几十 KB 到几十 MB 不等，总数据量不大，但全部是核心工程图纸。我接手后的第一步不是直接解压，而是把它们先集中到一个独立目录里：

mkdir ~/arj_recover cp /mnt/cdrom/*.arj ~/arj_recover/ cd ~/arj_recover

接着全部测试一遍：

for f in *.arj; do echo "=== $f ===" unarj t "$f" done

测试结果发现有 2 个文件提示 CRC 错误，其中 1 个还比较严重。我没有跳过，而是把它们单独挑出来，再扫描齐全整套分卷，确认是不是缺了卷导致的问题。后来发现确实是缺两个 .a01 卷，从能找到的另一个备份盘里补齐后再次测试，CRC 错误消失，12 个归档全部顺利通过。

这里想强调一个习惯：先复制、再测试、后解压。直接在原光盘或者原盘符上操作，万一中途断电或者读取不稳定，就很可能破坏原始数据。老介质的读取本身就脆弱，多花两分钟复制一下能省下后面好几天的心力。

4.2 批量解压的脚本思路

如果归档很多，手动一个一个解压效率太低，可以写个简单的循环脚本：

for f in *.arj; do if unarj l "$f" > /dev/null 2>&1; then mkdir -p "extracted_${f%.arj}" cd "extracted_${f%.arj}" unarj x "../$f" cd .. else echo "bad archive: $f" fi done

这个脚本的核心逻辑很简单：先列档验证，如果通过再单独建目录存放解压结果。之所以每个归档都单独建目录，是为了避免不同归档里的同名文件互相覆盖——这个坑我在前面已经提到过，大概可以算是处理历史数据的头号警戒线。

有针对性的批量处理还能加一段英文转 UTF-8 的逻辑，见下文。

4.3 老归档里的中文文件名乱码处理

早年国内很多 DOS/Windows 系统在处理中文文件名时，用的是 GBK / GB2312 编码，而现代 Linux 终端默认是 UTF-8。直接解压之后，文件名经常变成一串乱码，比如鍏ㄥ浘.dwg这种没法看的东西。文件能打开，但文件名是一个灾难。

业界通用的处理方式是用 convmv 转换文件名编码。先安装 convmv：

sudo apt install convmv

然后对解压目录整体进行编码转换：

convmv -f gbk -t utf-8 --notest -r ./extracted

这条命令会把目录下所有 GBK 编码的文件名转换成 UTF-8。注意这里的--notest很关键，去掉它的话 convmv 默认只是预览转换结果，并不会真正执行。实际操作时我建议先不加--notest跑一遍预览，确认要改动的文件名清单没有异常，再加上--notest真正执行。

处理完文件名之后，还要留意文件内容里是否有 GBK 编码的文本。如果只是文件名乱码，convmv 就够用；如果需要处理内容，就要用 iconv 或者把文件导入支持 GBK 的编辑器再另存为 UTF-8。这个属于后续处理，跟文件名乱码是两个层面。

4.4 解压后的目录还有哪些修复要做

老归档解压出来之后，除了文件名，还可能遇到权限不对、时间戳不对、目录结构带反斜杠等问题。我用一个简单组合来收尾：

find ./extracted -type d -exec chmod 755 {} \; find ./extracted -type f -exec chmod 644 {} \; find ./extracted -name '*\*' -exec rename 's/\\/\//g' {} \;

第一条和第二条修复基础权限，避免后续文件不可读。第三条是把反斜杠路径修正为正常目录结构。并不是每个归档都需要，但一旦遇到，几十秒的操作能省去后面排查目录混乱的大量时间。

更细致的完整性校验是查看解压后的文件数量和数据大小是否和unarj l输出一致。如果发现文件数对不上，先复查测试结果，再决定是否需要重新解压。

5. 常见故障与踩坑实录

5.1 提示 CRC 错误或文件损坏

解压时最不想看到的就是 CRC error。出现这个情况，第一反应别慌，先分几种情况处理。

如果单个归档文件是从光盘复制的，可能是读取时产生了数据错误，重新拷贝一次往往就能解决。如果归档是多卷模式，CRC 错误很可能出现在某个后续卷，这时优先确认所有卷是否都在、文件名是否一致。ARJ 多卷命名的规律通常是主文件扩展名是 .arj，后续卷是 .a01、.a02、.a03 依次排下去，缺少其中任何一个卷，解压都会出错。

如果确定不是复制问题、也不缺卷，那就是归档本身已经损坏。唯一的补救办法是找其他备份，或者用官方 ARJ 工具尝试恢复，但不要抱太大希望，老数据的容错能力没你想象的强。对于真正重要的数据，平时多留一份备份才是硬道理。

5.2 多卷归档怎么合并处理

处理完老系统备份时，最常见的操作是先合并卷再解压。命令非常简单：

cat archive.arj archive.a01 archive.a02 > merged.arj unarj x merged.arj

合并之后的归档文件名不需要跟原来任何一卷同名，只要确保顺序无误即可。顺序特别重要，cat 必须严格按照 .arj、.a01、.a02 的顺序拼接，不能反着来，否则整个归档直接报废。

另外，合并操作之前建议先对每一卷算一下 md5，记录原始校验值，这样万一合并后出问题，可以快速定位是哪一卷异常。这种习惯在数据恢复场景里非常实用，要的就是能快速排查。

5.3 加密归档怎么办

ARJ 当年支持加密，所以老归档里偶尔碰到带密码的情况不稀奇。unarj 解压时如果遇到加密档案，通常会提示输入密码。正常情况下你知道密码，输入正确就能解。但老系统时代的密码策略经常是“谁设的谁知道，几年后谁都不知道”，这种时候就非常麻烦。

unarj 没有破解密码的能力，唯一的思路是借助密码恢复工具或者回想起当时的密码规律。常见密码可能是部门代号、项目编号、公司名字拼音，结合归档的年代背景多试几次。如果这一步走不通，数据基本就锁死了，这个责任不在工具，而在当年的管理流程。

比较稳妥的做法是，如果确认归档带密码，先试用通用压缩工具 7-Zip 打开一下，它兼容性不错，偶尔能比 unarj 更灵活地处理某些边界参数。如果 7-Zip 也解不开，那就老老实实走密码恢复的路子。

5.4 文件权限和时间戳丢失

unarj 解压出来的文件，时间戳和权限未必完全保留原始状态，因为 ARJ 格式本身记录的元数据和 Unix 权限模型差别很大。如果你的业务要求保留归档创建时间，务必在解压之前先用unarj l记录好归档内的时间戳，解压之后再用 touch 手动修复。

如果你解压后发现所有文件都是当前时间，别骂工具，老格式本来就没保存完整的 Unix 权限位和时间精度。这种场景下，把时间戳作为辅助参考就好，核心还是文件内容本身。

5.5 大文件的断点续传与重新解压

明明解压到一半失败了，第二次重新解压却发现提示文件已存在或者跳过。注意 unarj 没有自动断点续传能力，如果你需要重新解压，最好先清空旧输出目录，或者解压到一个全新目录。否则残留的半截文件可能干扰后续判断，甚至你误以为解压成功了，实际文件却是截断的。

我习惯的做法是提前在每个输出目录里建一个名为_done的标记文件，脚本全部跑完才创建。后面再次处理时先检查标记文件是否存在，存在就直接跳过，这样既避免重名覆盖，也能快速看出哪些归档真正处理完了。

6. 关于 unarj 的一些个人建议

嗯，作为一个不太“现代”的工具，unarj 身上有种强烈的时代痕迹：没有花哨参数，没有彩色输出，没有进度条，甚至有些版本连通配符规则都不太友好。但恰恰是这种简单，让它成了恢复老归档时的可靠伙伴。我用它处理过几次价值挺高的数据迁移项目，每次都是“一包一命令，跑了就完事”，没有多余的操作面，也就没有多余的出错面。

如果你想长期跟历史数据打交道，我建议把 unarj 和 7-Zip 配合使用，前者解决纯 ARJ 场景，后者兜底处理各种加密和特殊变体。同时把 convmv 和 md5sum 加进常用工具箱，遇到老编码和完整性验证的时候，这三个工具组合起来威力很大。

最后分享一个我个人的操作习惯：拿到一批老归档，不管多急，第一步永远是做一份副本，然后验完整、列清单、再解压。按这个顺序走，能把出问题的概率降到最低。数据恢复这种事，最怕的不是麻烦，而是本来能救的数据因为手忙脚乱而彻底丢掉。如果你也遇到过类似的老归档，欢迎按这套流程试一次，大概率能稳稳地把数据捞出来。