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

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в 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)

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

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

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

Цитата:
похоже, надо сделать счётчик для M после H. До двух M подряд (разделить любой символ) считаются минутами, а последующие обозначением месяца.

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

Цитата:
Тогда HH_M_M не будет возвращать разбитое число минут

Так он должен возвращать разбитое число минут, почему нет.

Цитата:
а несколько MMMMMMMM не будут интерпретироваться несколько раз.

В общем случае такие последовательности не интерпретируются несколько раз. Можете проверить с YYYYYYY или HHHHHHH. MMM это единственное исключение. Обработка символьных названий месяцев отличается от обработки остальных полей времени, и там такая проверка не работала. Сейчас сделал, будет работать и для MMMMMMMM.

Цитата:
Если кто-то вдруг захочет использовать 7Jul, то в текущей реализации не сможет.

Я сознательно ограничиваю возможность повторного указания того же поля времени в маске, вместо того, чтобы начать выводить его заново. Маски типа MMMM или YYYYY это практически всегда опечатка пользователя, а не какой-то хитрый замысел, и лучше дать эту опечатку заметить. Если увижу, что в реальных задачах пользователям действительно требуется указать месяц в маске дважды, в символьном виде, и как число, можно будет рассмотреть возможность реализации. Но пока я с такими задачами не встречался. Предположу, что на практике это нужно примерно так же, как МИНУТЫМИНУТЫ или JulJulMM.

Цитата:
или вообще число дня в середине числа месяца
-agM{"текст"}aM{"текст"}
0текст57текст  

07 это месяц, 5 это номер дня недели. Как просили.
 
Добавлено:
AlexDAT

Цитата:
похоже, надо сделать счётчик для M после H. До двух M подряд (разделить любой символ) считаются минутами, а последующие обозначением месяца.

Хотя если вспомнить про американский вариант даты, с месяцем перед днем, тогда, пожалуй, вы правы насчет варианта со счетчиком. Что-то типа: HH-MM-MM-DD-YY. Только первые два M после H должны быть минутами.
 
Не уверен, правда, про "подряд". Надо ли запрещать разделители между первыми двумя M. Имеет ли право на существование какой-нибудь вычурный h.h.m.m, и что мы выигрываем, запрещая такие варианты и обрабатывая в этой маске второй M как месяц.

Всего записей: 2242 | Зарегистр. 29-04-2013 | Отправлено: 15:04 09-07-2021 | Исправлено: EugeneRoshal, 16:52 09-07-2021
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
AlexDAT
Правда можно придумать маску только с часами без минут и американской датой: HHMMDDYY. Тут уже не угадать, минуты это или месяц. Только часы и обычная дата HHDDMMYY тоже может создать проблемы, если использовать только счетчик M после H и не сбрасывать его по D. Но на практике вряд ли применяются варианты только с часами, да еще и впереди даты.

Всего записей: 2242 | Зарегистр. 29-04-2013 | Отправлено: 17:45 09-07-2021
AlexDAT



Moderator
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal сам не пользуюсь, но больше беспокоит, что даже принудительное разделение текстом {} и другой переменной не прерывает шаблон. Вот кому может понадобится разбивать число месяца числом недели, как я привёл пример?
Если кто-то слепит без разделителя минуты и месяцы, то сам себе буратино. Другое дело, если есть разделитель. Например, делает бекапы в разное время суток (отслеживает правильность выполнения задачи по времени в имени архива), но не более N количества раз в месяце. Тогда может быть указано время создания бекапа и месяц, а дата второстепенна. Конечно, это теоретический вариант.

Всего записей: 2940 | Зарегистр. 21-04-2009 | Отправлено: 17:55 09-07-2021
GoblinNN

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal, регистрозависимыми сделать их mm - минуты MM - месяц

Всего записей: 2907 | Зарегистр. 11-10-2005 | Отправлено: 18:10 09-07-2021 | Исправлено: GoblinNN, 18:10 09-07-2021
AngelNet



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
подскажите пожалуйста, а можно винрар заставить выводить полное имя текущего месяца, а не только три буквы?
например: Jul > July
                Июл > Июль
(неважно какое количество символов в имени месяца, для локализованных версий.)
спасибо!

----------
animelist

Всего записей: 7413 | Зарегистр. 11-03-2004 | Отправлено: 18:19 09-07-2021 | Исправлено: AngelNet, 18:20 09-07-2021
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Я, как и AlexDAT, скептически отношусь к вставке постороннего текста между разрядами числа в дате/времени. Так что, если Вы оцениваете востребованность пользователями, я голосую за неразрывность полей: варианты типа h.h предлагаю считать невалидными (возможно, начиная с 7-й версии, чтобы обеспечить обратную совместимость). Тем самым упростится код вывода. Как вариант, одиночную букву можно трактовать как число без ведущих нулей.
 
GoblinNN
Я бы голосовал за эту идею, но, как я понял, WinRAR принципиально не различает регистр в ключах, как это принято ещё со времён MS-DOS. Правда, в Rar.txt это в явном виде не написано - только в winrar.chm.
 
AngelNet
Судя по всему, нельзя. А если бы было можно, как склонять месяц? Скажем, сегодня я хочу "архив_от_09_июля_2021.rar", а завтра "архив_за_июль_2021.rar". Аналогично с AM/PM в часах.

Всего записей: 1004 | Зарегистр. 12-06-2019 | Отправлено: 19:13 09-07-2021
EugeneRoshal

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

Цитата:
больше беспокоит, что даже принудительное разделение текстом {} и другой переменной не прерывает шаблон

Не хотелось бы усложнять синтаксис без необходимости. Если нынешнее поведение приведет к каким-то реальным затруднениям, тогда буду смотреть, но пока не жаловались.

Цитата:
Если кто-то слепит без разделителя минуты и месяцы, то сам себе буратино.

Если брать в качестве минут первые две M после часов, то и этот случай обработается нормально. Это только если часы и месяцы слепить, тогда проблема.
 
GoblinNN

Цитата:
регистрозависимыми сделать их mm - минуты MM - месяц

Смысл этих заморочек с позицией M - облегчить пользователям ввод шаблона. Так бы я мог назначить минуты и месяцы на разные буквы, но это еще вспомни что чему соответствует. Пришлось бы каждый раз лазить в документацию. С регистрозависимым вариантом, подозреваю, тоже придется заглядывать в документацию. Да и периодически люди будут путаться и указывать минуты или месяцы не в том регистре. Сейчас сложнее что-нибудь перепутать. Хоть yyddmmhhmm вводи, хоть YYDDMMHHMM.
 
AngelNet

Цитата:
подскажите пожалуйста, а можно винрар заставить выводить полное имя текущего месяца, а не только три буквы?

Разве что отредактировать имена месяцев в .lng файле. Но оно может повлиять на несколько функций, например, на лог-файлы.
 
Добавлено:
uShell

Цитата:
варианты типа h.h предлагаю считать невалидными (возможно, начиная с 7-й версии, чтобы обеспечить обратную совместимость). Тем самым упростится код вывода.

Упростится вряд ли, скорее даже усложнится. Сейчас разделители разрешены везде, а придется разрешать их только между полями. Причем, непонятно, что мы выиграем от такого изменения.

Всего записей: 2242 | Зарегистр. 29-04-2013 | Отправлено: 19:18 09-07-2021
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Насчёт усложнения соглашусь - я не учёл, что надо обрабатывать корректность строки. Я подумал, что при запрете разбиения ускорится обработка: если видим HH, то сразу пишем сюда часы через sprintf, тогда как для H.H после первой H надо записать hours%10+'0', а потом ещё сканировать всю форматную строку на предмет продолжения.
 
Вот так можно было бы написать код (неоптимизированный)

Всего записей: 1004 | Зарегистр. 12-06-2019 | Отправлено: 19:58 09-07-2021
AngelNet



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
да мне склонять не нужно) хватит и именительного падежа, дернутого из настроек виндовс!
 

Цитата:
Разве что отредактировать имена месяцев в .lng файле.

даже так... я почему то считал что имена месяцев берутся из системы, а они зашиты в языковой модуль...
вас понял, потрошить модуль не буду, мне стабильность работы дороже сомнительной выгоды.

----------
animelist

Всего записей: 7413 | Зарегистр. 11-03-2004 | Отправлено: 20:22 09-07-2021
EugeneRoshal

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

Цитата:
если видим HH, то сразу пишем сюда часы через sprintf, тогда как для H.H после первой H надо записать hours%10+'0'

Я с помощью 10 sprintf готовлю char Field[10][6] со полными строками для 10 возможных модификаторов. Потом для текущего символа маски определяю номер модификатора, используя wcschr(L"YMDHISWAEN",*Mask), и беру для него очередной символ из массива Field. Если wcschr вернула NULL, это разделитель. Получается достаточно компактный код, который вещи типа YYYY и YY обрабатывает автоматически. Switch на 10 вариантов вероятно был бы более объемным.

Всего записей: 2242 | Зарегистр. 29-04-2013 | Отправлено: 21:37 09-07-2021
regist123



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal написал(а)
Цитата:
Смысл этих заморочек с позицией M - облегчить пользователям ввод шаблона. Так бы я мог назначить минуты и месяцы на разные буквы, но это еще вспомни что чему соответствует. Пришлось бы каждый раз лазить в документацию. С регистрозависимым вариантом, подозреваю, тоже придется заглядывать в документацию. Да и периодически люди будут путаться и указывать минуты или месяцы не в том регистре. Сейчас сложнее что-нибудь перепутать. Хоть yyddmmhhmm вводи, хоть YYDDMMHHMM.

Всё-таки также поддержку предложение сделать регистрозависимыми.
1) Это привычное поведение которое часто используется и в других местах, а поэтому как раз такое написание интуитивно (если человек привык писать форматы масок времени). К примеру даже если взять википедию https://ru.wikipedia.org/wiki/ISO_8601 то там тоже используется этот принцип.
2) Если человек не знает как правильно писать и путается, то просто обязан посмотреть документацию как писать правильно. Так что аргумент, что придётся смотреть документацию мне кажется не уместным.

----------
Раздачи и акции

Всего записей: 7189 | Зарегистр. 20-03-2009 | Отправлено: 14:19 11-07-2021
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
regist123
Сложность в том, что эта функция не реализуется сейчас с нуля, а давно присутствует в RAR. У пользователей есть уже и наработанные привычки, и командные файлы. Чтобы создать проблемы с совместимостью, нужна какая-то серьезная причина и выигрыш. А мы тут выигрываем только возможность указать часы без минут со следующим за ними месяцем. Что-то типа -aghhmmddyy.

Всего записей: 2242 | Зарегистр. 29-04-2013 | Отправлено: 15:23 11-07-2021
justmann



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
 
 
Беру 20 файлов размером 350 МБ одинакового содержания, но с разными именами. Замечательная идея создать непрерывный архив, ведь файлы одинаковые и ожидаемый размер архива должен получиться равным размеру 1 архива + пару килобайт на запись других имен.
 
Но!!! Винрар абсолютно не справился с задачей, создав многогигабайтный архив! Неужели сложно внедрить функцию подсчета хеша и если хеши одинаковые - то содержимое файлов считать одинаковым и при упаковке solid-архива паковать только имена файлов.

Всего записей: 344 | Зарегистр. 08-06-2021 | Отправлено: 13:04 13-07-2021
Sish



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
justmann
Согласитесь, уважаемый, что ситуация, подобная описанной Вами, едва ли встретится в реальной практике.

Всего записей: 25335 | Зарегистр. 09-06-2004 | Отправлено: 13:13 13-07-2021
AlexDAT



Moderator
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
justmann может не так архивировали или всё же содержимое отличалось?
Сейчас проверил и вполне из 7 одинаковых файлов (копии) по 15,4 МБ получил архив весом 15,4 МБ.
Сохранять идентичные файлы как ссылки

Всего записей: 2940 | Зарегистр. 21-04-2009 | Отправлено: 13:21 13-07-2021
Gnomi

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

Цитата:
Беру 20 файлов размером 350 МБ одинакового содержания, но с разными именами.  

 
Если бы размер словаря для упаковки был бы не менее 350*20=7000 мб, а все требуемые файлы при архивации одномоментно влезли бы в этот словарь, ваша задача была бы решена.
 
В общем виде, это задача называется "дедупликация", в корпоративных системах хранения для её решения применяются серверы баз данных.

Всего записей: 48 | Зарегистр. 24-12-2005 | Отправлено: 13:36 13-07-2021 | Исправлено: Gnomi, 13:38 13-07-2021
justmann



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Всё завязано под размер словаря. Одинаковые мелкие файлы он пакует в непрерывный архив, но вот файлы по 350 МБ - он не способен признать одинаковыми!
 
Неужели за столько лет развития архиватора, никто не предложил добавить функцию - сравниваем размер файлов, если размер одинаковый вычисляем MD5 хеш - если хеш одинаковый - значит файлы одинаковые и их нужно утаптывать в SOLID-архиве как один файл. Неужели за овер 30 лет и овер 100 версий не появилась такая примитивная проверка. Ведь для вычисления хеша не нужно огромные ресурсы, словари и прочее....

Всего записей: 344 | Зарегистр. 08-06-2021 | Отправлено: 14:52 13-07-2021
AlexDAT



Moderator
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
justmann ощущение, что не читаете ответы. Такая упаковка реализована отдельной опцией.

Всего записей: 2940 | Зарегистр. 21-04-2009 | Отправлено: 15:19 13-07-2021
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
justmann
Как я понял, Вы хотите, чтобы WinRAR автоматически сортировал файлы и помещал одинаковые как можно ближе друг к другу. Тогда, если размер словаря превосходит размер файла, дубликаты будут упакованы с приличным сжатием. Я бы поддержал такое предложение: и сортировка, и сравнение в WinRAR уже есть - остаётся их "подружить". Но надо будет подумать, как этот режим будет сочетаться с сортировкой по расширению.
 
В Вашем случае, если включить solid-сжатие и задать размер словаря хотя бы 512 МБ (при условии, что одинаковые файлы имеют одинаковое расширение), архив не будет многогигабайтным. Проверьте.
 
И насчёт MD5 - за ним водятся ложноположительные срабатывания, поэтому для определения идентичности файлов его использовать не следует. Если дело только в сортировке, то можно и MD5 - при коллизии мы разве что потеряем сжатие, а вот с ключом -oi будет беда.

Всего записей: 1004 | Зарегистр. 12-06-2019 | Отправлено: 18:49 13-07-2021 | Исправлено: uShell, 18:53 13-07-2021
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Дедупликация - интересная тема. Хотя это опять неизбежно привело бы к изменению формата RAR. Стоит ли овчинка выделки в 2021 году - большой вопрос.
 

Цитата:
И насчёт MD5

В WinRAR уже есть Blake2, который устойчив к коллизиям + быстрее, чем MD5.
 

Всего записей: 6833 | Зарегистр. 01-10-2002 | Отправлено: 19:32 13-07-2021
   

Страницы: 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