Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » WinRAR (часть 4)

Модерирует : gyra, Maz

Maz (31-07-2023 08:32): WinRAR (часть 5)  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201

   

Maz



Дед Мазай
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
По вопросам лечения (кряки, патчи и т.д.), а также разблокировки архивов, обращаемся в «Варезник».
Отдельная тема по сборкам WinRAR
Предыдущие части темы: 1 | 2 | 3



 
Официальный русский сайт: win-rar.com
Официальный e-mail разработчика WinRAR (писать на русском): dev@rarlab.com
 
Стабильная английская версия: 6.22 x86 | x64 (31 мая 2023 г.)
Стабильная русская версия:  6.22 x86 | x64 (31 мая 2023 г.)

Текущая английская бета-версия:  6.23 beta 1 x86 | x64
Текущая русская бета-версия:  6.23 beta 1 x86 | x64

Примечание: английская бета-версия обновляется регулярно, без изменения номера версии. подробнее...
Список изменений на английском языке
(на родном – смотрите файл WhatsNew.txt в дистрибутиве на вашем языке)
Скачать RAR для macOS, FreeBSD, Linux, Android можно здесь.

Скачать ранее вышедшие версии можно с официального FTP
Таблица совместимости версий с различными ОС

Версия 3.62 (ru) с подарочным ключом (респект камраду elmorte)

Коллекция всех ранее выходивших версий WinRAR 1.54b - 6.22 (1995-2023): скачать (311 МБ) [обновлено 31.05.2023]

вместо F.A.Q. || альтернативные архиваторы

Почему опять задерживается русская версия? А при русском разработчике на языке XXX уже давно есть. Не захламляйте тему подобными вопросами.

Кому не нравится новая тема оформления - скачайте с официального сайта rarlab.com (из раздела Themes) и установите себе WinRAR Classic theme by Francesco Indrio
Стандартная (48x36). Маленькие кнопки (24x24)

В теме активно отвечает на вопросы автор архиватора Евгений Рошал! Ситуация уникальная, прошу пользоваться.

Всего записей: 38814 | Зарегистр. 26-02-2002 | Отправлено: 19:30 27-08-2020 | Исправлено: DimmY, 17:47 20-07-2023
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Inoz2000

Цитата:
Delta:1 LZMA:23 и LZMA:21m

WinRAR искал "LZMA:" в начале строки с методами, поэтому когда там была Delta или BCJ, он эту строку не находил. Поправлю.
 
Inoz2000

Цитата:
Я бы попросил в RarFiles.lst вписать файлы
*.md5
*.sha
*.sfv  

Они все три реально широко используются?

Цитата:
Примерно в районе *.nfo

Этот уже, наверное, пора убирать в связи с устареванием. Мне кажется, это наследие времен BBS.
 
GoblinNN

Цитата:
ps: а всё семейство sha не надо в этот лист? blake есть еще. о! xxh, k12

В смысле, в rarfiles.lst? Мне файлы с такими расширениями ни разу не попадались. Не хотелось бы заполнять rarfiles.lst редко используемыми форматами. Так-то всяческих хэшей не один десяток можно найти.
 
lelik007

Цитата:
А поле словарь, можно и вообще убрать.  

Для большинства форматов, включая RAR, актуально именно поле с размером словаря. Убирать его для всех форматов нельзя. Менять название поля на ходу только для 7z технически можно, но по сравнению с размером словаря пользователю оно сообщит разве что о задействованных фильтрах. А это все-таки достаточно узкоспециализированная информация.
 
uShell

Цитата:
Судя по дискуссии, WinRAR за размером словаря обращается к 7zxa, а та возвращает строку, которую WinRAR вынужден парсить (иначе вряд ли было бы возможно перепутать d21 и d21m).

Да, это так.

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 18:09 20-03-2023
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
сколько словарей может быть в архиве 7z, если разные методы

Сколько угодно! У того же BCJ2 четыре потока, каждый из которых может быть сжат со своим словарём. Но по логике надо выводить оценку потребления памяти, а это либо максимальный из всех словарей (и WinRAR так и делает), либо сумма словарей потоков (если распаковка потоков выполняется одновременно и в памяти надо держать все словари разом).
 

