» 7-Zip / 7z
Bulat_Ziganshin
Цитата:
ты предлагаешь попробовать их по-отдельности? или может одновременно?
-m0=deflate -m1=bzip2 -mx1
Цитата:
поясни про отдельный поток
Цитата:
быстрее будет сжимать в deflate/bzip2
ты предлагаешь попробовать их по-отдельности? или может одновременно?
-m0=deflate -m1=bzip2 -mx1
Цитата:
ещё быстрее (как это ни странно) будет сжимать в формат zip - 7z при этом может использовать отдельныей поток на каждый сжимаемый файл
поясни про отдельный поток
Привет всем!
Недавно я придумал и осуществил свой небольшой тест на "ум" архиваторов. Идея проста: посмотреть, как будет вести себя архиватор при упаковке файла, который заведомо нельзя сжать. Для этого я создал файл размером 6 250 000 байт, представляющий собой (в двоичном виде) 50 млн. знаков двоичного представления числа Pi (до настоящего времени не было найдено никаких закономерностей в знаках числа Pi, независимо от того, в какой системе счисления оно представлено), используя следующую программу в среде Mathematica:
In[1]:= Export["C:\Pi.txt", First@RealDigits[Pi, 2, 5*10^7], "Bit"]
Out[1]= C:\Pi.txt
Далее полученный файл я упаковал, используя в обоих случаях максимальное сжатие, архиваторами WinRAR 3.80 ("Метод сжатия:" "Максимальный") и 7-Zip 4.62 ("Уровень сжатия:" "Ультра"), остальные параметры компрессии оставил по умолчанию в обоих случаях. Вот результаты:
WinRAR - создал архив, на 84 байта больший исходного файла, причём этот архив содержал исходный файл в несжатом виде (проверяется поиском подстроки из исходного файла внутри созданного архива).
7-Zip - создал архив размером 6 335 026 байт (на 85026 байт больше исходного файла), причём внутри архива подстроку из исходного файла найти не удалось: значит, 7-Zip "сжал" исходный файл, несмотря на то, что размер в результате существенно вырос!
P.S. Это вовсе не к тому, что 7-Zip плох, просто ему есть ещё куда развиваться... Вполне возможно, подобные проблемы возникают и при упаковке сжатых картинок (в форматах .JPG, .JP2 и др.), но это требует уже дополнительного исследования. Пишу о том, что сам нарыл.
Недавно я придумал и осуществил свой небольшой тест на "ум" архиваторов. Идея проста: посмотреть, как будет вести себя архиватор при упаковке файла, который заведомо нельзя сжать. Для этого я создал файл размером 6 250 000 байт, представляющий собой (в двоичном виде) 50 млн. знаков двоичного представления числа Pi (до настоящего времени не было найдено никаких закономерностей в знаках числа Pi, независимо от того, в какой системе счисления оно представлено), используя следующую программу в среде Mathematica:
In[1]:= Export["C:\Pi.txt", First@RealDigits[Pi, 2, 5*10^7], "Bit"]
Out[1]= C:\Pi.txt
Далее полученный файл я упаковал, используя в обоих случаях максимальное сжатие, архиваторами WinRAR 3.80 ("Метод сжатия:" "Максимальный") и 7-Zip 4.62 ("Уровень сжатия:" "Ультра"), остальные параметры компрессии оставил по умолчанию в обоих случаях. Вот результаты:
WinRAR - создал архив, на 84 байта больший исходного файла, причём этот архив содержал исходный файл в несжатом виде (проверяется поиском подстроки из исходного файла внутри созданного архива).
7-Zip - создал архив размером 6 335 026 байт (на 85026 байт больше исходного файла), причём внутри архива подстроку из исходного файла найти не удалось: значит, 7-Zip "сжал" исходный файл, несмотря на то, что размер в результате существенно вырос!
P.S. Это вовсе не к тому, что 7-Zip плох, просто ему есть ещё куда развиваться... Вполне возможно, подобные проблемы возникают и при упаковке сжатых картинок (в форматах .JPG, .JP2 и др.), но это требует уже дополнительного исследования. Пишу о том, что сам нарыл.
popkov
ну я к примеру нек раз наблюдал ситуацию когда 7зип с макссжатием сжимал хуже простого зип - это как раз и зависело от "сжимаемости" файла
Цитата:
я и Игорь без сомнения с тобой согласимся
ну я к примеру нек раз наблюдал ситуацию когда 7зип с макссжатием сжимал хуже простого зип - это как раз и зависело от "сжимаемости" файла
Цитата:
просто ему есть ещё куда развиваться...
я и Игорь без сомнения с тобой согласимся
Шапку обновил.
Verwolk
Дополню: что есть и что изменилось: 7z463-ia64.msi, 7z463-x64.msi, 7z463.exe, 7z463.msi, 7z463.tar.bz2, 7z463_extra.7z, 7za463.zip, lzma463.tar.bz2
Цитата:
Что ещё не обновилось:
На английской странице - версия LZMA SDK - там ссылка на 4.62, текущая 4.63, русская страница.
Verwolk
Дополню: что есть и что изменилось: 7z463-ia64.msi, 7z463-x64.msi, 7z463.exe, 7z463.msi, 7z463.tar.bz2, 7z463_extra.7z, 7za463.zip, lzma463.tar.bz2
Цитата:
4.63 2008-12-31
-------------------------
- 7-Zip now can unpack ZIP archives encrypted with PKWARE-AES.
- Some bugs were fixed.
Что ещё не обновилось:
На английской странице - версия LZMA SDK - там ссылка на 4.62, текущая 4.63, русская страница.
euheny
Цитата:
Вообще говоря, способность 7-Zip "сжимать" с увеличением размера - это очень серьёзная, даже критическая недоработка. Удивительно, что уже версия 4.63, а элементарного сопоставления размеров "упакованного" файла и оригинального (с последующим включением в архив наименьшего из них) - до сих пор не сделано! Такие вещи должны реализовываться на самых первых стадиях разработки программы, а тут такая длинная история - и такой глупый ляп...
Цитата:
ну я к примеру нек раз наблюдал ситуацию когда 7зип с макссжатием сжимал хуже простого зип - это как раз и зависело от "сжимаемости" файла
Вообще говоря, способность 7-Zip "сжимать" с увеличением размера - это очень серьёзная, даже критическая недоработка. Удивительно, что уже версия 4.63, а элементарного сопоставления размеров "упакованного" файла и оригинального (с последующим включением в архив наименьшего из них) - до сих пор не сделано! Такие вещи должны реализовываться на самых первых стадиях разработки программы, а тут такая длинная история - и такой глупый ляп...
popkov
Согласен, имеется такой факт, но забавно, что этот "эффект" встречается практически во всех архиваторах.
И причина, как мне думается в том, что оценить сжимаемость можно только после получения статистики файла, а это время, зачастую соизмеримое со временем сжатия. Да и вероятность встретится с подобным файлом исчезающе мала, и асимптотически стремится к нулю. Так есть ли смысл в подобной операции? Только время терять. Конечно можно предложить сверхбыстрый алгоритм оценки сжимаемости на основе b-Tree, только кто предоставить статистику для создания достоверных оценочных таблиц? У меня её в нужном объёме под рукой нет.
Для подобной оценки если мне не меняет память, нужно не менее 1037 - 1038 отсчётов. Мне лет пятнадцать тому назад пришлось решать подобную задачу для сжатия случайного битового потока. Оказалось проще сделать ряд допущений, т.к. точности инженерного расчёта в 1% - 1,5% для решения подобно задачи более чем достаточно. Да, и кроме того, эта задача программно-алгоритмически, извини вообще-то даже символьного решения не имеет, а о количественном я уже вообще молчу. Она может быть решена только на специализированном аппаратно-программном комплексе с управляемой потоковой компрессией. Иначе время решения быстро устремляется к бесконечности.
А твоё решение просто не удачно потому, что:
1) надо сначала сжать файл, потом сравнить длины и принять решение о копировании минимального в архив.
2) задаваемая опция алгоритма "копировать в архив файл минимально длинны" может оказаться не применимой в данном режиме сжатия.
Можно сделать иначе - использовать маски исключений, и файлы попадающие под них не сжимая добавлять в архив. Но, иные архивы отлично сжимаются, а иные битовые потоки могут вообще быть не сжимаемыми. Смотри выше.
Согласен, имеется такой факт, но забавно, что этот "эффект" встречается практически во всех архиваторах.
И причина, как мне думается в том, что оценить сжимаемость можно только после получения статистики файла, а это время, зачастую соизмеримое со временем сжатия. Да и вероятность встретится с подобным файлом исчезающе мала, и асимптотически стремится к нулю. Так есть ли смысл в подобной операции? Только время терять. Конечно можно предложить сверхбыстрый алгоритм оценки сжимаемости на основе b-Tree, только кто предоставить статистику для создания достоверных оценочных таблиц? У меня её в нужном объёме под рукой нет. Для подобной оценки если мне не меняет память, нужно не менее 1037 - 1038 отсчётов. Мне лет пятнадцать тому назад пришлось решать подобную задачу для сжатия случайного битового потока. Оказалось проще сделать ряд допущений, т.к. точности инженерного расчёта в 1% - 1,5% для решения подобно задачи более чем достаточно. Да, и кроме того, эта задача программно-алгоритмически, извини вообще-то даже символьного решения не имеет, а о количественном я уже вообще молчу. Она может быть решена только на специализированном аппаратно-программном комплексе с управляемой потоковой компрессией. Иначе время решения быстро устремляется к бесконечности. А твоё решение просто не удачно потому, что:
1) надо сначала сжать файл, потом сравнить длины и принять решение о копировании минимального в архив.
2) задаваемая опция алгоритма "копировать в архив файл минимально длинны" может оказаться не применимой в данном режиме сжатия.
Можно сделать иначе - использовать маски исключений, и файлы попадающие под них не сжимая добавлять в архив. Но, иные архивы отлично сжимаются, а иные битовые потоки могут вообще быть не сжимаемыми. Смотри выше.
Victor_VG
Цитата:
Первый аргумент не выдерживает никакой критики: если нет эффективного алгоритма оценки, надо сжимать - но если в результате вышла лажа, надо помещать в архив исходный файл и не издеваться над пользователем. Ну или хотя бы спросить его: ему нужен архив, больший чем исходный файл, но "сжатый" (а значит, при извлечении ещё и на распаковку дополнительное процессорное время будет потрачено) или же ему просто нужен архив наименьшего возможного размера (что всем без исключения и нужно - иначе зачем вообще нужна компрессия - используй ISO без сжатия как контейнер - и порядок! Гораздо удобнее - даже распаковывать не придётся, нужно просто монтировать как виртуальный диск).
Цитата:
Цитата:
В WinRAR (по крайней мере, при упаковке единственного файла) - не встречается (см. выше). Так что "почти" здесь неуместно. Приведи конкретные примеры. Да и вообще - даже если и есть такие кривые архиваторы - зачем с них брать пример?
Цитата:
А твоё решение просто не удачно потому, что:
1) надо сначала сжать файл, потом сравнить длины и принять решение о копировании минимального в архив.
Первый аргумент не выдерживает никакой критики: если нет эффективного алгоритма оценки, надо сжимать - но если в результате вышла лажа, надо помещать в архив исходный файл и не издеваться над пользователем. Ну или хотя бы спросить его: ему нужен архив, больший чем исходный файл, но "сжатый" (а значит, при извлечении ещё и на распаковку дополнительное процессорное время будет потрачено) или же ему просто нужен архив наименьшего возможного размера (что всем без исключения и нужно - иначе зачем вообще нужна компрессия - используй ISO без сжатия как контейнер - и порядок! Гораздо удобнее - даже распаковывать не придётся, нужно просто монтировать как виртуальный диск).
Цитата:
2) задаваемая опция алгоритма "копировать в архив файл минимально длинны" может оказаться не применимой в данном режиме сжатия.Единственный такой режим - Solid Archiv. В нём можно этого не делать, но, по-хорошему, алгоритм должен быть таков, чтобы во всех режимах всё получалось как надо - а не как попало!
Цитата:
но забавно, что этот "эффект" встречается практически во всех архиваторах
В WinRAR (по крайней мере, при упаковке единственного файла) - не встречается (см. выше). Так что "почти" здесь неуместно. Приведи конкретные примеры. Да и вообще - даже если и есть такие кривые архиваторы - зачем с них брать пример?
popkov
Цитата:
Считайте фичей WinRAR-а
Цитата:
Может для автора 7-Zip приемлимы потери "1-1.5%" в таких случаях.
Ды и функционал архиватора по нынешним временам достаточно "спортанский".
Цитата:
В WinRAR (по крайней мере, при упаковке единственного файла)
Считайте фичей WinRAR-а
Цитата:
надо помещать в архив исходный файл и не издеваться над пользователем
Может для автора 7-Zip приемлимы потери "1-1.5%" в таких случаях.
Ды и функционал архиватора по нынешним временам достаточно "спортанский".
popkov
"Кривые архиваторы": tar, cpio (UNIX) - по умолчанию вообще не сжимают объекты файловой системы, просто помещает их в выходной контейнер, но могут использовать аппаратное сжатие в стримерах (LZ023/deflate, сжатие 2:1 на ленту).
По п.1) А что касается "аргументов не выдерживающих критики", то извини, это твоё предложение, не моё - "сопоставления размеров "упакованного" файла и оригинального (с последующим включением в архив наименьшего из них" . Значит я так понимаю, что ты согласен с тем что это твоё предложение ошибочно?
И по п. 2) - любой метод сжатия входного потока кроме прямого отображения исходного потока на выходной подразумевает обязательную обработку входного потока с применение основного алгоритма метода. И исключения из процесса отдельных объектов автоматически приводит к изменению самого алгоритма. А это прости, уже задача Буриданова осла - как сохранить алгоритм в первоначальное его форме, и одновременно включить в него не свойственные ему функции не изменяя сам алгоритм.
Ну и по поводу твоего эксперимента - а ты смотрел эти "85026" байт? Что там, не как текст, а как бинарный код? Дело в том, что заголовок архива + словарь сжатия при такой длине случайного потока не могут получится столь малы. Минимальная длинна заголовка 23 байт, метод сжатия по умолчанию LZMA /SOLID словарь 8 Мб, блок 8 Мб, слово 64 Байт. Так, что "впритык" никак не выйдет - даже если файл скопирован в контейнер без сжатия, служебные структуры заголовка, словаря и статистики свободно займут эти 85026 байт. У RAR иной заголовок - его длинна 22 байт, а служебные данные расположены иначе, и вне заголовка.
Так, что ты вновь вступил в противоречие с собственными аргументами. Ищи другие, и более убедительные. Эти опровергаются элементарно.
"Кривые архиваторы": tar, cpio (UNIX) - по умолчанию вообще не сжимают объекты файловой системы, просто помещает их в выходной контейнер, но могут использовать аппаратное сжатие в стримерах (LZ023/deflate, сжатие 2:1 на ленту).
По п.1) А что касается "аргументов не выдерживающих критики", то извини, это твоё предложение, не моё - "сопоставления размеров "упакованного" файла и оригинального (с последующим включением в архив наименьшего из них" .
Значит я так понимаю, что ты согласен с тем что это твоё предложение ошибочно? И по п. 2) - любой метод сжатия входного потока кроме прямого отображения исходного потока на выходной подразумевает обязательную обработку входного потока с применение основного алгоритма метода. И исключения из процесса отдельных объектов автоматически приводит к изменению самого алгоритма. А это прости, уже задача Буриданова осла - как сохранить алгоритм в первоначальное его форме, и одновременно включить в него не свойственные ему функции не изменяя сам алгоритм.
Ну и по поводу твоего эксперимента - а ты смотрел эти "85026" байт? Что там, не как текст, а как бинарный код? Дело в том, что заголовок архива + словарь сжатия при такой длине случайного потока не могут получится столь малы. Минимальная длинна заголовка 23 байт, метод сжатия по умолчанию LZMA /SOLID словарь 8 Мб, блок 8 Мб, слово 64 Байт. Так, что "впритык" никак не выйдет - даже если файл скопирован в контейнер без сжатия, служебные структуры заголовка, словаря и статистики свободно займут эти 85026 байт. У RAR иной заголовок - его длинна 22 байт, а служебные данные расположены иначе, и вне заголовка.
Так, что ты вновь вступил в противоречие с собственными аргументами. Ищи другие, и более убедительные. Эти опровергаются элементарно.
Victor_VG
Цитата:
7-Zip сжимает не сжимаемые данные с небольшим минусом - "1-1.5%"
Из прдепоследнего:
http://forum.ru-board.com/topic.cgi?forum=5&topic=1406&start=1540#2
Цитата:
Цитата:
Ну и по поводу твоего эксперимента
7-Zip сжимает не сжимаемые данные с небольшим минусом - "1-1.5%"
Из прдепоследнего:
http://forum.ru-board.com/topic.cgi?forum=5&topic=1406&start=1540#2
Цитата:
740 372 426 байт - 2008-11-23 Solo.v9.0.2.4cd.exe (в 7z SFX) - http://img242.imageshack.us/img242/148/33zq4.gif
731 832 320 байт - 2008-11-21 Solo.v9.0.2.4cd.iso
egor23
Цитата:
Проверил (встроенными в Mathematica средствами упаковки в стандартные форматы): ZIP и GZIP также не стали "сжимать" файл, а поместили его в контейнер таким, какой он есть. "Отличился" только BZIP2 (размер файла вырос до 6 277 173 байт).
Общий вывод: разработчики старых-добрых форматов (GZIP, ZIP, RAR) таких ляпов не делали. Разработчики новых, похоже, разучились видеть очевидное...
[no]In[1]:=
SetDirectory[NotebookDirectory[]]
PiFile=Import["Pi.txt","Binary"];
{#,FileByteCount[#]}&@"Pi.txt"
{#,FileByteCount[#]}&@Export["Pi.txt.zip",{PiFile},{"ZIP",{{"Pi.txt","Binary"}}}]
{#,FileByteCount[#]}&@Export["Pi.txt.bz2",{PiFile},{"BZIP2","Binary"}]
{#,FileByteCount[#]}&@Export["Pi.txt.gz",{PiFile},{"GZIP","Binary"}]
Out[1]= D:\DESKTOP\Pi
Out[2]= [/no]{Pi.txt,6250000}
Out[3]= {Pi.txt.zip,6252036}
Out[4]= {Pi.txt.bz2,6277173}
Out[5]= {Pi.txt.gz,6251928}
Цитата:
Считайте фичей WinRAR-а
Проверил (встроенными в Mathematica средствами упаковки в стандартные форматы): ZIP и GZIP также не стали "сжимать" файл, а поместили его в контейнер таким, какой он есть. "Отличился" только BZIP2 (размер файла вырос до 6 277 173 байт).
Общий вывод: разработчики старых-добрых форматов (GZIP, ZIP, RAR) таких ляпов не делали. Разработчики новых, похоже, разучились видеть очевидное...
[no]In[1]:=
SetDirectory[NotebookDirectory[]]
PiFile=Import["Pi.txt","Binary"];
{#,FileByteCount[#]}&@"Pi.txt"
{#,FileByteCount[#]}&@Export["Pi.txt.zip",{PiFile},{"ZIP",{{"Pi.txt","Binary"}}}]
{#,FileByteCount[#]}&@Export["Pi.txt.bz2",{PiFile},{"BZIP2","Binary"}]
{#,FileByteCount[#]}&@Export["Pi.txt.gz",{PiFile},{"GZIP","Binary"}]
Out[1]= D:\DESKTOP\Pi
Out[2]= [/no]{Pi.txt,6250000}
Out[3]= {Pi.txt.zip,6252036}
Out[4]= {Pi.txt.bz2,6277173}
Out[5]= {Pi.txt.gz,6251928}
egor23
popkov
Убедили. Такие аргументы убедительны.
popkov
Убедили. Такие аргументы убедительны.
объясните пожалуйста что значит архивация, точнее какие ее минусы?
popkov
Victor_VG
egor23
Да это не секрет что 7зип имеет недостатки. Мне они неприятны.
Но лучше архиватора я не знаю. Будем мирится и надеяться на исправление багов. В этом сама жизнь
Victor_VG
egor23
Да это не секрет что 7зип имеет недостатки. Мне они неприятны.
Но лучше архиватора я не знаю. Будем мирится и надеяться на исправление багов. В этом сама жизнь
euheny
Поддерживаю, но и достоинство подкину - 7Zip распаковывает zip архивы с "неверной" для Windows полем заголовка ushort frVersion = 778. PKZip/PKUnzip любой версии меньшей чем 8-я выведет на каждый файл по предупреждению W3 и общее сообщение об ошибке E9 без распаковки архива. Он не проверяет, что этот номер версии libzip (UNIX), и не распаковывает архив.
Trava79
"Пулемёт" - хотфиксы версии как грибы после дождя. Шапку я поправил, а вот LZMA SDK Игорь не стал обновлять - там нет исправленных в 7-zip ошибок:
Цитата:
Поддерживаю, но и достоинство подкину - 7Zip распаковывает zip архивы с "неверной" для Windows полем заголовка ushort frVersion = 778. PKZip/PKUnzip любой версии меньшей чем 8-я выведет на каждый файл по предупреждению W3 и общее сообщение об ошибке E9 без распаковки архива. Он не проверяет, что этот номер версии libzip (UNIX), и не распаковывает архив.
Trava79
"Пулемёт" - хотфиксы версии как грибы после дождя.
Шапку я поправил, а вот LZMA SDK Игорь не стал обновлять - там нет исправленных в 7-zip ошибок: Цитата:
4.64 2009-01-03
-------------------------
- The bug in 7-Zip 4.63 was fixed: 7-Zip could not decrypt .ZIP archives encrypted with WinZip-AES method.
Victor_VG
C zip 7Zip работает на "ура". Мне же неприятно, что отсутствует функция добавления файлов к существующим архивам, за исключением этого самого zip. Даже в "родной" формат 7z мне добавлять файлы не удавалось.
C zip 7Zip работает на "ура". Мне же неприятно, что отсутствует функция добавления файлов к существующим архивам, за исключением этого самого zip. Даже в "родной" формат 7z мне добавлять файлы не удавалось.
gjf
Пересылка/удаление в Zip так же блокированы, хотя добавление/обновление файлов возможно. Может это особенность плугина для Far?
Пересылка/удаление в Zip так же блокированы, хотя добавление/обновление файлов возможно. Может это особенность плугина для Far?
euheny
Цитата:
Ну я не соглашусь: под лежачий камень вода не течёт! Сидеть тихо как мышь и мириться - значит, баги никогда и не будут исправлены!
Цитата:
Но лучше архиватора я не знаю. Будем мирится и надеяться на исправление багов. В этом сама жизнь
Ну я не соглашусь: под лежачий камень вода не течёт! Сидеть тихо как мышь и мириться - значит, баги никогда и не будут исправлены!
popkov
Пиши Игорю. Баг репорты он же учитывает.
Пиши Игорю. Баг репорты он же учитывает.
Вообще говоря, это даже не баг, а фундаментальная недоработка на самых первых стадиях разработки алгоритма.
Кстати, а откуда родом Игорь? Он этот форум не посещает?
Чё-то не нашёл на оффсайте его E-Mail.
Да и вообще: мне эта тема одному интересна - или всё-таки есть ещё понимающие и заинтересованные люди?
Кстати, а откуда родом Игорь? Он этот форум не посещает?
Чё-то не нашёл на оффсайте его E-Mail.
Да и вообще: мне эта тема одному интересна - или всё-таки есть ещё понимающие и заинтересованные люди?
Victor_VG
Я не плугином работаю, а родной оболочкой 7Zipa.
Я не плугином работаю, а родной оболочкой 7Zipa.
gjf
Цитата:
"Этого не может быть, потому что этого не может быть никогда". Может, ты только solid архивы имеешь ввиду? А другие форматы - где как. В rar не пакует, естесственно, он платный.
Victor_VG
Цитата:
Удаление работает -
"Delete"="7z d {-p%%P} -r0 {-w%%W} -scsDOS -- %%A @%%LQMN"
Цитата:
Мне же неприятно, что отсутствует функция добавления файлов к существующим архивам, за исключением этого самого zip. Даже в "родной" формат 7z мне добавлять файлы не удавалось
"Этого не может быть, потому что этого не может быть никогда". Может, ты только solid архивы имеешь ввиду? А другие форматы - где как. В rar не пакует, естесственно, он платный.
Victor_VG
Цитата:
Пересылка/удаление в Zip так же блокированы, хотя добавление/обновление файлов возможно. Может это особенность плугина для Far?
Удаление работает -
"Delete"="7z d {-p%%P} -r0 {-w%%W} -scsDOS -- %%A @%%LQMN"
как сделать bat-файл, который мог вводить пароль в архив и разархивировать его?
Добавлено:
уже разобрался!)
Добавлено:
и еще как узнать какой объем памяти потребуется для разархивации архива?
Добавлено:
уже разобрался!)
Добавлено:
и еще как узнать какой объем памяти потребуется для разархивации архива?
lorents
Вы упорно не хотите почитать справку, а напрасно:
Цитата:
Вы упорно не хотите почитать справку, а напрасно:
Цитата:
ПримерыПо второму воросу поищите в справке самостоятельно.
7z a archive.7z -psecret -mhe *.txt
сжимает *.txt файлы в archive.7z используя пароль "secret". Это также зашифрует заголовки архива (ключ -mhe), таким образом, имена файлов будут зашифрованы.
7z x archive.zip -psecret
извлекает все файлы из archive.zip используя пароль "secret".
GORA2
я тока что это нашел! у меня всегда так, сначала задам вопрос потом прочту справку, надо мне меняться
я тока что это нашел! у меня всегда так, сначала задам вопрос потом прочту справку, надо мне меняться
Проверил ради интереса ещё парочку архиваторов:
ARJ 3.10 (Open-source ARJ):
Команда:
arj a Pi.txt.arj Pi.txt
Результат: файл Pi.txt.arj размером 6 250 121 байт (на 121 байт больше исходного), целиком содержащий файл Pi.txt в неизменном виде.
ARJ32 3.14a (Патентованная версия архиватора)
Команда:
arj32 a Pi.txt.arj Pi.txt
Результат: файл Pi.txt.arj размером 6 250 124 байт (на 124 байта больше исходного), целиком содержащий файл Pi.txt в неизменном виде.
WinUHA 2.0 RC1 (2005.02.27)
Сжатие: ALZ-3 (Максимальное), остальные параметры оставил по умолчанию
Результат: файл Pi.txt.uha размером 6 251 034 (на 1034 байта больше исходного), содержащий "сжатую" версию файла.
Похоже, что я немного поспешил выше, когда сказал, что при упаковке в ZIP и GZIP файл Pi.txt помещается в неизменном виде в контейнер. Полное сравнение ZIP-архива с исходным файлом показало, что совпадают только байты архива (с первыми байтами исходного файла) с 42-го по 32820 (при упаковке WinRAR 3.80 с максимальным сжатием или WinZIP 12) или с 42-го по 16432-й (при упаковке встроенной в Mathematica функцией). Аналогично с GZIP: совпадают байты с 32-го по 32810 (при упаковке gzip 1.2.4 (порт под Windows)) или с 16-го по 16406-й (при упаковке встроенной в Mathematica функцией). Дальше совпадения не искал.
... и очень интересный результат получил при упаковке в формат ZIP с помощью 7-Zip:
Сжатие: Ультра
Методы (проверил все!): Deflate, Deflate64, BZip2, LZMA
Результат не зависит от использованного метода: получается архив, на 110 байт больше исходного файла, и содержащией его целиком в неизменном виде.
ARJ 3.10 (Open-source ARJ):
Команда:
arj a Pi.txt.arj Pi.txt
Результат: файл Pi.txt.arj размером 6 250 121 байт (на 121 байт больше исходного), целиком содержащий файл Pi.txt в неизменном виде.
ARJ32 3.14a (Патентованная версия архиватора)
Команда:
arj32 a Pi.txt.arj Pi.txt
Результат: файл Pi.txt.arj размером 6 250 124 байт (на 124 байта больше исходного), целиком содержащий файл Pi.txt в неизменном виде.
WinUHA 2.0 RC1 (2005.02.27)
Сжатие: ALZ-3 (Максимальное), остальные параметры оставил по умолчанию
Результат: файл Pi.txt.uha размером 6 251 034 (на 1034 байта больше исходного), содержащий "сжатую" версию файла.
Похоже, что я немного поспешил выше, когда сказал, что при упаковке в ZIP и GZIP файл Pi.txt помещается в неизменном виде в контейнер. Полное сравнение ZIP-архива с исходным файлом показало, что совпадают только байты архива (с первыми байтами исходного файла) с 42-го по 32820 (при упаковке WinRAR 3.80 с максимальным сжатием или WinZIP 12) или с 42-го по 16432-й (при упаковке встроенной в Mathematica функцией). Аналогично с GZIP: совпадают байты с 32-го по 32810 (при упаковке gzip 1.2.4 (порт под Windows)) или с 16-го по 16406-й (при упаковке встроенной в Mathematica функцией). Дальше совпадения не искал.
... и очень интересный результат получил при упаковке в формат ZIP с помощью 7-Zip:
Сжатие: Ультра
Методы (проверил все!): Deflate, Deflate64, BZip2, LZMA
Результат не зависит от использованного метода: получается архив, на 110 байт больше исходного файла, и содержащией его целиком в неизменном виде.
popkov
Пиши ему на support@7-zip.org
А что касаемо твоих результатов - интересно.
Пиши ему на support@7-zip.org
А что касаемо твоих результатов - интересно.
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172
Предыдущая тема: Longhorn и Blackcomb
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.