Rars：一个主要由LLM编写的Rust RAR实现

# 用 Rust 写个 rars，老铁 来源: https://bitplane.net/log/2026/05/rars/ 我用 LLM 做过几个逆向工程项目（[这个](https://bitplane.net/dev/python/cff-most/)、[那个](https://bitplane.net/dev/rust/amiga-lzx/)、[还有这个](https://bitplane.net/dev/python/crunchmania/)、[以及这个](https://bitplane.net/log/2026/04/mkfs/)），觉得是时候把那些铁疙瘩逼到极限了。 给每个版本的 RAR 写个压缩器，按理说应该要花个五年，所以从来没人费这劲。如今，花了五个晚上的周末时间，用上 OpenAI Codex 5.5 和 Claude Opus 4.7，成本大约 40 英镑（还是严重补贴后的 token 价），就搞定了。 是的，它是 5.5 万行的“屎山”，速度不快，还差点让我被 OpenAI 封号。但——它跑起来了。 --- ## SPECIF~1.RAR（[链接](https://bitplane.net/log/2026/05/rars/#specif1rar)） RAR 最初是 DOS 下的一个 LZSS 压缩器，在 warez 圈子里作为首选格式而风靡一时。为了和 WinZip 争夺功能对等和霸主地位，WinRAR 推出了多卷支持、恢复记录，甚至一个内部虚拟机，但它最大的卖点始终是更强的压缩率。这是一个中年格式，从未停止成长，庞杂得像一栋房子。 `unrar` 带有源代码，但那些代码实际上并不自由，而且有点讽刺的是，RAR 的作者 Eugene Roshal 并不喜欢盗版。所以理想情况下，我需要根据规范自己实现，但规范根本不存在。 创建规范这个艰巨任务涉及到从开源解压器中提取代码——unar、libarchive、UNRARLIB，还有随机网页和民间传说。 然后我让 Claude 尽可能多地整理文档。每一轮之后，我都会追问缺失的功能，并持续维护一个“漏洞文档”，记录那些难以知晓的细节。这个文档在上下文重置之间保持不变——重置是为了把 token 流向漏洞。花了两个星期的反复烹饪，直到我们把读取端的大部分内容都记录下来。但写入端仍然是胡编乱造和推测的混合物。 所以下一步，我拿来了 DOS 和 Windows 的 RAR 二进制文件，开始制作测试用例，进行十六进制转储，并在 Ghidra 和 DOSBox-x 中反复分析，以了解它们是如何打包的。又花了一两周，漏洞开始闭合。 现在我有了可能派得上用场的东西：每个 RAR 文件格式版本的规范文档： - 📚 规范（[https://github.com/bitplane/rar-research](https://github.com/bitplane/rar-research)） --- ## 开始造轮子（[链接](https://bitplane.net/log/2026/05/rars/#building-something)） 怀着无比自信的错误，我和 Codex、Claude 开始构建一个（摇摇欲坠地）兼容的 Rust 命令行工具。工作流程大致如下： ### 基于规范开发（[链接](https://bitplane.net/log/2026/05/rars/#working-from-spec)） Opus 很棒，但它往往热情洋溢地生成代码，却忽略了全局。Claude 需要补救性的审查、重构和短缰绳，但在讨论策略或架构方面很出色。Gippity 5.5 在没人打扰时能紧盯目标，但如果你跟它聊太多，它会把你带进兔子洞。我可以把规范文档扔给 Codex，基本告诉它“放手干吧”。非常清爽。 基于规范开发时，Codex 会因“网络违规”随机停止，我得手动压缩才能继续。最终我必须通过 OpenAI 验证才能避免这种情况。结果发现，在规范调研的某个时候，Claude 需要了解“真实性验证”，而这是个付费功能。在装满逆向工程工具的上下文中，它破解了 WinRAR 并绕过了产品注册，然后尽职尽责地在规范中记录了它的“罪行”。这些文档被 OpenAI 发现后触发了警报，直接把它干停了。我从 git 历史中删除了这部分，并决定——**不**实现这个功能。 ### 一只脚踩刹车（[链接](https://bitplane.net/log/2026/05/rars/#one-foot-on-the-brake)） 你得盯着那些机器人，在事情开始变糟时及时打断。如果不这样做，它们就会用各种特例绕过每一个问题和每一个测试，丑陋的模式会蔓延到你的代码中，后面就得花大价钱重构。我本应该多干预一些，但我没做到，后来为此付出了代价。Token 是补贴的，但浪费的是我的时间。 过去大约 15 个月，我的爱好就是对 Claude 大喊大叫，所以我对干预这件事越来越在行。我喜欢这种感觉，即使它已经损害了我的性格。我对 Codex 骂得少很多，也许是因为它更快，或者不那么像个咧嘴傻笑的蠢货，但更可能因为它平淡而专业。这也许是好事，但我还不确定。 ### 测试，为了科学（[链接](https://bitplane.net/log/2026/05/rars/#tests-for-science)） 测试多得离谱。脆弱的测试、无关紧要的覆盖率、` excessively\_long\_test\_names\_that\_fill\_your\_screen`——这些在开发如此规模的代码时至关重要。它们提供了一种统计质量，扭曲了文本生成，当机器人偏离轨道或试图偷工时，能把它们拉回正轨。所以，请给我大量的单元测试，尽可能高的覆盖率。我们以后总可以删掉它们，对吧？对吧？... 所以测试保持了代码的形状，但真正运行代码才能让它与现实对齐。因此真正的工作是关于测试用例、对照检查，以及修正规范中的错误。在这个过程中，Codex 清理了之前至少经过十轮审查都没发现的自动填充废话（“幻觉”）。 事实证明，经验性地与现实碰撞是获取信号的最佳方式，经过足够的时间，规范被打磨得接近真理。科学。 ### 交叉上下文（[链接](https://bitplane.net/log/2026/05/rars/#cross-cutting-context)） 我定期让 Claude 对代码进行一次全面审查。这有助于把代码库从令人无法容忍的屎山，推向更可容忍的屎山——这是我们在 2026 年 5 月所能期望的最好结果。 不过审查代理的问题在于热情。它们会生成极其集中的吹毛求疵，争论那些无关紧要的事情，所以你还需要一个过滤器。 我的过滤器是这样的：我把 `review.md` 放到 `.gitignore` 中，然后指示 Codex 将审查分组成批次。然后我把它们按功能区域添加到 `plan.md` 中，这个计划驱动开发任务。Claude 知道之前的审查会招致复合的盲点，而告诉 Codex 哪些事情我不在意又会污染上下文——所有文本都会。有选择性地管理上下文，在会话之间切换，删除 review 文档，在不同机器上运行，这些多样性有助于工作流向所有漏洞。 过了一段时间，我让 Claude 扮演 UAT 测试员，编排兼容性测试套件，并在现实中的存档上进行测试，生成新的 review.md，这些文档通过常规途径输入到计划中。这是一个串行过程，但不算太大的瓶颈。 ## 首次发布（[链接](https://bitplane.net/log/2026/05/rars/#a-first-release)） 等做到 RAR 2.9 时，我对阅读机器生成的废话有点厌倦了。于是我开始转做其他项目。既然已经有一个能工作的 CLI，支持 RAR 1.3 和 1.4 版本（大多数工具甚至打不开这些版本），我就把它重新生成到一个新目录，然后推送到了 crates.io。 我觉得这对档案管理员会有用，即使我放弃了。所以在这里： - 🦀 oldrar（[https://crates.io/crates/oldrar](https://crates.io/crates/oldrar)） - 🐱 源码（[https://github.com/bitplane/oldrar](https://github.com/bitplane/oldrar)） - 🏠 主页（[https://bitplane.net/dev/rust/oldrar](https://bitplane.net/dev/rust/oldrar)） --- ## 打进一个`/goal`（[链接](https://bitplane.net/log/2026/05/rars/#scoring-a-goal)） 上周晚些时候，OpenAI 发布了 `/goal` 功能，我又捡起了这个项目。这基本上是一个 Ralph 循环，允许机器人无限制地在一项任务上磨，在填满其可怜的上下文限制后自动压缩并继续。只运行一个会话甚至不会触及 5 小时的使用限制，所以它多次运行了 6 小时以上，将剩下的规范转录成代码，还有一次连续运行了 16 小时，直到我打断它并要求重构。它就这样冲破了大部分工作，洪水般地填充了大约 4 万行代码，实现了恢复记录、加密、多卷支持和大量我至今还不完全了解的规范工作。 在 Codex 工作的同时，我和 Claude 找到了更多的 RAR 文件，并建立了一个压缩基准测试和兼容性回归测试套件。让 Codex 优化压缩的任务出乎意料地有效，它能够应用其他压缩器中的众所周知的技术，将 LZSS 优化到仅比 WinRAR 差 5-10%，并在一些测试数据上超过了 RAR。WinRAR 是由一个技艺高超且痴迷的俄罗斯黑客优化了几十年的，而我只是用蛮力和无知使用了分布的中位数。考虑到付出的努力，能如此接近感觉是个巨大的胜利。而且既然我不想读太多代码，这样也就可以了。 性能则完全是另一回事。Codex 很乐意使用 `valgrind` 和 `hyperfine` 来寻找热点，并且毫不费力地捡起了低垂的果实。但在寻找那种经验丰富的 C 开发者用来压榨热循环的新型性能技巧方面，它差得远，最终速度慢了数倍。或者也可能是惯用的、安全的 Rust 代码本身就慢。我怀疑两者兼有。 最新版本的 Codex 模型生成的代码几乎没有注释，我很喜欢这一点，因为注释不会被执行，而且会迅速腐烂。但厌恶注释加上自动压缩，导致了 RAR 1.4 兼容性上的功能回归，尤其是与 DOS 版本的 RAR 交互时，至少有 3 次因此绊倒。如果在源代码中放个注释，本可以避免这个问题。 另一件事：Claude 的审查，特别是 UAT 审查，深入了细节，却错过了最明显的东西——用户体验是一团可怕的机器可读噪音。它捕获了不一致和错误，但直到我明确说“告诉我为什么这用户体验很烂”，它才给出任何与用户体验相关的建议，尽管用户体验是主要目标。其他领域也是如此，它们默认有盲点，很可能可以通过代理技能或在提示中加入一点“你tm在逗我”来解决。 --- ## 我们学到了什么？（[链接](https://bitplane.net/log/2026/05/rars/#what-did-we-learn)） 所以 TL;DR 是： 1. 基于规范开发确实可行。 2. 现代模型非常擅长 Rust。 3. 自主研究极其强大。 4. 测试、文档和注释通过质量和引导来塑造上下文。 5. 自带架构，否则就得支付重构费用。 6. 暂时不要指望出色的性能或新颖的见解。 7. 机器人可能会忽略显而易见的东西。 --- ## 🦀 rars（[链接](https://bitplane.net/log/2026/05/rars/#-rars)） 所以，这就是用 Rust 实现的 RAR。它很凌乱，很慢，体积接近 2 MB，压缩率比 WinRAR 稍差。 但是，它能跑起来，而且现在世界上有了一个自由软件的 RAR 实现。所以，这番努力是值得的。 你可以这样安装 `rars`： 以及链接在这里： - 🏠 主页（[https://bitplane.net/rust/rars](https://bitplane.net/rust/rars)） - 🦀 crate（[https://crates.io/crates/rars-cli](https://crates.io/crates/rars-cli)） - 🐱 源码（[https://github.com/bitplane/rars](https://github.com/bitplane/rars)）