Цитата:
при задании словаря d=15k , он гад почему-то получается 16k

Но никто не гарантирует, что это поведение сохранится в других версиях 7-Zip и в других архиваторах, генерирующих 7z-контейнер. Даже сам 7-Zip при сжатии использует такой словарь, какой задал пользователь, только в заголовок пишет отсебятину. Метод LZMA (в отличие от LZMA2) задаёт размер словаря в байтах, поэтому теоретически возможен и приведённый выше вариант.
 
Добавлено:

Цитата:
WinRAR искал "LZMA:" в начале строки с методами

Примерно это я и имел в виду, критикуя парсинг строки. А если там будет не LZMA, а PPMd (который тоже имеет настраиваемый словарь) или какой-нибудь редкоземельный метод вроде Brotli? А если в новой версии 7zxa в строке появится буква d перед размером словаря? Кстати, у PPMd параметр, задающий размер словаря, называется не d, а mem. Но тут у Вас, конечно, руки связаны - всё упирается в 7zxa.

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 18:16 20-03-2023
Inoz2000



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
Цитата:
какой-нибудь редкоземельный метод вроде Brotli
Такой метод WinRar не знает, вы разве не знали?

----------
Мы все умрём. (-:

Всего записей: 4904 | Зарегистр. 23-04-2009 | Отправлено: 18:30 20-03-2023
lelik007



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Некоторые программы называют этот формат  *.sha, а некоторые *.sha1.
Еще очень популярный *.sha256, все мыслимые хеши не нужно.
uShell
EugeneRoshal
Pasha_ZZZ
В принципе, я со всеми согласен, подумав.
Особенно с этим.

Цитата:
 Но по логике надо выводить оценку потребления памяти, а это либо максимальный из всех словарей (и WinRAR так и делает), либо сумма словарей потоков (если распаковка потоков выполняется одновременно и в памяти надо держать все словари разом).  

uShell
Какой уж Brotli, тут бы нормально сделать для встроенных в 7-zip форматов.

Всего записей: 2759 | Зарегистр. 13-10-2006 | Отправлено: 18:44 20-03-2023
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell

Цитата:
А если в новой версии 7zxa в строке появится буква d перед размером словаря?

Не покажет размер словаря. Косметика, в общем-то. Распаковать - все равно распакует, если 7xa.dll этот формат понимает.

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 18:48 20-03-2023
pp3

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Некоторые наблюдения о недочетах.
Имеется архив на дискетах, где один файл сжат и разбит на тома. Открываю winrar с первым томом (остальные пока недоступны), первое что бросается в глаза - поле crc32 показывает контрольную сумму только части файла, а не всего как обычно - может это выделить как-то, а то неочевидно (ну размер и дата же полные)? Захожу в диалог информации об архиве, там шикарная степень сжатия - 1%, потому что она считается только по этому тому, что неверно и вводит в заблуждение. Запускаю мастер распаковки - он предлагает каталог вида "имя архива.part01" - ну part01-то зачем, это наверное надо обрезать?
 
p.s. посмотрел в конец архива hex-редактором, там несколько килобайт нулей ради выравнивания на точный размер тома, видимо потому что точный размер секции с инфой о быстром доступе нельзя подсчитать точно. Интересно с этим можно что-то сделать? А можно ли вообще отключить добавление секции с быстрым доступом к именам файлов ради экономии места?
 
p.p.s. проверялось на 6.21.

Всего записей: 63 | Зарегистр. 15-05-2003 | Отправлено: 18:59 20-03-2023
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Захожу в диалог информации об архиве, там шикарная степень сжатия - 1%, потому что она считается только по этому тому

Да, я тоже обращал на это внимание. Хорошо бы тут вообще ничего не выводить.
 

Цитата:
можно ли вообще отключить добавление секции с быстрым доступом к именам файлов

-qo-

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 19:10 20-03-2023
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
pp3

Цитата:
Запускаю мастер распаковки - он предлагает каталог вида "имя архива.part01" - ну part01-то зачем, это наверное надо обрезать?  

Это если вызывать мастер распаковки "изнутри" архива, а не поместив курсор на его имя. Поправлю.

Цитата:
Интересно с этим можно что-то сделать?

Подробности я сейчас не помню, но с идеальным соответствием заданному размеру тома были проблемы. Видимо, дело в наличии некоторого количества полей, итоговая длина которых определяется только в последний момент. Если том чуть короче заданного, для аккуратности он выравнивается нулями.

Цитата:
А можно ли вообще отключить добавление секции с быстрым доступом к именам файлов ради экономии места?

Ключ -qo- или опция "Quick open information/Do not add" на странице "Options" диалога упаковки.
 
uShell

Цитата:
Да, я тоже обращал на это внимание. Хорошо бы тут вообще ничего не выводить.

Там погрешность максимальна для одного порезанного файла и минимальна в случае массы упакованной мелочи. Не уверен, что не выводить - однозначно лучше.

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 19:41 20-03-2023
pp3

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal

Цитата:
Ключ -qo- или опция "Quick open information/Do not add" на странице "Options" диалога упаковки.  

Спасибо. А вообще есть ли смысл в quick open info для многотомных архивов, где мало файлов? Или оно вообще имеет смысл только скорее для архивов где файлов будет много, а где их мало можно и не добавлять даже в автоматическом режиме - ведь количество файлов в томе точно известно на момент его окончания?
 

Цитата:
Там погрешность максимальна для одного порезанного файла и минимальна в случае массы упакованной мелочи. Не уверен, что не выводить - однозначно лучше.
 

Если у winrar есть доступ ко всем томам в каталоге (тот же случай - порезан один файл), а мы зашли в последний том например, то можно же точно подсчитать степень сжатия, а winrar все равно выводит неверную информацию. Зато если зайти в первый том - все хорошо.

Всего записей: 63 | Зарегистр. 15-05-2003 | Отправлено: 21:46 20-03-2023
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
А вообще есть ли смысл в quick open info для многотомных архивов, где мало файлов?

У меня немного другой вопрос возник: блок QO в томе содержит информацию обо всём архиве или только об одном томе (или нескольких)? Если обо всём, то выглядит странным

Цитата:
мы зашли в последний том например, то можно же точно подсчитать степень сжатия, а winrar все равно выводит неверную информацию

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 23:38 20-03-2023
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
pp3

Цитата:
Спасибо. А вообще есть ли смысл в quick open info для многотомных архивов, где мало файлов?

Зависит от нескольких факторов, включая время позиционирования диска. Если архив хранится на дискетах, как в приведенном вами случае, время позиционирования крайне велико.

Цитата:
Или оно вообще имеет смысл только скорее для архивов где файлов будет много, а где их мало можно и не добавлять даже в автоматическом режиме - ведь количество файлов в томе точно известно на момент его окончания?

Если файлов мало, так и quick open info к размеру архива много не добавит. Для малого количества файлов и выигрыш в скорости от наличия quick open info небольшой, и выигрыш в размере от ее отсутствия мизерный. Так что это не так принципиально.
 
Хотя в экзотической ситуации с архивом на дискетах, даже при небольшом количестве файлов в архиве выигрыш от наличия этих данных может быть заметен. Слишком велико время позиционирования.

Цитата:
Если у winrar есть доступ ко всем томам в каталоге (тот же случай - порезан один файл), а мы зашли в последний том например, то можно же точно подсчитать степень сжатия, а winrar все равно выводит неверную информацию. Зато если зайти в первый том - все хорошо.

Если включена "Merge volumes contents" в настройках, при открытии первого тома WinRAR пытается прочесть содержание всех томов. Но при открытии не первого тома WinRAR считает, что пользователю интересно содержимое именно данного тома, и показывает только его. Иначе зачем пользователю открывать том из середины. Если нужна статистика о всем наборе томов, можно включить упомянутую выше опцию и открыть первый том.
 
 
Добавлено:
uShell

Цитата:
блок QO в томе содержит информацию обо всём архиве или только об одном томе

Об одном текущем томе.

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 23:41 20-03-2023
Inoz2000



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
Цитата:
Кстати, у PPMd параметр, задающий размер словаря, называется не d, а mem
нету там ни d, ни me, ни цифр. Одно слово PPMD догадайтесь сами

----------
Мы все умрём. (-:

Всего записей: 4904 | Зарегистр. 23-04-2009 | Отправлено: 09:12 21-03-2023
lelik007



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Inoz2000
Он для упаковки имел ввиду, в ком.строке.
Типа -m0=PPMd -mmem=30 (1 Гб).
А в выводе метода для PPMd действительно нет размера словаря,
Method  : PPMD
Для bzip2 тоже.

Всего записей: 2759 | Зарегистр. 13-10-2006 | Отправлено: 10:23 21-03-2023 | Исправлено: lelik007, 10:29 21-03-2023
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
для PPMd действительно нет размера словаря
А этот метод позволяет без распаковки его узнать?
Вроде у того же zstd похожая история была.

Всего записей: 16542 | Зарегистр. 04-11-2010 | Отправлено: 18:26 21-03-2023
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Inoz2000, lelik007
7-Zip в своём интерфейсе mem прекрасно выводит. Потому что

Цитата:
А этот метод позволяет без распаковки его узнать?

в заголовке архива прописаны и o, и mem, причём mem, как и в случае LZMA, задаётся в байтах. Для ZSTD (и, кажется, LZMA2) размер словаря хранится в потоке, поэтому в заголовке на нём можно сэкономить. К тому же, распаковщики всех упомянутых алгоритмов теоретически могут вообще не знать размер словаря заранее, а выделить память с запасом. В моих экспериментах увеличение указанного размера словаря для LZMA2 не приводило ни к каким ошибкам.

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 18:50 21-03-2023
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
Цитата:
увеличение указанного размера словаря для LZMA2 не приводило ни к каким ошибкам
А если уменьшить?

Всего записей: 16542 | Зарегистр. 04-11-2010 | Отправлено: 18:58 21-03-2023
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
А если уменьшить?

Для начала следует отметить, что выставление словаря N байт означает, что дальше, чем на N байт назад, компрессор смотреть не будет ни при каких условиях. Фактически он и эти N может не использовать. Например, в потоке случайных данных, где LZ-алгоритм вообще не работает, актуальный словарь будет нулевым. Так вот, если размер словаря, указанный в архиве, уменьшить ниже реально используемого (т.е. ниже максимума, использованного в LZ-кодах), будет ошибка распаковки. Какая именно ошибка - не помню. Если уменьшить так, что новый размер покроет реально используемый - ошибки нет.
 
Теоретически, компрессор может засекать максимум, который он использует, и корректировать выставляемый в архиве размер словаря. На мой взгляд, это легко реализовать (разве что в многопоточном режиме придётся повозиться с синхронизацией), но на практике я такого не видел.

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 19:14 21-03-2023
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
Цитата:
будет ошибка распаковки
Что и требовалось доказать.
Цитата:
уменьшить так, что новый размер покроет реально используемый - ошибки нет
Для этого надо было изначально паковать с промежуточным размером словаря, получается.
Паковал когда-то на 16 ГБ рамы архив в двухпотоке со словарём около 1280 МБ (это был потлок по свободной оперативке), но на конечный архив свойства писали про словарь для распаковки как 1536 МБ. Видать, это и есть тот самый случай, когда можно "поправить руками на меньшее"?

Всего записей: 16542 | Зарегистр. 04-11-2010 | Отправлено: 19:20 21-03-2023
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
это и есть тот самый случай, когда можно "поправить руками на меньшее"?

Может быть, но с поправкой на то, как размер словаря хранится. Если это LZMA2, в нём технически нельзя прописать 1280m - только ближайшее сверху 1536m. А вот для LZMA - да, можно.
 
Кстати, для некоторых некруглых чисел у меня 7-Zip указывает такой размер словаря, какой задан в команде (например, 5m). Странная логика - округлять только некоторые числа.

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 19:32 21-03-2023
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
Возможно, эти 5m - тоже в каком-то смысле "достаточно круглое" как всякие 48m, чтобы использовать как есть.

Всего записей: 16542 | Зарегистр. 04-11-2010 | Отправлено: 19:35 21-03-2023
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201

Компьютерный форум Ru.Board » Компьютеры » Программы » WinRAR (часть 4)
Maz (31-07-2023 08:32): WinRAR (часть 5)


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru