尧图网页设计 
简介这份rar压缩包为无线通信领域阵列天线波束赋形的MATLAB实现配套HFSS仿真数据侧重于差分进化算法对波束权值的优化。资源共19个文件包含16个csv数据文件和3个m脚本csv文件可用于导入仿真结果或阵列响应数据m脚本涵盖差分进化算法主程序、数据读取及目标函数定义包体约5MB轻量易用。已有1025人浏览学习适合具备阵列天线基础和MATLAB编程经验的学生、研究人员快速上手。代码内部提供权值计算、信号合成以及方向图生成等核心步骤用户可通过调整参数观察波束形状变化借助HFSS仿真数据校验理论模型理解差分进化算法在多维非线性优化中的实际应用。这套资料将电磁仿真与优化算法紧密结合为深入掌握波束赋形技术提供了可运行的实践范例。1. 如果你在处理 decode.rar 时遇到编码爆炸如果你在处理一个名为decode.rar的归档时控制台抛出了UnicodeDecodeError: utf-8 codec cant decode byte 0xeb先别急着认定压缩包损坏。问题多半出在 RAR 文件名编码Windows 中文环境压出的名字是 GBK而 Linux 上的 Python 默认按 UTF-8 解析字节 0xeb 就这样卡住了解压流程。另一种常见情况是归档加密离职同事留下的decode.rar密码谜团让人不得不走密码恢复路线。下面从 RAR 编码与文件头结构讲起给出可自动容错的解压脚本再进入 hashcat 和 16 进制视角的密码处理最后落到 VSCode 里的调试技巧。2. 理解 RAR 解码的核心编码表与密文结构2.1 文件名编码从 ANSI 到 UTF-8 的过渡RAR 格式诞生于 1993 年当时的个人电脑普遍使用 ANSI 代码页。WinRAR 为了保持向后兼容在文件头中做了一个隐式约定如果文件名存储区域带有 Unicode 标志位则说明该名字采用 UTF-8如果不带则使用创建时的操作系统代码页。中国大陆的 Windows XP/7 时代代码页是 936也就是 GBK。GBK 用双字节表示汉字第一个字节范围是0x81-0xFE第二个字节是0x40-0xFE除去0x7F。所以你遇到的开头字节0xeb很可能就是某个汉字的高位字节比如“连”“这”“码”等字的 GBK 编码都以0xEB开头。问题在于 Python 的rarfile库默认假设文件名是 cp437DOS 美国字符集它会把每个字节映射成一个可打印的西方字符最终产生了乱码而不是异常。当你在某些设置了 UTF-8 的 Python 环境里强制decode(utf-8)时才会抛出UnicodeDecodeError。这里的关键是我们需要拿到 RAR 文件头里原始文件名对应的字节序列再推测它的真实编码而不是用默认编码硬解。2.1.1 用 xxd 验证文件头标志xxd -l 32 decode.rarxxd的-l 32表示只查看前 32 字节。输出中前 8 个字节是 RAR 签名通过签名的第 7 个字节可以看到00还是01进而区分 RAR4 和 RAR5。文件头中的标志位比较复杂RAR4 用 16 位位掩码RAR5 使用可扩展的字段结构。直接看十六进制只能确认大致状态真正需要精确解析时用rar2john或者rarfile库的元数据。2.2 加密结构口令不会出现在文件里RAR3 和 RAR5 的加密方式有明显升级。RAR3 使用基于 SHA-1 的 PBKDF2迭代次数我印象中是 2048 次RAR5 改用 PBKDF2-HMAC-SHA256迭代次数固定为 32768。口令本身不直接保存在文件中而是通过一个校验头验证口令是否正确。校验头里存放的是经过 KDF 派生的密钥与一个随机数salt共同计算出的摘要。这意味着你无法通过“查看 16 进制找密码”的方式获取口令——你能看到的只是随机 salt 和摘要值而非明文。理解这一点你就能明白为什么破解工具都需要先提取 hash再做离线暴力尝试它们是把候选口令经过相同的 KDF 计算对比摘要是否一致。2.3 解码工具矩阵与选型工具定位编码处理能力密码恢复unrar官方命令行工具支持-sc指定编码仅解压不破解7z通用压缩工具自动检测较弱常乱码无rarfilePython 库可传encoding参数可调用后端hashcat高性能密码恢复无关支持 RAR3/RAR5rarcrack内嵌 hash 提取与破解无关CPU 可用选型逻辑日常批量解压我会优先rarfileunrar的组合因为rarfile提供了RarInfo结构能拿到文件名、CRC、头标志等元数据方便在解压前做预处理。如果你想快速看内容又不写程序7z最便捷但它在 Linux 下解压 Windows 压制的 GBK 文件名时经常产生????.txt这种占位符不推荐作为生产方案。真正的硬核场景——比如从几十个旧备份里找回文件名——要用 Python 脚本做编码猜解。2.3.1 最小命令行验证先用unrar看看它自己能正确识别什么unrar l decode.rar这里的l是列出归档内容。unrar从 5.50 开始支持 UTF-8 文件名映射但它对 GBK 的识别依赖系统 locale。如果你的 locale 是C或en_US.UTF-8中文文件名依然会乱码。这时可以加-sc参数强行指定文件名编码unrar l -scgbk decode.rar-scgbk告诉 unrar文件名在存储时使用的是 GBK。如果你确认文件是 RAR5 且本身是 UTF-8则使用-scutf-8。这就是为什么我们要写脚本做自动检测不能每次手动试编码。GBK 和 UTF-8 在文件名字节层面的区分并不总是明显。UTF-8 的汉字通常以三字节序列0xE4-0xE9开头而 GBK 的汉字以双字节序列0x81-0xFE开头且第二个字节也在0x40-0xFE区间。这两类模式在统计上有一定重叠所以chardet对短字符串的判定存在误差。一个可行的修正方法是结合上下文如果同一归档内多个文件名都检测出同一种编码且其中包含常见中文用字则该编码可信度更高。3. 用 Python 编写一个能处理编码错误的 decode.rar 脚本3.1 安装依赖与后端sudo apt install unrar p7zip-full pip install rarfile chardet在 macOS 上把第一行换成brew install unrar。rarfile只是个 Python 包装器真正干活的是unrar或7z可执行文件。安装完unrar后rarfile会在PATH中自动找到它。chardet用于字节序列的编码检测它不是 RAR 解码的必需品但能显著降低人工指定编码的工作量。3.2 直接解压会踩的坑import rarfile with rarfile.RarFile(decode.rar) as rf: rf.extractall(output)这段代码在干净的环境里能跑但碰到中文文件名或者加密文件就出问题。常见异常有三种rarfile.RarCannotExec找不到unrar或7z可执行文件。检查PATH或者直接给rarfile.UNRAR_TOOL赋值。rarfile.BadRarFile: Bad RAR file可能是文件头损坏也可能是 RAR5 文件但unrar版本太低需要 5.0。文件解压成功但文件名是乱码因为rarfile默认用 cp437 解码文件名。cp437 是美国 DOS 时代的字符集和中文完全对不上。注意RarFile初始化时不负责解压它只读取中央目录。所以如果你在with里先调namelist()就报编码错误那么这个错误发生在读取元数据阶段而不是extractall。3.3 手动指定编码后的效果with rarfile.RarFile(decode.rar, encodinggbk) as rf: for name in rf.namelist(): print(name) rf.extractall(output)encodinggbk会让rarfile用 GBK 解码内部的 ANSI 文件名。如果你的归档是 UTF-8 编码则应将encoding设为utf-8。问题来了一个目录里的几十个 RAR 可能混用两种编码手动指定必然出错。我们需要的是自动检测。3.4 自动检测文件名编码的完整脚本下面的脚本是实际工作中我经常用的模板它对文件名做了一次“逆向”处理先按 cp437 把rarfile内部已经解码成 str 的文件名变回原始字节再用chardet检测真实编码最后尝试解码。import rarfile import chardet import sys def decode_raw_name(name: str) - str: 将 rarfile 内部解码后的文件名还原为原始字节并猜测编码 # 因为 cp437 是单字节映射lossless raw name.encode(cp437, errorssurrogateescape) if not raw: return name guess chardet.detect(raw).get(encoding) if guess is None: return raw.decode(utf-8, errorsreplace) try: return raw.decode(guess, errorsreplace) except LookupError: return raw.decode(utf-8, errorsreplace) def extract_smart(path: str, dest: str): rarfile.UNRAR_TOOL unrar # 显式指定后端 with rarfile.RarFile(path) as rf: for info in rf.infolist(): display decode_raw_name(info.filename) print(f{info.filename} - {display}) rf.extractall(dest) if __name__ __main__: extract_smart(sys.argv[1], sys.argv[2])surrogateescape是 Python 处理无法映射字节时的标准逃逸方法这里能保证 cp437 编码回字节时不丢信息。chardet.detect返回的是字节级统计推测对于短文件名可能有误判但通常 GBK/UTF-8 的区分准确率在 90% 以上。如果检测到的是Windows-1252之类的编码可能说明原始文件本来就是乱码这时只能用errorsreplace保底。3.4.1 处理文件内容编码文件名解决了但文件内容同样可能有编码问题。extractall只负责把字节写进磁盘不会校验文本编码。解压完成后你需要手动读取文本文件。下面是一段通用的安全读取代码from pathlib import Path def read_text_file(path: Path) - str: raw path.read_bytes() if not raw: return guess chardet.detect(raw).get(encoding) or utf-8 return raw.decode(guess, errorsreplace)errorsreplace会把无法解码的字节替换成适合混淆密码和快速查看。如果你要写回文件建议在写回时统一用 UTF-8 并且指定newline避免 Windows 和 Linux 换行符互相污染。3.5 常见异常与处置对照表异常信息原因处置RarCannotExec后端缺失安装 unrar或设置rarfile.UNRAR_TOOLBadRarFile文件损坏或 RAR5 不兼容换新版 unrar用unrar t测试归档UnicodeDecodeError尝试用 UTF-8 解码 GBK 字节用脚本自动检测或设encodinggbkRarPasswordRequired归档加密进入第 4 章的密码恢复流程这章写的函数是后面所有操作的基础。第 4 章讲密码恢复时你会看到这些元数据的作用提取 hash 需要的是文件头里的 salt 和校验值而不是文件名。4. decode.rar 的密码恢复从 16 进制视角到 hashcat 实战4.1 16 进制编辑器里到底能看到什么有人习惯用 16 进制编辑器如 HxD、010 Editor去查看 RAR 文件期望找到类似password的字符串。事实上现代 RAR 加密不会把口令以明文放在任何位置。你看到的是头部签名、标志位、salt、校验和密文。用xxd查看加密的 RAR你会注意到文件头标志区有一个加密置位位这能让你确认归档是否加密但没有实际破解价值。如果想通过修改标志位来移除密码得到的只会是一个无法解压的损坏文件因为数据区已经用 AES 加密没有密钥不可能还原。但 16 进制视角并非无用。它可以帮你确认归档版本查看 salt 和迭代次数是否异常甚至在事故排障中确认文件是否被截断。比如 RAR5 的加密头中salt 长度为 16 字节紧随其后的是 16 字节的校验值。你可以在xxd输出中看到类似16$...的结构信息这实际上是rar2john提取 hash 的输入依据。4.2 提取 hashrar2john 与 hashcat 配合首先准备好工具sudo apt install john rar2john decode.rar hash.txt cat hash.txtrar2john是 John the Ripper 套件中的脚本它解析 RAR 文件头输出带有$rar5$或$RAR3$前缀的 hash。以 RAR5 为例decode.rar:$rar5$16$2f3b...e9a4$16$8c0d...b01f$32768$0这段内容的分隔符含义是16salt 的字节长度这里 16 字节第一串 hexsalt 本身第二个16校验值长度第二串 hex校验值32768PBKDF2 迭代次数最后的0版本相关标记拿到 hash 后用 hashcat 破解。RAR5 的模式编号是13000RAR3 是125需要注意 RAR3 的 hash 格式和rar2john输出可能不完全一样如果-m 125报错请直接使用john的--formatrar。hashcat -m 13000 -a 0 hash.txt /usr/share/wordlists/rockyou.txt-a 0是字典攻击模式。如果你猜测密码是 6 位数字可以用掩码hashcat -m 13000 -a 3 hash.txt ?d?d?d?d?d?d?d代表数字 0-9。你可以组合?l小写、?u大写、?s特殊符号。掩码攻击的效率取决于 GPU 和迭代次数RAR5 的 32768 次迭代在单张消费级显卡上大约每秒几十到几百次尝试所以纯粹暴力 8 位以上不现实通常建议用字典加规则。破解完成后用下面的命令查看结果hashcat -m 13000 hash.txt --show--show会从 potfile已破解密码的缓存文件中读取已经成功破解的密码不需要重新计算。如果你的 hash 对应多个文件可以用--user参数保留原始文件名标签。4.3 破解速度参考与参数调整下面的表格是我在常见硬件上的粗略参考不同驱动和功耗设置会有差异只作为预算时间的依据。硬件模式速率 (H/s)6位小写字母耗时笔记本 CPU (4核)13000~200约 2 天台式机 CPU (8核)13000~500约 20 小时GTX 1660 Super13000~2000约 5 小时RTX 409013000~8000约 1.5 小时看到这组数据你就明白为什么纯暴力不可取。更现实的做法是构建与目标人物相关的字典用hashcat的规则扩展比如在字典中每个词后面追加两位年份数字。命令如下hashcat -m 13000 -a 0 -r my.rule hash.txt base_dict.txtmy.rule是你自己写的规则文件比如$1$9$8$5表示在原词末尾添加1985。具体规则语法可以参考 hashcat 官方 wiki这里不展开。4.4 rarcrack 的嵌入式破解如果你不想先提取 hash也可以用rarcrack直接喂 RAR 文件rarcrack decode.rar --type rar3 --threads 4 --charset abc123 --min 4 --max 6它的工作方式是尝试一个口令然后调用unrar测试是否能解压因此速度远低于 hashcat只适合密码可能很短或多机器并行的小任务。rarcrack 会生成一个decode.rar.xml进度文件中断后重新运行会从之前的进度继续。这里需要强调的是任何密码恢复工具都要在合法授权下使用。如果你拿到的 RAR 属于公司或他人请先确认你有权访问其中的数据。技术本身是中性的但操作对象和边界决定合法与否。5. 在 VSCode 里优雅地调试 decode.rar 全套过程5.1 配置 Python 调试环境在 VSCode 中直接运行上面的脚本很可能在print阶段就出现编码错误因为 Windows 控制台的默认代码页可能是 GBK而 Python 3.6 在 Windows 上又把 stdout 强行设成了 UTF-8。最简单的方式是在.vscode/launch.json里指定环境变量{ version: 0.2.0, configurations: [ { name: Rar Decoder, type: python, request: launch, program: ${file}, args: [decode.rar, output], console: integratedTerminal, env: { PYTHONIOENCODING: utf-8, PYTHONUTF8: 1 } } ] }PYTHONIOENCODING控制标准 I/O 的编码PYTHONUTF81则强制 Python 的文件系统编码和默认文本编码为 UTF-8。这样你在集成终端里看到的输出就是准确的不会因为终端本身影响判断。5.2 用断点检查 RAR 内部的原始字节在decode_raw_name函数的raw name.encode(...)这一行打断点。当断点命中时在调试监视器里添加raw查看它的十六进制。如果raw以0xeb开头说明原始字节是 GBK 的高位字如果以0x65 0x73即es开头则大概率是 Latin 字符。确认后你就能快速决定该用哪个编码。你还可以把鼠标悬停在name上看str的 repr。由于rarfile用 cp437 解码你会在里面看到类似ä¸æ–‡这样的字符串这就是“中文”被 cp437 误读的结果。看到这个形态就说明必须走编码重猜流程。5.3 一个可以被反复调用的调试技巧编码回退装饰器遇到UnicodeDecodeError时我习惯写一个很小的装饰器让函数自动重试编码from functools import wraps def retry_decode(default_encutf-8): def decorator(func): wraps(func) def wrapper(raw: bytes, *args, **kwargs): try: return raw.decode(default_enc) except UnicodeDecodeError: import chardet enc chardet.detect(raw).get(encoding) or latin1 return raw.decode(enc, errorsreplace) return wrapper return decorator retry_decode(utf-8) def decode_bytes(raw): return raw.decode(utf-8) # 实际会被装饰器接管注意装饰器内部的raw.decode(...)并不是递归真正的执行逻辑是在wrapper里完成的。使用示例name_bytes b\xeb\x8a\x9e text decode_bytes(name_bytes)在当前 VSCode 的“调试控制台”里直接调用decode_bytes(b\xeb...)会比反复运行整个脚本快得多。调试完成后你可以删除装饰器或者把编码检测逻辑整合到正式代码里。最后给出一条在排障时很实用的建议在rarfile解压前先用unrar t测试归档完整性再用本文的脚本处理文件名即使密码未知完整的测试输出也能帮你区分“文件损坏”和“需要密码”两类问题。这样你就能把精力集中在真正值得投入的环节上。本文还有配套的精品资源点击获取 RAR解码与密码恢复：从编码错误到Python自动化处理
简介这份rar压缩包为无线通信领域阵列天线波束赋形的MATLAB实现配套HFSS仿真数据侧重于差分进化算法对波束权值的优化。资源共19个文件包含16个csv数据文件和3个m脚本csv文件可用于导入仿真结果或阵列响应数据m脚本涵盖差分进化算法主程序、数据读取及目标函数定义包体约5MB轻量易用。已有1025人浏览学习适合具备阵列天线基础和MATLAB编程经验的学生、研究人员快速上手。代码内部提供权值计算、信号合成以及方向图生成等核心步骤用户可通过调整参数观察波束形状变化借助HFSS仿真数据校验理论模型理解差分进化算法在多维非线性优化中的实际应用。这套资料将电磁仿真与优化算法紧密结合为深入掌握波束赋形技术提供了可运行的实践范例。1. 如果你在处理 decode.rar 时遇到编码爆炸如果你在处理一个名为decode.rar的归档时控制台抛出了UnicodeDecodeError: utf-8 codec cant decode byte 0xeb先别急着认定压缩包损坏。问题多半出在 RAR 文件名编码Windows 中文环境压出的名字是 GBK而 Linux 上的 Python 默认按 UTF-8 解析字节 0xeb 就这样卡住了解压流程。另一种常见情况是归档加密离职同事留下的decode.rar密码谜团让人不得不走密码恢复路线。下面从 RAR 编码与文件头结构讲起给出可自动容错的解压脚本再进入 hashcat 和 16 进制视角的密码处理最后落到 VSCode 里的调试技巧。2. 理解 RAR 解码的核心编码表与密文结构2.1 文件名编码从 ANSI 到 UTF-8 的过渡RAR 格式诞生于 1993 年当时的个人电脑普遍使用 ANSI 代码页。WinRAR 为了保持向后兼容在文件头中做了一个隐式约定如果文件名存储区域带有 Unicode 标志位则说明该名字采用 UTF-8如果不带则使用创建时的操作系统代码页。中国大陆的 Windows XP/7 时代代码页是 936也就是 GBK。GBK 用双字节表示汉字第一个字节范围是0x81-0xFE第二个字节是0x40-0xFE除去0x7F。所以你遇到的开头字节0xeb很可能就是某个汉字的高位字节比如“连”“这”“码”等字的 GBK 编码都以0xEB开头。问题在于 Python 的rarfile库默认假设文件名是 cp437DOS 美国字符集它会把每个字节映射成一个可打印的西方字符最终产生了乱码而不是异常。当你在某些设置了 UTF-8 的 Python 环境里强制decode(utf-8)时才会抛出UnicodeDecodeError。这里的关键是我们需要拿到 RAR 文件头里原始文件名对应的字节序列再推测它的真实编码而不是用默认编码硬解。2.1.1 用 xxd 验证文件头标志xxd -l 32 decode.rarxxd的-l 32表示只查看前 32 字节。输出中前 8 个字节是 RAR 签名通过签名的第 7 个字节可以看到00还是01进而区分 RAR4 和 RAR5。文件头中的标志位比较复杂RAR4 用 16 位位掩码RAR5 使用可扩展的字段结构。直接看十六进制只能确认大致状态真正需要精确解析时用rar2john或者rarfile库的元数据。2.2 加密结构口令不会出现在文件里RAR3 和 RAR5 的加密方式有明显升级。RAR3 使用基于 SHA-1 的 PBKDF2迭代次数我印象中是 2048 次RAR5 改用 PBKDF2-HMAC-SHA256迭代次数固定为 32768。口令本身不直接保存在文件中而是通过一个校验头验证口令是否正确。校验头里存放的是经过 KDF 派生的密钥与一个随机数salt共同计算出的摘要。这意味着你无法通过“查看 16 进制找密码”的方式获取口令——你能看到的只是随机 salt 和摘要值而非明文。理解这一点你就能明白为什么破解工具都需要先提取 hash再做离线暴力尝试它们是把候选口令经过相同的 KDF 计算对比摘要是否一致。2.3 解码工具矩阵与选型工具定位编码处理能力密码恢复unrar官方命令行工具支持-sc指定编码仅解压不破解7z通用压缩工具自动检测较弱常乱码无rarfilePython 库可传encoding参数可调用后端hashcat高性能密码恢复无关支持 RAR3/RAR5rarcrack内嵌 hash 提取与破解无关CPU 可用选型逻辑日常批量解压我会优先rarfileunrar的组合因为rarfile提供了RarInfo结构能拿到文件名、CRC、头标志等元数据方便在解压前做预处理。如果你想快速看内容又不写程序7z最便捷但它在 Linux 下解压 Windows 压制的 GBK 文件名时经常产生????.txt这种占位符不推荐作为生产方案。真正的硬核场景——比如从几十个旧备份里找回文件名——要用 Python 脚本做编码猜解。2.3.1 最小命令行验证先用unrar看看它自己能正确识别什么unrar l decode.rar这里的l是列出归档内容。unrar从 5.50 开始支持 UTF-8 文件名映射但它对 GBK 的识别依赖系统 locale。如果你的 locale 是C或en_US.UTF-8中文文件名依然会乱码。这时可以加-sc参数强行指定文件名编码unrar l -scgbk decode.rar-scgbk告诉 unrar文件名在存储时使用的是 GBK。如果你确认文件是 RAR5 且本身是 UTF-8则使用-scutf-8。这就是为什么我们要写脚本做自动检测不能每次手动试编码。GBK 和 UTF-8 在文件名字节层面的区分并不总是明显。UTF-8 的汉字通常以三字节序列0xE4-0xE9开头而 GBK 的汉字以双字节序列0x81-0xFE开头且第二个字节也在0x40-0xFE区间。这两类模式在统计上有一定重叠所以chardet对短字符串的判定存在误差。一个可行的修正方法是结合上下文如果同一归档内多个文件名都检测出同一种编码且其中包含常见中文用字则该编码可信度更高。3. 用 Python 编写一个能处理编码错误的 decode.rar 脚本3.1 安装依赖与后端sudo apt install unrar p7zip-full pip install rarfile chardet在 macOS 上把第一行换成brew install unrar。rarfile只是个 Python 包装器真正干活的是unrar或7z可执行文件。安装完unrar后rarfile会在PATH中自动找到它。chardet用于字节序列的编码检测它不是 RAR 解码的必需品但能显著降低人工指定编码的工作量。3.2 直接解压会踩的坑import rarfile with rarfile.RarFile(decode.rar) as rf: rf.extractall(output)这段代码在干净的环境里能跑但碰到中文文件名或者加密文件就出问题。常见异常有三种rarfile.RarCannotExec找不到unrar或7z可执行文件。检查PATH或者直接给rarfile.UNRAR_TOOL赋值。rarfile.BadRarFile: Bad RAR file可能是文件头损坏也可能是 RAR5 文件但unrar版本太低需要 5.0。文件解压成功但文件名是乱码因为rarfile默认用 cp437 解码文件名。cp437 是美国 DOS 时代的字符集和中文完全对不上。注意RarFile初始化时不负责解压它只读取中央目录。所以如果你在with里先调namelist()就报编码错误那么这个错误发生在读取元数据阶段而不是extractall。3.3 手动指定编码后的效果with rarfile.RarFile(decode.rar, encodinggbk) as rf: for name in rf.namelist(): print(name) rf.extractall(output)encodinggbk会让rarfile用 GBK 解码内部的 ANSI 文件名。如果你的归档是 UTF-8 编码则应将encoding设为utf-8。问题来了一个目录里的几十个 RAR 可能混用两种编码手动指定必然出错。我们需要的是自动检测。3.4 自动检测文件名编码的完整脚本下面的脚本是实际工作中我经常用的模板它对文件名做了一次“逆向”处理先按 cp437 把rarfile内部已经解码成 str 的文件名变回原始字节再用chardet检测真实编码最后尝试解码。import rarfile import chardet import sys def decode_raw_name(name: str) - str: 将 rarfile 内部解码后的文件名还原为原始字节并猜测编码 # 因为 cp437 是单字节映射lossless raw name.encode(cp437, errorssurrogateescape) if not raw: return name guess chardet.detect(raw).get(encoding) if guess is None: return raw.decode(utf-8, errorsreplace) try: return raw.decode(guess, errorsreplace) except LookupError: return raw.decode(utf-8, errorsreplace) def extract_smart(path: str, dest: str): rarfile.UNRAR_TOOL unrar # 显式指定后端 with rarfile.RarFile(path) as rf: for info in rf.infolist(): display decode_raw_name(info.filename) print(f{info.filename} - {display}) rf.extractall(dest) if __name__ __main__: extract_smart(sys.argv[1], sys.argv[2])surrogateescape是 Python 处理无法映射字节时的标准逃逸方法这里能保证 cp437 编码回字节时不丢信息。chardet.detect返回的是字节级统计推测对于短文件名可能有误判但通常 GBK/UTF-8 的区分准确率在 90% 以上。如果检测到的是Windows-1252之类的编码可能说明原始文件本来就是乱码这时只能用errorsreplace保底。3.4.1 处理文件内容编码文件名解决了但文件内容同样可能有编码问题。extractall只负责把字节写进磁盘不会校验文本编码。解压完成后你需要手动读取文本文件。下面是一段通用的安全读取代码from pathlib import Path def read_text_file(path: Path) - str: raw path.read_bytes() if not raw: return guess chardet.detect(raw).get(encoding) or utf-8 return raw.decode(guess, errorsreplace)errorsreplace会把无法解码的字节替换成适合混淆密码和快速查看。如果你要写回文件建议在写回时统一用 UTF-8 并且指定newline避免 Windows 和 Linux 换行符互相污染。3.5 常见异常与处置对照表异常信息原因处置RarCannotExec后端缺失安装 unrar或设置rarfile.UNRAR_TOOLBadRarFile文件损坏或 RAR5 不兼容换新版 unrar用unrar t测试归档UnicodeDecodeError尝试用 UTF-8 解码 GBK 字节用脚本自动检测或设encodinggbkRarPasswordRequired归档加密进入第 4 章的密码恢复流程这章写的函数是后面所有操作的基础。第 4 章讲密码恢复时你会看到这些元数据的作用提取 hash 需要的是文件头里的 salt 和校验值而不是文件名。4. decode.rar 的密码恢复从 16 进制视角到 hashcat 实战4.1 16 进制编辑器里到底能看到什么有人习惯用 16 进制编辑器如 HxD、010 Editor去查看 RAR 文件期望找到类似password的字符串。事实上现代 RAR 加密不会把口令以明文放在任何位置。你看到的是头部签名、标志位、salt、校验和密文。用xxd查看加密的 RAR你会注意到文件头标志区有一个加密置位位这能让你确认归档是否加密但没有实际破解价值。如果想通过修改标志位来移除密码得到的只会是一个无法解压的损坏文件因为数据区已经用 AES 加密没有密钥不可能还原。但 16 进制视角并非无用。它可以帮你确认归档版本查看 salt 和迭代次数是否异常甚至在事故排障中确认文件是否被截断。比如 RAR5 的加密头中salt 长度为 16 字节紧随其后的是 16 字节的校验值。你可以在xxd输出中看到类似16$...的结构信息这实际上是rar2john提取 hash 的输入依据。4.2 提取 hashrar2john 与 hashcat 配合首先准备好工具sudo apt install john rar2john decode.rar hash.txt cat hash.txtrar2john是 John the Ripper 套件中的脚本它解析 RAR 文件头输出带有$rar5$或$RAR3$前缀的 hash。以 RAR5 为例decode.rar:$rar5$16$2f3b...e9a4$16$8c0d...b01f$32768$0这段内容的分隔符含义是16salt 的字节长度这里 16 字节第一串 hexsalt 本身第二个16校验值长度第二串 hex校验值32768PBKDF2 迭代次数最后的0版本相关标记拿到 hash 后用 hashcat 破解。RAR5 的模式编号是13000RAR3 是125需要注意 RAR3 的 hash 格式和rar2john输出可能不完全一样如果-m 125报错请直接使用john的--formatrar。hashcat -m 13000 -a 0 hash.txt /usr/share/wordlists/rockyou.txt-a 0是字典攻击模式。如果你猜测密码是 6 位数字可以用掩码hashcat -m 13000 -a 3 hash.txt ?d?d?d?d?d?d?d代表数字 0-9。你可以组合?l小写、?u大写、?s特殊符号。掩码攻击的效率取决于 GPU 和迭代次数RAR5 的 32768 次迭代在单张消费级显卡上大约每秒几十到几百次尝试所以纯粹暴力 8 位以上不现实通常建议用字典加规则。破解完成后用下面的命令查看结果hashcat -m 13000 hash.txt --show--show会从 potfile已破解密码的缓存文件中读取已经成功破解的密码不需要重新计算。如果你的 hash 对应多个文件可以用--user参数保留原始文件名标签。4.3 破解速度参考与参数调整下面的表格是我在常见硬件上的粗略参考不同驱动和功耗设置会有差异只作为预算时间的依据。硬件模式速率 (H/s)6位小写字母耗时笔记本 CPU (4核)13000~200约 2 天台式机 CPU (8核)13000~500约 20 小时GTX 1660 Super13000~2000约 5 小时RTX 409013000~8000约 1.5 小时看到这组数据你就明白为什么纯暴力不可取。更现实的做法是构建与目标人物相关的字典用hashcat的规则扩展比如在字典中每个词后面追加两位年份数字。命令如下hashcat -m 13000 -a 0 -r my.rule hash.txt base_dict.txtmy.rule是你自己写的规则文件比如$1$9$8$5表示在原词末尾添加1985。具体规则语法可以参考 hashcat 官方 wiki这里不展开。4.4 rarcrack 的嵌入式破解如果你不想先提取 hash也可以用rarcrack直接喂 RAR 文件rarcrack decode.rar --type rar3 --threads 4 --charset abc123 --min 4 --max 6它的工作方式是尝试一个口令然后调用unrar测试是否能解压因此速度远低于 hashcat只适合密码可能很短或多机器并行的小任务。rarcrack 会生成一个decode.rar.xml进度文件中断后重新运行会从之前的进度继续。这里需要强调的是任何密码恢复工具都要在合法授权下使用。如果你拿到的 RAR 属于公司或他人请先确认你有权访问其中的数据。技术本身是中性的但操作对象和边界决定合法与否。5. 在 VSCode 里优雅地调试 decode.rar 全套过程5.1 配置 Python 调试环境在 VSCode 中直接运行上面的脚本很可能在print阶段就出现编码错误因为 Windows 控制台的默认代码页可能是 GBK而 Python 3.6 在 Windows 上又把 stdout 强行设成了 UTF-8。最简单的方式是在.vscode/launch.json里指定环境变量{ version: 0.2.0, configurations: [ { name: Rar Decoder, type: python, request: launch, program: ${file}, args: [decode.rar, output], console: integratedTerminal, env: { PYTHONIOENCODING: utf-8, PYTHONUTF8: 1 } } ] }PYTHONIOENCODING控制标准 I/O 的编码PYTHONUTF81则强制 Python 的文件系统编码和默认文本编码为 UTF-8。这样你在集成终端里看到的输出就是准确的不会因为终端本身影响判断。5.2 用断点检查 RAR 内部的原始字节在decode_raw_name函数的raw name.encode(...)这一行打断点。当断点命中时在调试监视器里添加raw查看它的十六进制。如果raw以0xeb开头说明原始字节是 GBK 的高位字如果以0x65 0x73即es开头则大概率是 Latin 字符。确认后你就能快速决定该用哪个编码。你还可以把鼠标悬停在name上看str的 repr。由于rarfile用 cp437 解码你会在里面看到类似ä¸æ–‡这样的字符串这就是“中文”被 cp437 误读的结果。看到这个形态就说明必须走编码重猜流程。5.3 一个可以被反复调用的调试技巧编码回退装饰器遇到UnicodeDecodeError时我习惯写一个很小的装饰器让函数自动重试编码from functools import wraps def retry_decode(default_encutf-8): def decorator(func): wraps(func) def wrapper(raw: bytes, *args, **kwargs): try: return raw.decode(default_enc) except UnicodeDecodeError: import chardet enc chardet.detect(raw).get(encoding) or latin1 return raw.decode(enc, errorsreplace) return wrapper return decorator retry_decode(utf-8) def decode_bytes(raw): return raw.decode(utf-8) # 实际会被装饰器接管注意装饰器内部的raw.decode(...)并不是递归真正的执行逻辑是在wrapper里完成的。使用示例name_bytes b\xeb\x8a\x9e text decode_bytes(name_bytes)在当前 VSCode 的“调试控制台”里直接调用decode_bytes(b\xeb...)会比反复运行整个脚本快得多。调试完成后你可以删除装饰器或者把编码检测逻辑整合到正式代码里。最后给出一条在排障时很实用的建议在rarfile解压前先用unrar t测试归档完整性再用本文的脚本处理文件名即使密码未知完整的测试输出也能帮你区分“文件损坏”和“需要密码”两类问题。这样你就能把精力集中在真正值得投入的环节上。本文还有配套的精品资源点击获取