Перепаковать архивы 7z в zip

← →
SergP © (2015-01-16 19:31) [0]

Имеются архивы 7z, нужно их перепаковать в zip, но процесс должен происходить автоматически, а не руками.
Дело в том, что данная операция у меня должна производиться cgi-скриптом, написанным на Дельфи, или запускаться из этого скрипта (например путем запуска winrar или даже *.bat файла)

Как это лучше сделать? А то пока ничего толкового в голову не приходит...
Например имеется файл filename.xlsx.p7s
его нужно перепаковать из 7z в zip и сохранить как filename.xlsx

Вариант тупо распаковать архив в папку, а потом опять заархивировать другим архиватором что-то мне не особо нравится...
Кстати, требуемая возможность по преобразованию архивов имеется в WinRar, но как ею воспользоваться из командной строки что-то не нашел...

← →
Dimka Maslov © (2015-01-16 20:02) [1]

Помнится у выньрара была библиотека по кодированию-раскодированию, которую можно было подключать к своим прогам.

← →
Jeer © (2015-01-16 20:22) [2]

Полагаю, что перепаковка все же производится методом распаковки и упаковки.

← →
кгшзх © (2015-01-16 20:32) [3]

Вариант тупо распаковать архив в папку, а потом опять заархивировать другим архиватором что-то мне не особо нравится...

а другого варианта не существует.
придется распаковывать и запаковывать.

архиватору нужно составить словарь данных (чистых данных)
а данные запакованы.
значит распаковываем стопудово.
затем запаковываем.

← →
Rouse_ © (2015-01-16 21:08) [4]

> Вариант тупо распаковать архив в папку, а потом опять заархивировать
> другим архиватором что-то мне не особо нравится...

Красиво рассказал :)
Как ты вообще это видишь по другому? Там даже таблицы не идентичны...

← →
Inovet © (2015-01-16 21:50) [5]

> [4] Rouse_ © (16.01.15 21:08)
> Как ты вообще это видишь по другому?

Поменять расширение, вдруг распакуется другим архиватором?

← →
SergP © (2015-01-16 21:55) [6]

>
> Красиво рассказал :)
> Как ты вообще это видишь по другому? Там даже таблицы не
> идентичны...

файлы у меня небольшие, порядка 10-40кб (архив), ну я подумал что сам процесс с распаковкой и записью этих файлов на диск с последующей упаковкой и удалением распакованных файлов как-то сильно мутный, ведь теоретически все это можно провернуть в памяти...

что касается винрара, пробовал так:
winrar cv -afzip -y filename.xlsx.p7s
но во первых: он не воспринимает указанные файлы, пока они имеют неизвестное ему расширение, если переименовать в filename.xlsx.7z то видит и перепаковывает.
во вторых: перепаковывать- то перепаковывает, но почему-то в формат rar, несмотря на ключ -afzip

Ну и можно попробовать поставить вопрос по другому:
Имеется некая программа (в моем случае cgi-скрипт), который запускает некое другое приложение, которое получает кучу разных файлов в определенной папке, далее мой скрипт копирует\переносит эти файлы в другие папки в зависимости от маски. теперь нужно добавить такую функцию: если встречаются файлы *.xlsx.p7s то при переносе их нужно походу преобразовать из 7z в zip и сменить имя на *.xlsx (т.е. отсечь ".p7s").
Как бы решили данную проблему мастера?

← →
Дмитрий С © (2015-01-16 23:17) [7]

7z.dll в помощь.

← →
Kilkennycat © (2015-01-16 23:29) [8]

[5] на 99% работает

← →
Германн © (2015-01-17 01:34) [9]

> ну я подумал что сам процесс с распаковкой и записью этих
> файлов на диск с последующей упаковкой и удалением распакованных
> файлов как-то сильно мутный, ведь теоретически все это можно
> провернуть в памяти...

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

← →
Германн © (2015-01-17 01:36) [10]

> теперь нужно добавить такую функцию: если встречаются файлы
> *.xlsx.p7s то при переносе их нужно походу преобразовать
> из 7z в zip и сменить имя на *.xlsx (т.е. отсечь ".p7s").
>

И что при этом получится?

← →
Kilkennycat © (2015-01-17 01:43) [11]

> распаковывать свои архивы в память

вообще-то, особой разницы нет, что файл, что память, и наверняка там в какой-нить стрим есть возможность.

← →
Германн © (2015-01-17 02:32) [12]

> Kilkennycat © (17.01.15 01:43) [11]
>
>
> > распаковывать свои архивы в память
>
> вообще-то, особой разницы нет, что файл, что память, и наверняка
> там в какой-нить стрим есть возможность.
>

Возможность есть всегда. Готовые функции не всегда есть.

← →
Игорь Шевченко © (2015-01-17 10:14) [13]

> файлы у меня небольшие, порядка 10-40кб (архив), ну я подумал
> что сам процесс с распаковкой и записью этих файлов на диск
> с последующей упаковкой и удалением распакованных файлов
> как-то сильно мутный, ведь теоретически все это можно провернуть
> в памяти...

В памяти еще более мутный. Надо делать просто, а не искать себе усложнений на вторые 90

← →
DVM © (2015-01-17 11:32) [14]

> если встречаются файлы *.xlsx.p7s то при переносе их нужно
> походу преобразовать из 7z в zip и сменить имя на *.xlsx
> (т.е. отсечь ".p7s").

p7s - это файл с подписью, точнее даже не так - подпись, содержащая файл. Наверное файл то надо сначала открепить от подписи, а не просто переименовывать, нет? Или это что-то другое?

← →
SergP © (2015-01-17 12:56) [15]

> p7s - это файл с подписью, точнее даже не так - подпись,
> содержащая файл. Наверное файл то надо сначала открепить
> от подписи, а не просто переименовывать, нет? Или это что-
> то другое?

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

Оказалось, что для этого не обязательно пользоваться специально-предназначеным для этого софтом, а достаточно преобразовать архив из 7z в zip, и сменить расширение.

← →
Rouse_ © (2015-01-17 15:25) [16]

> Inovet © (16.01.15 21:50) [5]
> Поменять расширение, вдруг распакуется другим архиватором?

Конечно, просто потому что есть такая вещь как сигнатура.
Вообще есть конечно один из вариантов.
Пишем два проксистрима, первый реализует распаковку, второй реализует паковку, но уже новым алго. На этапе получания данных в обеих стримах байтовый поток идет чистый.
Проблема в том что готовых прокси под 7z еще никто не писал (а под ZIP можно взять мой) :)

← →
SergP © (2015-01-17 16:58) [17]

ладно. Тогда может что-нить подскажете по winrar. В принципе меня устроит вариант его использования.
там есть команда cv - преобразование архивов.
но работать как я хочу оно не желает...
как я уже писал - не воспринимает файлы с расширением p7s, но если их переименовать в 7z то воспринимает... Ну Бог с ним, можно будет предварительно переименовывать файлы.

А вот то ключ -afzip не работает (архив из 7z преобразовывается в rar) это не подходит... Может там какие-то еще ключи нужно использовать?

← →
Rouse_ © (2015-01-17 17:44) [18]

Таки можно сделать перепаковку в памяти:

http://www.delphitop.com/html/yasuo/1867.html

Если файлы маленькие, то банально заспаковываем их во временные стримы (в памяти), и с сохранением структуры пишем обратно оть сюда: http://rouse.drkb.ru/components.php#fwzip

Не будет работать на обьемах от 3 гигов и выше (ибо в данном случае FWZip просто не сможет все это уместить в АПП).

← →
Кто б сомневался © (2015-01-17 22:08) [19]

А нафига их перепаковывать? Может проще будет сделать поддержку 7z?
Архиватор популярный ведь и бесплатный.

А вообще алгоритм простой - распаковываем вызывая 7z.exe через свой cgi в отдельную папку.
Ждем закрытия.

Запаковываем в zip эту папку, опять же через 7z.exe командную строку.
Там работы то ерунда.

Перепаковка в памяти? Зачем такой велосипед? Ведь это создаст ограничения с размером файлов, да и памяти на серверах не так много свободной.

← →
Кто б сомневался © (2015-01-17 22:26) [20]

На всякий случай:
Все команды 7z.exe описаны в 7-zip.chm в папке с прогой.

← →
Кто б сомневался © (2015-01-17 22:30) [21]

> там есть команда cv - преобразование архивов.
> но работать как я хочу оно не желает...

Потому что распаковывать *.7z надо только в 7z.exe - т.к. там могут быть разные методы сжатия lzma, lzma2, ppmd, bzip2 - тут даже плагин 7z для тотала не все их поддерживает.

← →
Германн © (2015-01-18 02:22) [22]

> Rouse_ © (17.01.15 17:44) [18]
>
> Таки можно сделать перепаковку в памяти:
>
> http://www.delphitop.com/html/yasuo/1867.html
>

Ну блин. Китайцы всё могут. :)

← →
Inovet © (2015-01-18 02:47) [23]

> [0] SergP © (16.01.15 19:31)
> Кстати, требуемая возможность по преобразованию архивов
> имеется в WinRar

А Rar разве без распаковки в папку пережимает?

← →
brother © (2015-01-18 11:22) [24]

имхо, при чем тут делфи? пишем батник!

← →
SergP © (2015-01-18 11:59) [25]

> А нафига их перепаковывать? Может проще будет сделать поддержку
> 7z?

внести изменения в Майкрософт оффис, ради того чтобы он понимал xlsx запакованные 7z - не думаю что это будет проще. )))

← →
RWolf © (2015-01-19 10:33) [26]

Я бы записал макрос для FAR и не морочил себе голову программированием.

← →
Труп Васи Доброго © (2015-01-20 11:20) [27]

> ведь теоретически все это можно провернуть в памяти...

Это и практически можно, без программирования.
Делай в памяти диск с помощью RAMDisk "Enterprise" (бесплатно) или любой другой.
Дальше пишешь батник по распаковке-упаковке на этом диске, если объёмы данных>>объёма RAM диска, то перепаковывай порциями.
Дел на три копейки, тебе сделать было бы быстрее, чем ты спрашиваешь.

← →
Jeer © (2015-01-21 22:24) [28]

>Делай в памяти диск с помощью

Странно, что кто-то еще обходится без RAM-диска для файловых операций.
У меня всегда висит один гиг для таких целей.

Еще полезное дело - TruCrypt ( к примеру ), как контейнер для мелко-раздробленных файлов.
Есть несколько контейнеров, один из которых наиболее объемный - 300 Гиг для кэширования мозаик ( sat и map ) в GIS-среде SAS-planet.

>Jeer © (21.01.15 22:24) [28]

в тему контейнеров

при переносе тучи мелких файлов на медленный носитель(например usb v1), часто использовал winrar (опции: без сжатия, доп инфа для восстановления - для перестраховки)

запись в один файл много быстрее копирования кучи мелких файлов

>запись в один файл много быстрее копирования кучи мелких файлов

Да.

У меня режим быстрого сжатия работает быстрее чем режим без сжатия.

> Jeer © (21.01.15 22:24) [28]
> Странно, что кто-то еще обходится без RAM-диска для файловых операций.

ничего странного. блок питания сдохнет, ищи потом диск в памяти...

[32] так мы говорим же о промежуточном использовании?

>Kilkennycat © (24.01.15 03:10) [32]
>ничего странного. блок питания сдохнет, ищи потом диск в памяти...

Автоматом при shutdown ram-disk сохраняется на HDD.

> [28] Jeer © (21.01.15 22:24)
> Странно, что кто-то еще обходится без RAM-диска для файловых операций.

Может и странно, но не люблю я костыли, тем более отпиленные. В общем для меня не надо, а если где-то такое и полезно - значит, пусть будет. (Неужели с этим не приходится гемороиться.)

>Inovet © (24.01.15 19:37) [35]
>Может и странно...

Ну вот, вместо HDD - у тебя сейчас 1..1000 терабайт в памяти и оно как-то быстро сохраняется (где-то там) при выключении и восстанавливается (откуда-то там) при включении.
Ты, лично - против?

Ну так вот, это уже реальность.

> [36] Jeer © (25.01.15 02:23)

Я к чему говорю. Вообще-то ОСь дожна бы этим (кэшированием) заниматься, она и занимается, но не эффективно, видимо, не всё так просто. Т.е. в идеале мой(и) HDD должен(ны) целиком мапироваться на (свободное) ОЗУ, и тогда в костыле РАМдиска не должно быть смысла. Но реальность, как обычно, далека от идеала.

Сохранение при включении-выключении - это понятно... о если сдох блок питания, что не такая уж редкость, то сохранение несколько проблематично, на материнке есть батарейка, конечно, но ее не хватит :) впрочем, везде есть золотая середина. я видел подобное применение на сервере для ускорения работы с 1с - это ужасно рискованно. Для домашнего применения - почему нет...
Но я бы лучше собрал рэйд. Дорого, но надежно.
Да и необязательно проблема с питанием. ОС тоже может добавит сюрпризов.

>kilkennycat © (26.01.15 03:04) [38]

Для домашнего применения это не особо критично, тем более, что использование диска в памяти - только на относительно короткое время.
Для серверных применений - самое-то, да и блоки питания там с резервированием, если это, конечно не обычный комп, гордо названный сервером.

> Но я бы лучше собрал рэйд. Дорого, но надежно.

Скузи за вопрос, но каким боком рэйд поможет при сдыхании блока питания? ЕМНИП, текущие данные (не сохранённые) всё равно сидят в оперативке, так что рэйд не поможет, результат работы нулевой.
А про какую опасность вообще идёт речь? В сабжевой задаче данные (архивы 7z) уже хранятся на винте и им ничто не угрожает. Перепакованные архивы (ZIP) тоже будут храниться на винте. Вопрос - чем им угрожает RAM диск?
Пишется батник, либо программка такого плана:
Выбрать из источника файлы, общим объёмом < (RAMдиск - размер самого большого файла из списка в распакованном виде * 2)
Запустить перепаковщик по этому списку файлов, с сохранением результатов на RAM:
пока не кончились файлы 7z
Взять файл из списка, перепаковать на RAM диск, удалить исходный файл с RAM диска.
Перенести файлы ZIP в место постоянного хранения.
Удалить файлы 7z в исходном месте
Взять следующую порцию файлов.
ВСЁ!
В каком месте тут надо бояться RAM диска?
Ну отключится свет и что? Исчезнут данные на RAM диске, но исходные и конечные архивы то находятся на винтах.

Перепаковать архивы 7z в zip Найти похожие ветки