ZXC 0.12.0

т.е. если потерял словарь - потерял архив?)

Как будто в lz4 или zstd это не так.

т.е. если потерял словарь - потерял архив?)

А иного способа сжимать пока не изобрели, только по договоренности «Вот эта комбинация символов = имеет вот такое сокращение».

Но пока по эффективности сжатия лидирует китайская грамота =)

а разве словарь не часть архива dataman, windows10?

Нет, по крайней мере в lz4 и zstd.

$ lz4 -h:

-D FILE: use FILE as dictionary (compression & decompression)

$ zstd -H:

-D DICT Use DICT as the dictionary for compression or decompression.

Автор zxc на них и ориентируется, скорее всего.

а, ок.

Не понял, разве словарь не формируется для данной конкретной ситуации. Это ломает все мои представления

Немного устарело, но https://nigeltao.github.io/blog/2022/zstandard-part-7-dictionaries.html пишет:

Dictionaries are supplied out-of-band to a Zstandard file. Each frame in a Zstandard file can refer to its own dictionary, identified by a uint32 number.

Dictionaries are optional and the romeo.txt.zst example doesn’t use them. Instead, here’s a 4 KiB dictionary built from 64 KiB chunks of Shakespeare’s complete works:

$ wget –quiet https://www.gutenberg.org/files/100/100-0.txt
$ zstd –train –maxdict=4096 -B65536 -o 100-0.dict 100-0.txt 2> /dev/null

Но наверное, для 7z можно написать плагин, который будет хранить в архиве и словарь тоже. А может кто-то уже так и сделал. :)

Я вот считаю микрощелочные усилия, сжать что-то, просто беспорядочными действиями. Ты потратишь больше времени на запаковку, чем потом вообще когда-нибудь притронешься к своему файлу. И так, уже давно самые большие объемы данных сжимают эффективнее всего всякие av1/h.265 По сути сжимая ты тратишь процессорное время, чтобы потом распаковать, и снова потратить время. Есть конечно полезные типы файлов которые можно сжимать, картинки например, но ты просто уменьшаешь их размер, а не пакуешь в архив, из которого надо достать. Максимум использовать его как папку для пересылки файлов, без сжатия. Ведь сжатие архива, экономит смешные мегабайты памяти. Плюс степень силы упаковки архива, требует огромных усилий при его открытии. Так еще и место свободного много нужно для временных файлов , чтобы его открыть. Да и к тому же, большинство файлов и так уже сжаты, так что заниматься переупаковой сжатых файлов, такое себе дело. Архивы-зло.

Кажется понял. Есть набор стандартных словарей. Но можно этот некий «типа стандартный» словарь расширить еще и своими вариантами, надеюсь понял верно

Ну тут не все так однозначно.

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

А полезные типы файлов которые можно сжимать - по сути только текстовые, пушо они эффективнее всего поддаются сжатию.

И экономит это не смешные мегабайты памяти, а иногда гигабайты и часы. Например у меня на одном из серверов, SQL дамп занимает 25 гиг. Сжатый занимает что-то около 450 мегабайт.

Свободное место для открытия архива не нужно, в наборе к архиваторам идут утилиты, которые умеют сразу в stdout, например zcat.

Я понимаю о чем вы можете подумать, поэтому говорю заранее: 25 гигабайт - это объем информации, не подлежащей оптимизации, хоть в 10 таблиц ее разнесите, хоть в 100 баз - она будет занимать 25 гигабайт

И кстати, усилий работа с архивами требует минимальных.

Есть набор стандартных словарей.

В Brotli есть, в zstd и lz4 нет.

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

Касаемо сабжа, автор планировал написать модуль для ядра (а может уже и есть).

Тогда его смогут использовать различные ФС.

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

Честно говоря удивлен, текстовые логи часто из 600 мегабайт становятся 600 килобайтами. Например пакеты в сети как знаете не жмут, вот pcap-файл для всяких wireshark/tcpdump жмутся в 10-15 раз. Наконец архив типа tar ни разу не зло, просто 5000 файлов становятся одним и очень быстро передаются через шары и netcat-ы одной командой

В отличии от zpaq, в области низких коэфицентов сжатия этот подход выглядит совершенно ненужным.