Судя по количеству публикаций 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
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
К слову, буду очень признателен, если кто-то поможет подобрать параметры zlib (или указать другую ошибку), которые позволят добиться полного совпадения исходного контейнера и результата упаковки. Сейчас они могут немного отличаться, хотя и успешно работали во всех проведенных мной тестах.
Вопрос «Нафига еще один unpack?» я задаю в каждом подобном топике. Наверное, не стоит нарушать традиций…
Нафига нам еще один unpack? Я не то чтоб хочу сказать, что он не нужен… Но в статье ни слова не сказано, про «зачем». Можно догадываться, а можно в статье рассказать подробнее — всем будет интересно.
(2) Evil Beaver,
Да нет какой-то особой цели. Вот вы, на сколько я знаю, чисто из академического интереса и не большой практической потребности, написали 1Script.
Я из тех же соображений делаю модуль для работы с данными 1С на Python. Начал с разбора 1CD, теперь добавил работу с контейнерами. У меня просто есть определенная идея (уже исключительно для моих личных целей), как я потом буду все это использовать. А библиотекой делюсь с сообществом абсолютно безвозмездно.
В перспективе, если сумею разобраться, хочу добавить в библиотеку возможность декомпиляции модулей, декомпиляции данных полей паролей (это просто и уже готово, просто в репозиторий пока не залил).
Что касается отдельно анпака: мне в существующем эталонном решении (V8Unpack на C++) не нравится то, что он во все проекты включен в качестве бинарника. В итоге тот же precommit1C представляет мешанину и Python, OS, C++ и по факту не является кроссплатформенным. Можно конечно взять бинарник под *nix, но мне больше симпатизирует вариант полной реализации на распространенном скриптовом языке. Python тут, имхо, лучший вариант. В общем я планирую, хотя бы чисто для себя, сделать форк precommit1C на чистом Python. Не разделяю я общего фанатизма сообщества, по переписыванию всего на OS.
(3) ну я-то как раз Вас правильно понял, и рад, что в Вашем комментарии, получил подтверждение того, что вы не просто повторяете уже существующие инструменты, но и имеете какую-то четкую прикладную цель. Это прекрасно. Просто в статье этого не прозвучало совсем никак. Итого, мы, как сообщество — что можем понять об этой (вполне замечательной) разработке? Ну еще один unpack… На этот раз на Питоне… Ну ладно… И дело заглохло…
Слишком мало информации сообщили, вот что удручает. Это, как бы, совет на будущее )
С другой стороны, опять же, я сторонник улучшения существующих инструментов, а не повторения их. Но это уж каждый автор за себя решает, я могу только агитировать.
Фанатизм (неправильное слово, скорее энтузиазм) мне лично понятен. Не надо учить язык, чтобы развивать инструмент, если его хочется чуть-чуть доработать. Оно ведь как получается — кто-то сделал классную штуку на powershell, кто-то на Python, кто-то на Lua, кто-то на BAT. Я хочу, все это использовать, но чтобы все это объединить и развить, мне сколько экосистем нужно выучить? А тут — всего одна, да еще и знакомая в значительной мере.
А вот кстати, почему вы скептически к этому энтузиазму относитесь? (я не из вредности спрашиваю, надеюсь понимаете;), а в поисках конструктива для улучшений)
Добро пожаловать в наш клуб!
Кстати, не сравнивали скорость работы?
(4) Evil Beaver, касательно энтузиазма — я просто не вижу существенных плюсов OS перед тем же Python. Последний является одним из самых простых языков для изучения (даже детей сейчас зачастую обучают ему, как первому языку программирования) и вместе с тем одним из самых распространенных на различных платформах и не менее гибким. На мой взгляд для того, чтобы изучить питон на уровне, позволяющем писать программы, аналогичные возможностям OS нормальному программисту хватит рабочего дня.
В общем холивар разводить не хотелось бы. Скажу лишь, что многообразие экосистем сейчас встречается почти в любом серьезном проекте, и я обычно, не считаю его проблемой. Серьезный специалист (в том числе 1Сник) в любом случае в своем арсенале должен иметь хотя бы понимание основных языков. Понимание, это конечно не навык профессиональной разработки — это уровень, при котором можно внести минимальные правки. Под основными языками я (исключительно для себя) подразумеваю: JS (как основной язык веба), Java (C#) как стандарт Enterprise разработки, Python (для скриптов) и в идеале C++ (низкоуровневый софт).
(5) baton_pk, скорость работы как минимум сопоставима. Я правда на это упор не делал. Изначально хотел добиться низкого потребления памяти, чтобы ничего не падало на больших контейнерах. С запаковкой вроде бы все удачно, а вот на распаковкой еще стоит по работать.
Кстати сравнение скорости работы всех существующих решений очень не плохая идея для статьи..
(6)
если выбирать скорость-память я буду выбирать скорость. Требования — что бы не падало — само собой.
(6) я и не спорю с фактом необходимости знать несколько языков. И разнородность решений (когда есть компоненты, сделанные в разных языках/экосистемах) это тоже не зло. Но вы же не будете отрицать, что они сложнее и требуют специалистов более высокой квалификации? Это иногда невыгодно, вот и все. Не поймите неправильно, я совсем не призываю всех писать все на oscript. Каждый решает сам. Просто 1С-никам (мне, например) на oscript писать тупо проще, поскольку не надо учить Питон (хоть он и очень замечательный, никаких вопросов)
А вот здесь я солидарен со Спольски. Учить программированию на простых языках — это плохо. Сначала что-то вроде Бэйсика для понимания концепций «переменная/условие/цикл», а потом C/C++. Тогда на выходе получится более качественный программист. Правда, Спольски говорил про обучение в ВУЗах, а не про детей, но идея понятна, в любом случае.
(7) minimajack, тут я с вами солидарен.
Я кстати смотрел вашу разработку и помню там была issue, что запакованные конфигурации медленно сравниваются конфигуратором. Удалось ли решить?
У меня после беглого взгляда на существующие решения сложилось мнение, что большинство из авторов пренебрегли некоторыми тонкостями: к примеру оглавление в стандартных контейнерах обычно разбито на несколько блоков: первый в начале контейнера длинной 512 байт и остальные в конце такими же блоками. Многие просто писали его целиком в самом начале. Аналогичная ситуация с размером блока по умолчанию. Платформа такие контейнеры обработает в любом случае, но влияет ли это на быстродействие самой платформы я не изучал.
(8) Evil Beaver, все верно. Для основных понятий Python и выбирают. Я как бы тоже считаю, что для дальнейшего качественного обучения нужно давать язык с явной типизацией и управлением памятью, чтобы потом поведение других языков не казалось «магией». Хотя может быть все дело в том, что нас так учили 🙂
(9) нет решить не удалось…Этот ньюанс необходимо проверять.
зы я подозреваю что тут важен порядок файлов в системе: рут, версии — вначале например…
(10)
Все придет к тому, что через двадцать лет программеры забудут что такое языки/компиляторы, которые дают нативный машинный код, будут программить для ОС, которая работает под silverlight, который работает в браузере, который написан на .NET, и запущено все это будет в какой-нибудь windows 7, а она в свою очередь будет работать в VmWare под линуксом. Среди программеров будут ходить слухи, что кто-то знает как программить не только под .NET, но и под windows и linux.
Тем кому ранее эта тема была интересна, рекомендую заглянуть на гитхаб страницу проекта:
А так же в оригинальную тему . Возможно найдутся желающие помочь мне с реализацией пары фич, чтобы довести проект до полностью завершенного состояния.
Можно ли как то провернуть следующую штуку:
После распаковки отчета/обработки на диск есть файл, например, с макетом, который начинается с заголовка файла и дальше xml.
Если изменить что -нибудь, обратно отчет собирается некорректно, вываливаясь с ошибкой при открытии в 1С.
Так вот соль в том, чтобы пересчитывать заголовок, у меня не хватает знаний. Может направите в правильную сторону?