gifts2017

Python V8Unpack

Опубликовал Егор Иванов (Infactum) в раздел Программирование - Инструментарий

В ряду анпакеров пополнение! Теперь и на Python.

Судя по количеству публикаций c реализацией алгоритма распаковки/запаковки контейнеров 1С их не писал только ленивый. Уже существуют решения на C++, Java, C#, Lua и много что еще. А теперь будет и на Python.

На самом делее реализация распаковщика не была основной целью. Но в рамках развития модуля onec_dtools, о котором я писал в своей прошлой публикации, была добавлена поддержка работы с контейнерами 1С. Так что я решил собрать небольшое консольное приложение, для демонстрации этих возможностей.

В приложенном к публикации файле есть как исходники, так и упакованный exe для тех, кому лениво ставить Python.

Само консольное приложение имеет 2 режима:

1. Распаковка контейнера (parse) в указанный каталог. При этом вложенные контейнеры разархивируются и рекурсивно распаковываются.

py8unpack.exe -P in_filename out_dir_name

2. Упаковка каталога (build) в контейнер. Операция, полностью обратная предыдущей.

py8unpack.exe -B in_dir_name out_filename

Скачать файлы

Наименование Файл Версия Размер
V8Unpack + src 11
.zip 3,90Mb
15.11.15
11
.zip 3,90Mb Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Егор Иванов (Infactum) 16.11.15 06:06
К слову, буду очень признателен, если кто-то поможет подобрать параметры zlib (или указать другую ошибку), которые позволят добиться полного совпадения исходного контейнера и результата упаковки. Сейчас они могут немного отличаться, хотя и успешно работали во всех проведенных мной тестах.
2. Андрей Овсянкин (Evil Beaver) 16.11.15 09:44
Вопрос "Нафига еще один unpack?" я задаю в каждом подобном топике. Наверное, не стоит нарушать традиций...

Нафига нам еще один unpack? Я не то чтоб хочу сказать, что он не нужен... Но в статье ни слова не сказано, про "зачем". Можно догадываться, а можно в статье рассказать подробнее - всем будет интересно.
3. Егор Иванов (Infactum) 16.11.15 09:59
(2) Evil Beaver,
Да нет какой-то особой цели. Вот вы, на сколько я знаю, чисто из академического интереса и не большой практической потребности, написали 1Script.
Я из тех же соображений делаю модуль для работы с данными 1С на Python. Начал с разбора 1CD, теперь добавил работу с контейнерами. У меня просто есть определенная идея (уже исключительно для моих личных целей), как я потом буду все это использовать. А библиотекой делюсь с сообществом абсолютно безвозмездно.
В перспективе, если сумею разобраться, хочу добавить в библиотеку возможность декомпиляции модулей, декомпиляции данных полей паролей (это просто и уже готово, просто в репозиторий пока не залил).
Что касается отдельно анпака: мне в существующем эталонном решении (V8Unpack на C++) не нравится то, что он во все проекты включен в качестве бинарника. В итоге тот же precommit1C представляет мешанину и Python, OS, C++ и по факту не является кроссплатформенным. Можно конечно взять бинарник под *nix, но мне больше симпатизирует вариант полной реализации на распространенном скриптовом языке. Python тут, имхо, лучший вариант. В общем я планирую, хотя бы чисто для себя, сделать форк precommit1C на чистом Python. Не разделяю я общего фанатизма сообщества, по переписыванию всего на OS.
4. Андрей Овсянкин (Evil Beaver) 16.11.15 10:13
(3) Infactum, ну я-то как раз Вас правильно понял, и рад, что в Вашем комментарии, получил подтверждение того, что вы не просто повторяете уже существующие инструменты, но и имеете какую-то четкую прикладную цель. Это прекрасно. Просто в статье этого не прозвучало совсем никак. Итого, мы, как сообщество - что можем понять об этой (вполне замечательной) разработке? Ну еще один unpack... На этот раз на Питоне... Ну ладно... И дело заглохло...

Слишком мало информации сообщили, вот что удручает. Это, как бы, совет на будущее )

С другой стороны, опять же, я сторонник улучшения существующих инструментов, а не повторения их. Но это уж каждый автор за себя решает, я могу только агитировать.
Не разделяю я общего фанатизма сообщества, по переписыванию всего на OS

Фанатизм (неправильное слово, скорее энтузиазм) мне лично понятен. Не надо учить язык, чтобы развивать инструмент, если его хочется чуть-чуть доработать. Оно ведь как получается - кто-то сделал классную штуку на powershell, кто-то на Python, кто-то на Lua, кто-то на BAT. Я хочу, все это использовать, но чтобы все это объединить и развить, мне сколько экосистем нужно выучить? А тут - всего одна, да еще и знакомая в значительной мере.
А вот кстати, почему вы скептически к этому энтузиазму относитесь? (я не из вредности спрашиваю, надеюсь понимаете;), а в поисках конструктива для улучшений)
5. Сергѣй Батанов (baton_pk) 16.11.15 10:15
Добро пожаловать в наш клуб!

