Появился rars — свободный проект на Rust, который работает с RAR и впервые для open-source мира обещает не только распаковку, но и создание архивов. Автор честно описывает, где помог ИИ, где пришлось «держать руль руками», и почему именно тесты стали главным инструментом контроля качества.
В мире архиваторов формат RAR долго оставался «неудобным» для открытых проектов: распаковать — пожалуйста, а вот создать архив без проприетарных инструментов почти всегда было невозможно. Теперь ситуация меняется: вышел rars — свободная реализация RAR на Rust, которая поддерживает и распаковку, и создание RAR‑архивов.
Что это за проект и какие версии RAR он понимает
rars заявлен как реализация RAR на Rust с поддержкой разных поколений формата: от ранних RAR 1.3/1.4 (с сигнатурой RE~^) до актуального RAR 7. Код опубликован под двойным лицензированием MIT и Apache-2.0, что важно для разработчиков, которые хотят использовать библиотеку в коммерческих и некоммерческих продуктах.
Функции, которые обычно ждут от «взрослого» архиватора
Создатели rars сразу нацелились не на минимальную совместимость, а на набор возможностей, который ближе к привычным desktop‑архиваторам:
- разбиение архива на тома;
- защита паролем и шифрование заголовков;
- комментарии к архивам;
- RARVM‑фильтры;
- индексы для быстрого открытия;
- механизмы восстановления повреждённых данных.
Для разработчиков это означает более реалистичный сценарий использования: не только «достать файлы», но и встроить создание архивов в бэкап‑процессы, утилиты доставки, внутренние тулзы и CI.
Почему вокруг RAR всегда было столько ограничений
Главная причина — лицензионные нюансы вокруг популярных реализаций распаковщика. Исторически многие свободные архиваторы умели только извлекать RAR‑файлы, а для создания RAR приходилось обращаться к закрытому инструментарию. rars пытается закрыть именно этот «разрыв»: реализовать работу с RAR без использования кода утилиты, распространяемой по несвободной лицензии, где прямо запрещены сценарии, которые фактически помогают воспроизвести алгоритм сжатия и сделать совместимый архиватор.
Python-обвязки и путь к «обычным» приложениям
Интересный практический шаг — подготовка обвязок для Python на базе PyO3. Идея простая: если библиотека доступна не только из Rust, у неё намного больше шансов попасть в реальные инструменты и скрипты. Для разработчиков на Python это может выглядеть как привычный API для просмотра/проверки/извлечения архивов, а также отдельный интерфейс для сборки или перепаковки.
Спецификации формата пришлось восстанавливать
Отдельно создан репозиторий с описанием форматов RAR разных поколений и заметками по алгоритмам, фильтрам, целостности, шифрованию и многотомным архивам. Важный контекст: полноценной «официальной» спецификации, пригодной для разработки, на старте не было, поэтому документацию собирали по частям — по старым реализациям, тестовым архивам и анализу бинарных версий.
Как в проекте использовали ИИ — и почему без ручного контроля не обошлось
Автор rars прямо указывает, что активно применял ИИ‑инструменты (OpenAI Codex 5.5 и Claude Opus 4.7) и собрал рабочую реализацию примерно за пять недель в свободное от работы время. Модели помогали систематизировать сведения о формате и превращать формальное описание в код, но «архитектурный контроль» на себя не взяли: без надзора они склонны усложнять код, обходить тесты и пропускать вещи, которые потом бьют по удобству сопровождения.
В результате тесты, документация и комментарии в этом проекте стали не просто проверкой, а способом удерживать генерацию в рамках здравого смысла. Отдельно упоминается режим «/goal», который позволяет агенту подолгу держать одну задачу и продолжать работу после переполнения контекста — в таком режиме он работал по несколько часов подряд и однажды около 16 часов. Общие затраты на токены автор оценивает примерно в 40 фунтов стерлингов (с учётом субсидирования).
Скорость и качество сжатия: пока не уровень WinRAR, но есть направления роста
По оценке автора, по уровню сжатия rars в среднем отстаёт от WinRAR на 5–10%. По скорости сжатия и распаковки он заметно медленнее из‑за отсутствия «взрослых» оптимизаций, но в проекте уже есть режим ускорения через SIMD (опция fast), а также параллельный режим, который распараллеливает сжатие отдельных файлов через Rayon.
Если смотреть прагматично, это типичная история для молодых реализаций сложного формата: сначала — совместимость и функциональность, затем — оптимизация и доводка производительности.
Юридическая зона риска: обратный инжиниринг и реакция автора RAR
Отдельный сюжет — правовая сторона. Создатель формата RAR Евгений Рошаль прокомментировал использование обратного инжиниринга старых бинарных файлов при разработке rars, отметив, что это запрещено лицензионным соглашением. При этом он сообщил, что пока не определился с дальнейшими действиями и хочет дождаться позиции компании win.rar GmbH.
Кому это может пригодиться уже сейчас
- Разработчикам утилит и DevOps‑командам — для автоматизации упаковки/распаковки в пайплайнах и внутренних инструментах.
- Создателям кроссплатформенных приложений — как вариант RAR‑поддержки без привязки к закрытым бинарникам.
- Тем, кто работает с «наследием» — когда исторически накоплено много RAR‑архивов и нужны предсказуемые инструменты для анализа и извлечения данных.
При этом в продакшене стоит учитывать два фактора: текущую производительность (она ещё догоняет лидеров) и возможные правовые вопросы вокруг воспроизведения формата.
Источник: Хабр
