UnRAR.dll 是唯一靠谱的纯 C# 可用方案
没有真正意义上的“纯托管 C# RAR 解压库”。RAR 是专有格式，官方未公开完整规范，所有可靠实现都基于
UnRAR.dll（由 RARLAB 官方提供）的封装。所谓“不依赖外部程序”，是指不调用
unrar.exe或
winrar.exe这类命令行工具，但依然需要加载原生 DLL —— 这是绕不开的现实。
常见误区是误信某些 NuGet 包（如
SharpCompress、
DotNetZip）支持 RAR：它们明确声明 不支持 RAR v5+（即现代默认格式），对 RAR v4 的支持也极不稳定，解密、分卷、Unicode 路径等场景大概率失败。
如何安全集成 UnRAR.dll 到 C# 项目
必须使用官方发布的
UnRAR.dll（注意版本匹配），不能用第三方编译版或“免 DLL”包装器（多数已失效或含风险）。推荐方式： 从 RARLAB 官网 下载最新
unrarw32.exe或
unrarw64.exe，解压出其中的
UnRAR.dll将
UnRAR.dll放入项目输出目录（
bin/Debug或
bin/Release），并设属性为“始终复制” 用
[DllImport]声明关键函数，例如
UNRARX5入口点；不要尝试自己解析 RAR 文件头 —— 格式细节（如加密 salt、AES-256 密钥派生）未公开且频繁变更 注意平台匹配：x64 项目必须用
UnRAR.dll（64 位版），AnyCPU 项目需按运行时架构动态加载对应版本，否则抛
DllNotFoundException或
BadImageFormatException
常见错误：密码正确却报“CRC 错误”或“文件损坏”
这不是代码问题，而是 RAR 加密机制导致的假阳性。RAR 使用“密码 + 文件名”双重派生密钥，若解压时未传入原始文件名（尤其是含非 ASCII 字符时），
UnRAR.dll会因密钥不匹配而校验失败，表现像 CRC 错误。
实操要点：
调用SetPassword后，必须确保后续
ProcessFile操作中传入的文件路径与压缩时完全一致（大小写、编码、路径分隔符） 避免用
Directory.GetFiles获取待解压列表后再处理 —— 它可能改变原始编码；应直接从 RAR 内部枚举文件名（通过
Callback函数或
FindFirst/
FindNext） 中文路径务必确认压缩端使用的是 UTF-8（RAR 5.0+ 默认）而非 OEM 编码；若不确定，可先用官方 WinRAR 打开验证能否正常显示
替代思路：改用 ZIP 或 7z 是否可行？
如果控制权在你手上（即你能决定压缩端格式），强烈建议放弃 RAR。ZIP（用
System.IO.Compression.ZipFile）和 7z（用
SevenZipExtractor+
7z.dll）都有成熟、开源、纯托管或稳定封装的方案，无专利限制，Unicode 和密码支持更透明。
但若必须处理用户提交的 RAR 文件（比如上传接口），就别纠结“纯托管”执念 ——
UnRAR.dll是事实标准，只要部署时带对位 DLL、处理好异常路径和编码，它比任何“纯 C# 尝试”都可靠得多。真正的坑不在 DLL 本身，而在忽略 RAR 特有的加密绑定逻辑和版本碎片化。