Кстати, не сравнивали скорость работы?
minimajack; Evil Beaver; +2 Ответить 1
6. Егор Иванов (Infactum) 16.11.15 11:11
(4) Evil Beaver, касательно энтузиазма - я просто не вижу существенных плюсов OS перед тем же Python. Последний является одним из самых простых языков для изучения (даже детей сейчас зачастую обучают ему, как первому языку программирования) и вместе с тем одним из самых распространенных на различных платформах и не менее гибким. На мой взгляд для того, чтобы изучить питон на уровне, позволяющем писать программы, аналогичные возможностям OS нормальному программисту хватит рабочего дня.
В общем холивар разводить не хотелось бы. Скажу лишь, что многообразие экосистем сейчас встречается почти в любом серьезном проекте, и я обычно, не считаю его проблемой. Серьезный специалист (в том числе 1Сник) в любом случае в своем арсенале должен иметь хотя бы понимание основных языков. Понимание, это конечно не навык профессиональной разработки - это уровень, при котором можно внести минимальные правки. Под основными языками я (исключительно для себя) подразумеваю: JS (как основной язык веба), Java (C#) как стандарт Enterprise разработки, Python (для скриптов) и в идеале C++ (низкоуровневый софт).
(5) baton_pk, скорость работы как минимум сопоставима. Я правда на это упор не делал. Изначально хотел добиться низкого потребления памяти, чтобы ничего не падало на больших контейнерах. С запаковкой вроде бы все удачно, а вот на распаковкой еще стоит по работать.
Кстати сравнение скорости работы всех существующих решений очень не плохая идея для статьи..
7. Евгений Ванжула (minimajack) 16.11.15 11:26
(6) Infactum,
если выбирать скорость-память я буду выбирать скорость. Требования - что бы не падало - само собой.
8. Андрей Овсянкин (Evil Beaver) 16.11.15 11:29
(6) Infactum, я и не спорю с фактом необходимости знать несколько языков. И разнородность решений (когда есть компоненты, сделанные в разных языках/экосистемах) это тоже не зло. Но вы же не будете отрицать, что они сложнее и требуют специалистов более высокой квалификации? Это иногда невыгодно, вот и все. Не поймите неправильно, я совсем не призываю всех писать все на oscript. Каждый решает сам. Просто 1С-никам (мне, например) на oscript писать тупо проще, поскольку не надо учить Питон (хоть он и очень замечательный, никаких вопросов)

даже детей сейчас зачастую обучают ему, как первому языку программирования


А вот здесь я солидарен со Спольски. Учить программированию на простых языках - это плохо. Сначала что-то вроде Бэйсика для понимания концепций "переменная/условие/цикл", а потом C/C++. Тогда на выходе получится более качественный программист. Правда, Спольски говорил про обучение в ВУЗах, а не про детей, но идея понятна, в любом случае.
9. Егор Иванов (Infactum) 16.11.15 11:33
(7) minimajack, тут я с вами солидарен.
Я кстати смотрел вашу разработку и помню там была issue, что запакованные конфигурации медленно сравниваются конфигуратором. Удалось ли решить?
У меня после беглого взгляда на существующие решения сложилось мнение, что большинство из авторов пренебрегли некоторыми тонкостями: к примеру оглавление в стандартных контейнерах обычно разбито на несколько блоков: первый в начале контейнера длинной 512 байт и остальные в конце такими же блоками. Многие просто писали его целиком в самом начале. Аналогичная ситуация с размером блока по умолчанию. Платформа такие контейнеры обработает в любом случае, но влияет ли это на быстродействие самой платформы я не изучал.
10. Егор Иванов (Infactum) 16.11.15 11:39
(8) Evil Beaver, все верно. Для основных понятий Python и выбирают. Я как бы тоже считаю, что для дальнейшего качественного обучения нужно давать язык с явной типизацией и управлением памятью, чтобы потом поведение других языков не казалось "магией". Хотя может быть все дело в том, что нас так учили :)
11. Евгений Ванжула (minimajack) 16.11.15 11:46
(9) Infactum, нет решить не удалось...Этот ньюанс необходимо проверять.
зы я подозреваю что тут важен порядок файлов в системе: рут, версии - вначале например...
12. Андрей Овсянкин (Evil Beaver) 16.11.15 11:49
(10) Infactum,
Хотя может быть все дело в том, что нас так учили :)


Все придет к тому, что через двадцать лет программеры забудут что такое языки/компиляторы, которые дают нативный машинный код, будут программить для ОС, которая работает под silverlight, который работает в браузере, который написан на .NET, и запущено все это будет в какой-нибудь windows 7, а она в свою очередь будет работать в VmWare под линуксом. Среди программеров будут ходить слухи, что кто-то знает как программить не только под .NET, но и под windows и linux.

http://bash.im/quote/402319
Gruuush; shootnik; awa; +3 Ответить
13. Егор Иванов (Infactum) 27.12.15 19:11
Тем кому ранее эта тема была интересна, рекомендую заглянуть на гитхаб страницу проекта: https://github.com/Infactum/onec_dtools
А так же в оригинальную тему http://infostart.ru/public/412475/. Возможно найдутся желающие помочь мне с реализацией пары фич, чтобы довести проект до полностью завершенного состояния.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа