adt75.rar解压与密码恢复全指南：从测包到救回数据

简介：一份面向 ADT75 数字温度传感器的 C 语言驱动源码压缩包，专供嵌入式开发者、Linux 驱动开发人员及温度监控项目实践者参考。ADT75 是 ADI 公司的高精度数字温度传感器，广泛用于工业自动化、环境监测与设备散热控制；这份源码能够帮助读者掌握传感器与主控之间的 I²C/SPI 通信流程、温度数据的读取与换算方法，并能指导实际项目中的快速集成。压缩包为 rar 格式，内部仅 1 个 C 语言源文件，大小约 3KB，代码精炼、结构清晰，便于直接阅读和移植。驱动中涵盖初始化配置、数据采集、二进制到实际温度值的转换、通信异常处理以及必要校准等核心模块，同时展现了 Linux 内核驱动与用户空间程序的协作方式，可视为一套完整且便于扩展的传感器驱动示例。目前已有 87 人浏览学习，适合需要快速在 Linux 或嵌入式系统中对接 ADT75、实现温度监测功能的开发者下载借鉴。

1. adt75.rar_adt75：包名里那点信息，和拿到包后该做的事

adt75.rar_adt75是下载站和网盘转存里很常见的命名格式：点号前是真正的压缩包文件名，下划线后是解压后能看到的内层目录名。也就是说，这个包大概率会解出一个叫adt75的文件夹，里面是程序、数据集还是工程源码，光看名字谁都说不准——rar 只负责打包，不负责告诉你包的真面目。

点进这个标题的人，处境通常就四种：解压成功但不知道里面能不能用；解到一半报错；发现包带密码；或者一运行就出幺蛾子。这篇文章按这个顺序写：先把adt75.rar的测包和解压跑通，再处理损坏和假包，然后讲清密码恢复的边界，最后给一组能反复用的验包脚本。适合手里正攥着这个包、或经常在 Windows 和服务器之间倒腾 rar 压缩包的人。

2. 把 adt75.rar 解出来：三条命令路线与参数对照

解压 rar 前后，真正花时间的不是解压本身，而是确认三件事：包没坏、参数没选错、解出来的东西没被动过手脚。下面这套流程我在本地和服务器上都跑过，顺序是先测包、再解压、最后列内容核对，它能把后面章节里一大半的坑提前挡在门外。

2.1 先测包再解压：用 t 参数给自己留点后悔药

很多人拿到adt75.rar的第一步就是双击或直接unrar x，解到一半报CRC failed才知道包是坏的，前面时间全白搭。正确顺序是先测包。unrar的t参数会把包内每个文件解压到内存里，和包内记录的 CRC 值逐文件比对，但不真正写出文件，所以比完整解压快得多：

# 测试 rar 包完整性，只校验不落盘 unrar t adt75.rar

如果每一行末尾都是OK，最后出现All OK，这个包才能进解压环节。看到CRC failed、Unexpected end of archive这类输出，说明包已损坏或下载不完整，这时候回去重下一次，比硬解有价值得多。

不过要提醒一句：Linux 发行版默认不一定带 unrar。它用的是专有解压实现，很多发行版把它放在非自由软件仓库里，装起来要多一步。装不上时退到 7-Zip 就行，同样是逐文件 CRC 校验，只是输出格式不同：

# 没有 unrar 时用 7-Zip 测包，效果等价 7z t -y adt75.rar

-y让所有询问自动回答 yes，适合脚本里跑；手动测包时不写也行。7z 对 rar5 格式的支持通常比系统自带的旧版 unrar 更全，所以一旦在测包阶段遇到Unsupported method这类怪错，直接把工具换成 7z 往往是最快的解法，而不是去折腾 unrar 版本。

2.2 三条解压命令，按平台和场景选一条

测包通过后，解压命令的选择取决于平台。我在 Linux 服务器上用 unrar，在 Windows 上处理老包反而更常用 7-Zip——中文文件名兼容更好，macOS 或 BSD 上则用 bsdtar 兜底。三条路线的对照关系先放这里：

先看场景 A：如果你要完整保留包内目录结构，把文件原样解到当前目录，用 unrar 的x参数：

# 场景 A：保留目录结构，同名文件直接覆盖 unrar x -o+ -y adt75.rar

x是"用完整路径解压"。新手常把x和e搞混：unrar e会把所有文件拍平到同一个目录，子目录结构全部丢失，对小工程包可能无所谓，对带多层目录的数据包就是灾难。-o+表示同名文件直接覆盖，-y跳过交互提问。如果不想覆盖而是保留旧文件，把-o+换成-o-，但手动操作时-o-容易卡在询问上，所以脚本里我固定用-o+更省心。

再看场景 B：Windows 上用 WinRAR 压出来的包，往往带中文和空格文件名，这类包在 Linux 老版本 unrar 下容易出乱码，用 7z 处理更稳：

# 场景 B：解到指定输出目录，中文文件名用 7z 更可靠 7z x -y -o./adt75_out adt75.rar

注意-o与目录之间不能有空格，写成-o./adt75_out而不是-o ./adt75_out——这是 7-Zip 命令解析里最常见的翻车点。7z 会自动创建adt75_out目录，解完后内层那个adt75文件夹会出现在./adt75_out/adt75下。

最后是 BSD/macOS 场景，系统自带的 bsdtar 走 libarchive，对 rar5 的兼容性也不错：

# 场景 C：BSD/macOS 用系统自带 bsdtar mkdir -p adt75_out bsdtar -xf adt75.rar -C adt75_out

-C指定解压目标目录，但它不会自动创建目录，必须先用mkdir -p保证目录存在。bsdtar 如果报Unsupported compression一类错误，说明这个包的压缩特性它不认，回到 7z 路线即可。

补充一个 Linux 上常被忽略的细节：unrar 在 Unix 系系统上会尝试还原文件的权限位，而 7z 默认不还原。如果包里的脚本解出来后没有执行权限，别奇怪，那是工具差异；对需要运行的脚本或二进制，先ls -l看一眼权限，再决定要不要chmod +x。

2.3 解压不是终点：列内容、核对校验和

解压完先别急着跑程序，用l参数把包内清单拉出来看一遍。这一步花不了几秒，却能过滤掉后面很大一部分坑：

# 列出包内文件与目录结构，不解压 unrar l adt75.rar

输出里除了文件路径，还有原始大小、压缩后大小、CRC 和修改日期。我的习惯是重点看两样东西：一是总大小和文件数量是否和下载页描述一致，二是目录里有没有混进奇怪的可执行文件。一个声称是数据包的 rar 里如果躺着几 MB 的setup.exe，或者出现激活工具.exe、注册机.exe这类文件名，先警惕起来，3.3 节专门讲这种情况。

如果adt75.rar是从论坛或网盘下的，发布者通常会给 SHA-256 或 MD5，拿到后立刻核：

# 核对文件哈希，确认下载过程没有被窜改 sha256sum adt75.rar

这里要区分两个概念：unrar t验证的是压缩包内部数据是否自洽，sha256sum验证的是你拿到的文件与发布者发布的文件是否一致。两者缺一个，都可能让一个被替换过的坏包一路混到生产环境里，等到跑起来才发现不对，那时候代价就大了。如果发布者没给哈希，就用unrar t作为唯一依据，至少能确认文件本身没在传输过程中损坏。

3. 解压报错不是网线问题：先读报错再动手

报错信息是压缩包给的最直接线索，但多数人拿到报错的第一反应是重下一次或换个工具乱试。我见过的绝大多数解压翻车，其实都能从报错原文里定位到原因。下面三类报错差不多占了日常的九成，学会读它们，比换个工具瞎试有用得多。

3.1 三类高频报错，先分清再决定方案

第一类是文件级 CRC 报错。不管是用 unrar 还是 7z，看到CRC failed in adt75/data/table.dat或Data Error in ... File is broken这类输出，含义很明确：包内这一个文件的数据解出来和它记录的 CRC 对不上，文件坏了。但要注意，rar 的 CRC 是按文件分别记录的，所以一个文件报错不代表整个包都废了，其他文件大概率还能正常解出。

第二类是Unexpected end of archive。这个报错的意思是压缩包的实际长度比头部声明要短，最常见的原因是下载不完整，或者多卷分卷丢了一个卷。它和 CRC 报错的本质区别是：CRC 报错是"数据在但内容不对"，end of archive 是"数据根本没到齐"。

第三类是Cannot open adt75/xxx: No such file or directory，往往还伴随文件名乱码。这个报错和损坏无关，原因基本是工具版本太老、对 rar5 的 Unicode 文件名支持不到位，把 UTF-8 文件名按本地编码解析导致路径对不上。三类报错的应对方向完全不同，所以先读报错再动手，别上来就重下。

3.2 损坏包的抢救顺序：修复记录、重下、最后才强制解压

如果unrar t已经确认包损坏，先别急着用各种修复工具，按下面这个顺序走，大部分情况下能保住能保住的部分。

首先看打包者有没有留下恢复记录。WinRAR 打包时有个"添加恢复记录"的选项，常见的是 rr3% 或 rr5%，意思是额外写入包体积 3% 或 5% 的冗余数据，用于修复少量损坏。有恢复记录时，unrar repair才能派上用场：

# 重建可修复的 rar 包，产物为 adt75_fixed.rar unrar repair adt75.rar

如果原包制作时没勾恢复记录，repair 会直接告诉你No recovery records found，这一步就到此为止。市面上的 rar 修复工具，包括那些带 GUI 的，本质都是"能解多少解多少、把可读部分重组"，并没有凭空补回损坏字节的能力，别在工具上耗时间。

没有恢复记录时，退而求其次是抢救可解出的部分。unrar 的-kb参数会在遇到坏文件时保留已经解出来的那一部分，不直接中断：

# -kb：遇错不中断，保留已解出的部分文件 unrar x -kb adt75.rar

需要说明，-kb解出的坏文件可能是残缺的，用之前必须确认用途。对数据包来说，我的原则是：只有adt75.rar来源已经找不到、或者重下成本极高时，才用-kb抢救局部数据；能重下就重下，然后用sha256sum核对，这永远是第一选择。

最后一个选项是让 7z 去解。7z 的 rar 解压容错比老版 unrar 略好，遇到坏块时经常能把坏块前后的文件都吐出来，输出里照样标注Data Error，但对"至少拿到大部分文件"这个目标来说已经够用。记住，无论哪个工具救出来的文件，都要视为"半血"状态，跑数据任务前必须做完整性抽查。

3.3 假 RAR 与广告子程序：先体检再放行

搜索"rar用来加载广告的子程序"这个关键词的人，遇到的基本就是这一类包：正常内容是真的，但打包者在里面塞了一个广告加载器，文件名通常起得特别像正经理由——"说明.txt.exe"、"破解补丁.exe"、"一键安装.exe"。这类包在技术含量上是最低的，危害却是最大的。

先说不解压就能做的体检。7z 的l参数带-slt时，会输出每个文件的详细属性，包括大小、压缩后大小、属性和 CRC：

# 不解压直接看包内每个文件的详细信息 7z l -slt adt75.rar

看输出时我关注三点：文件大小和下载页描述是否对得上；目录里有没有不该出现的可执行文件；有没有刻意伪装的双扩展名（xxx.txt.exe这种）。任何一个点异常，先别解压，回到来源页重新确认。

如果已经解压了，在双击任何 exe 之前，用file命令看一眼真实类型：

# 识别可疑文件的实际类型，别被文件名骗了 file adt75/激活工具.exe

正常出 果是PE32 executable这类说明这是 Windows 程序；如果文件名伪装成文档、实际却是一个可执行文件，基本可以断定有猫腻。最坏的习惯是在压缩包管理器里直接双击预览或运行——工具会把文件释放到临时目录执行，你连它落在哪都不知道，出了事都无从排查。宁可先解压到固定目录，再逐个检查。

提示：包里出现"注册机、激活补丁、破解工具"这类可执行文件时，默认先当可疑处理。要么放虚拟机里跑，要么直接删掉只留数据文件。为省这几分钟的验证时间，把一台机器搞到弹窗全家桶，是我见过最不划算的买卖。

4. 带密码的 adt75.rar：哪些能恢复，哪些趁早死心

拿到一个带密码的adt75.rar，第一反应基本是搜"rar密码移除"。在动手之前，先要把一个事实讲清楚：rar 的加密机制没有后门，密码不是一股脑写在文件头里的，而是经过反复迭代推导出密钥再对数据加密。你在搜索框里敲"rar密码移除"时，那些工具能做的，要么是猜出密码后用密码解压，要么干脆是骗你安装广告程序。搞清楚这个边界，后面才不会浪费时间。

4.1 先确认加密模式：文件名变成星号不等于包坏了

在决定跑密码恢复之前，先用列目录命令确认加密类型，这一步很多人都跳过，结果拿着修复工具去修"全是星号的包"，南辕北辙：

# 列出包内文件，观察文件名是否被加密 unrar l adt75.rar

如果输出里的文件名全部是*号，说明打包时勾选了"加密文件名"。rar 的加密分两种模式：一种是只加密文件数据，解压时输密码，但文件名字还能看到；另一种是连文件名一起加密，unrar l下只能看到一堆星号，不知道里面装的是什么。后者通常更严，因为你连"值不值得跑"都判断不了。

顺便澄清一个常见误传：并不存在"只隐藏文件名、不加密数据"的模式。文件名一加密，数据必然也是加密的，想绕过去？不存在。如果你的目标是先看内容，这种包只能先恢复密码，没有第二条路。

4.2 用 rar2john 转哈希，再用字典和掩码攻击找回密码

真正可行、且工具链开源的路线是：先用rar2john把包里的加密参数提取成哈希串，再用 John the Ripper 或 hashcat 离线猜测密码。这个路线对包的格式版本、加密强度都有明确反馈，比那些界面花哨的破解软件透明得多，也更容易判断"到底还有没有戏"。

# 从 rar 中提取密码验证哈希（只适用于自己所有或有授权的包） rar2john adt75.rar > adt75.hash cat adt75.hash

rar2john是 John the Ripper 工具包里的脚本，它解析 rar 头部的加密迭代参数，输出 john 和 hashcat 都能识别的格式。为什么要把加密参数抽出来单独跑？因为 rar 的密钥推导有数万次迭代——RAR3 用的是 SHA-1 迭代约六万五千次，RAR5 用 PBKDF2-HMAC-SHA256，迭代三万两千多次——在压缩包上直接试密码，每次尝试都要完整走一遍迭代，慢到不可用。抽成哈希后，hashcat 可以在 GPU 上并行跑，速度能快一个量级。

先用 john 跑字典，适合密码是常见词的场景：

# 用公开字典跑常见弱密码 john --wordlist=/usr/share/wordlists/rockyou.txt adt75.hash john --show adt75.hash

rockyou.txt是渗透测试发行版里常见的公开字典，里面收集了过去泄露的真实密码，几百万条量级。--show在跑完后重新列出已破解的结果，不用再等它输出。但字典攻击有个盲区：密码只要不是字典里的词，你跑一万条也是空转。

所以第二招是掩码攻击，适合你隐约记得密码模式的情况，比如"应该是 6 到 8 位纯数字"：

# 8 位纯数字掩码穷举，GPU 下几十分钟到几小时可见结果 hashcat -m 12500 -a 3 -w 3 adt75.hash '?d?d?d?d?d?d?d?d'

-m 12500对应 RAR3 的哈希类型，RAR5 打包的用-m 23700，具体以hashcat --example-hashes输出为准；-a 3是掩码模式，?d代表数字占位符，8 个?d就是 00000000 到 99999999。-w 3是性能档位，跑的时候机器会明显变卡，这是正常的。

但要说句实话：掩码攻击只对短密码和规则密码有效。随机大小写加数字加符号的 8 位以上密码，穷举空间是天文数字，GPU 也救不了你。遇到这种，我一般直接放弃这个包，回头找原始来源重新下载，或者联系打包者要密码——这比烧一周电费去跑字典划算得多。

注意：这套流程只适用于你自己的包、或你明确获得授权测试的包。拿别人的压缩包跑字典，很多场景下既不合适也可能带来合规风险，这个边界自己把握。

4.3 别碰"注册机版密码恢复工具"：广告子程序的又一重灾区

搜索页常年挂着 "advanced rar password recovery" 和 "rar recovery toolbox破解版" 这类词。Advanced RAR Password Recovery 本身是正经的 GUI 工具，界面友好，但完整功能要付费，免费版通常只演示低复杂度密码，很容易给你一种"马上就能破"的错觉，真跑起复杂密码就卡住不动。

问题出在破解版上。这类工具的"破解版"安装包，和 3.3 节说的广告加载器是同一个路数：装完之后密码没找回，先收获一堆弹窗和全家桶。我在虚拟机里专门看过两个这类安装包的行为，无一例外都在往启动项里写东西。更要命的是，它会让你误以为"工具不行"，其实从第一步起就已经被引流到广告链路里了。

至于那些声称"在线秒破 rar 密码"的网页，基本只有两种结局：骗你把包传上去然后要钱，或者诱导你下载一个带广告的客户端。rar 的加密迭代设计就是为了防止秒破，一个网页几秒钟就能算出密码，这本身就违背密码学常识。

要选的话，我只走rar2john加 hashcat 这条开源路线。它没有 GUI 可看，但每一步都透明：哈希提取成功就是成功，跑不动就是跑不动，失败也失败得明明白白，不会给你塞广告子程序。代价只是需要习惯命令行，换来的是整个流程可信、可控。

5. 常见问题避坑：五条能复现的一线踩坑记录

这一章是我处理 rar 压缩包时反复遇见的真实问题，每一条都按"现象、原因、解决"写清楚，你可以直接对照自己的情况，省得再从零摸一遍。

5.1 现象：解到 30% 报 CRC failed，前面的文件却能正常打开

原因：rar 的 CRC 是按文件记录的，某个文件损坏不会拖累其他文件。常见诱因是下载工具断点续传没做校验、网盘中转文件被截断，或者本地磁盘坏道读到坏块。前面文件能正常用，不代表坏文件也能用，这是个容易误判的点。

解决：先用sha256sum核对整体哈希，不一致就重下。急着用某个文件，就用unrar x -kb保留已解出的部分，把坏文件单独标记出来找替代来源。记住-kb解出的坏文件可能残缺，拿去做任务前必须验证内容，别因为"能打开"就默认它是对的。

5.2 现象：unrar l 列出的文件名全是星号

原因：打包者勾选了"加密文件名"，这是 rar 的加密文件头模式，不是包损坏，也不是显示 bug。用修复工具去修它，永远不会有效果。

解决：先试几个常见弱密码，unrar x -p123456 adt75.rar这类命令可以一次试一个；不行就走第 4 章的 hashcat 路线。如果密码是随机长密码，基本可以放弃这个包，去源头重新找。这类包最大的问题是连里面装的什么都看不见，连"值不值得跑"都很难判断。

5.3 现象：Windows 上能解，Linux 上 unrar 报 No such file

原因：同一个包，WinRAR 能秒解，Linux 命令行 unrar 却报Cannot open ... No such file or directory，文件名乱码。原因是老版本 unrar 对 rar5 的 Unicode 文件名支持不到位，把 UTF-8 文件名按本地编码去解析，路径对不上自然打不开。

解决：升级 unrar 到 6.x，或者直接用7z x处理这类包，几乎不会遇到编码问题。如果已经用旧工具解出了乱码文件，可以事后补救：convmv -f GBK -t UTF-8 --notest -r adt75/批量把文件名转回 UTF-8。但这是救火，不如一开始就用 7z 省心。

5.4 现象：解出一个"激活工具"，双击后弹广告装全家桶

原因：压缩包作者把广告加载器伪装成工具塞进包，文件名起得特别有吸引力——"注册机"、"激活补丁"、"一键破解"。双击那一刻，它先把广告子程序写进启动项，再顺手放个假的"未激活"提示，让你以为只是工具失效。

解决：第一步永远是先体检再运行，用file看类型、看数字签名、看文件大小、对比下载页描述。必须运行就放虚拟机或沙箱里，别拿主力机器试。遇到弹广告的包，删掉对应 exe 只留数据文件，保留原包和来源截图，能找到替代源就绕开。

5.5 现象：哈希校验通过，换台机器解压却又失败

原因：文件在两个机器上sha256sum一致，但 B 机器解压报 CRC failed 或解出的文件和对不上。通常两种情况：一是 A 机器内存不稳或磁盘有坏道，解压时读到错误数据，但哈希验证恰好发生在文件落盘前，掩盖了问题；二是 B 机器上的解压工具版本太老，不认 rar5 的新压缩特性，解出来的字节对不上。

解决：先在 B 机器重新跑一次sha256sum，确认本地文件没被坏道改掉。哈希一致却解压失败，就是工具差异，升级到 7-Zip 21+ 或 unrar 6.x 再试。还不行就换一台内存可靠的机器重解，内存故障是这种"薛定谔式损坏"的隐藏元凶，工具链和硬件各排查一遍，才能定位到真正的问题。

6. 用一条脚本把验包、解压、复核串起来

与其每次手动敲五条命令，不如把流程固化成脚本，参数固定，避免手滑。下面这条是我处理adt75.rar这类包的最小模板，保存为unpack.sh后加执行位就能用：

#!/usr/bin/env bash # 用法: ./unpack.sh <rar文件> <输出目录> set -euo pipefail RAR_FILE="${1:?需要一个 rar 文件}" OUT_DIR="${2:?需要一个输出目录}" # 1. 测包，失败立即退出 7z t -y "$RAR_FILE" # 2. 解压到独立目录（覆盖同名文件） 7z x -y "-o${OUT_DIR}" "$RAR_FILE" # 3. 复核：列出解出的前 50 个文件与大小 find "$OUT_DIR" -type f -printf '%p\t%s bytes\n' | head -50

set -euo pipefail三个开关的作用分别是：任何命令失败就退出、变量未定义即报错、管道中任一环节失败都算失败。测包失败时脚本会在第 1 步停住，不会带着坏包继续解压。第 3 步的find输出是给人看的：文件数量、大小分布和 2.3 节unrar l的清单对得上，才说明解压完整。-printf是 GNU find 的参数，Linux 上没问题，macOS 自带的是 BSD find，不认这个格式，把-printf '%p\t%s bytes\n'换成-exec ls -la {} \;即可。

脚本跑完后，我的固定习惯是再补一道自检：如果adt75是程序，先跑它的--version或自带自检；如果是数据集，用find adt75 -type f | wc -l对文件数，再抽查首尾文件内容。全部通过之后，我才会把原始adt75.rar归档或删除——原包留到这一刻，相当于给自己留了后悔药，数据出问题时还能重来一次。

这套流程治好了我以前"先解压再验包"的毛病：那时候解到一半报错、又找不到原始来源，只能干着急。现在不管从哪拿到 rar 包，都是测包、解压、核对三步走，看起来多花一分钟，实际省下的全是后面排错的时间。希望帮到你。

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