[Ruslan1 16]

Здравствуйте!

 

Имеется кучка файлов, которые можно поделить на две группы

1) длинные текстовые- например, лог 6 мегабайт ежедневно

2) куча коротких текстовых - например, ежедневно директория с 1440 файлами по 200 байт (ежеминутные данные)

 

Хочу их заархивировать с целью:

группа1 - чтобы уменьшить размер (важно при передаче)

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

 

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

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

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

 

 

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

Обычно на МК решается обратная задача - разжать (прошивку, образ итд), да и то из нестандартного формата, а вот упаковщики в "стандартный" архив как-то не попадаются.

 

Ни и если кто-то может рассказать про личный опыт, что за архиватор применяли на МК, буду безмерно счастлив.

 

конкретно буду реализовывать на STM32F4, если это важно

[VCucumber 0]

есть же какой-то зип открытый, только возьми и скомпили

[AlexandrY 3]

Я точно не буду применять архиватор в нестандартный архив.

 

Тестировал кучку разных движков сжатия - https://geektimes.ru/post/264558/

Там среди прочего найдете проект под VisualStudio на PC. Можно экспериментировать с разными файлами насчет сжатия.

Но без ресурсов готовтесь к тому, что сжатие будет никакое.

[Ruslan1 16]

Тестировал кучку разных движков сжатия - https://geektimes.ru/post/264558/

Там среди прочего найдете проект под VisualStudio на PC. Можно экспериментировать с разными файлами насчет сжатия.

Но без ресурсов готовтесь к тому, что сжатие будет никакое.

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

zlib —...... Является обобщением алгоритма сжатия данных DEFLATE, используемого в их компрессоре данных gzip.

Ну никак не говорит, так смогу я сжатое этой zlib разжать стандартным gzip или не смогу. И так практически везде. Такое ощущение, что подавляющее большинство делает "вещь в себе", под свой же распаковщик.

 

Про ресурсы- сколько-то килобайт под буфер могу найти (ну, может десяток). Да и файлы лежат рядом, могу доступаться к ним и перечитывать сколько угодно раз, без полного перемещения файла в RAM.

 

есть же какой-то зип открытый, только возьми и скомпили

jszip ?

 

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

A tar кто-то реализовывал на микроконтроллере?

[aiwa 0]

minilzo

(__http://www.oberhumer.com/opensource/lzo/)

[vladec 7]

zip-ы, rar-ы, tar-ы и т.п. требуют для своей работы больших ресурсов, для микроконтроллера реально по затратам арифметическое сжатие.

[AlexandrY 3]

zip-ы, rar-ы, tar-ы и т.п. требуют для своей работы больших ресурсов, для микроконтроллера реально по затратам арифметическое сжатие.

 

Все эти алгоритмы параметрезированы. Распаковщики эту параметризацию понимают. Поэтому вы полностью управляете ресурсами. Любой засунете в пару десятков килобайт.

Дело только в том что сжатие такое дело, что чем меньше памяти под словари тем хуже сжатие.

 

Но TC скорее нужен не алгоритм сжатия, а формат контейнеров. Это другая тема.

Мои zip файлы компьютер понимает, но контейнер для многих файлов в одном zip-е я не делал.

[Ruslan1 16]

minilzo

(__http://www.oberhumer.com/opensource/lzo/)

Спасибо, буду думать (делать планирую буду ближе к новому году или даже после, чуть времени есть).

Все идет к тому что если хочу стандартный (zip какой-нить) то нужно больше усилий чем для нестандартного.

В принципе, наверное возможно и нестандарт, если разница в ресурсах велика....

в-общем-то оборудование небытовое, думаю смогу аргументировать применение и какого-нить небытового lzo.

 

Все эти алгоритмы параметрезированы. Распаковщики эту параметризацию понимают. Поэтому вы полностью управляете ресурсами. Любой засунете в пару десятков килобайт.

Дело только в том что сжатие такое дело, что чем меньше памяти под словари тем хуже сжатие.

 

Но TC скорее нужен не алгоритм сжатия, а формат контейнеров. Это другая тема.

Мои zip файлы компьютер понимает, но контейнер для многих файлов в одном zip-е я не делал.

Я в начале написал, у меня два разных случая в одном проекте

Для одного нужен сжиматель без контейнера, для другого- именно контейнер без сжимателя.

 

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

 

А свой нестандартный последний сжиматель я еще в институте делал, по Хафману, на Z80 и ассемблере. Для курсовой сжимателя хватило, разжиматель пусть другие делают :)

[HardEgor 64]

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

tar это вообще элементарщина, был придуман чтобы потоково лить файлы на ленту.

Просто все привыкли что сейчас он еще заворачивается в gzip, вот и переживают...

 

Вообще по-хорошему надо найти исходники самого древнего unix - там будет и tar и gzip для минимальных ресурсов.

[SapegoAL 0]

Но без ресурсов готовтесь к тому, что сжатие будет никакое.

Глупости. На меге делал модем. Там было сжатие. Примерно 2 коэффициент. Сжатие в потоке даже с адаптивным словарём очень мало рерурсов ест. А распаковка - вообще 0. На CM3 даже не заметишь.

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

[Ruslan1 16]

tar это вообще элементарщина, был придуман чтобы потоково лить файлы на ленту.

Просто все привыкли что сейчас он еще заворачивается в gzip, вот и переживают...

 

Вообще по-хорошему надо найти исходники самого древнего unix - там будет и tar и gzip для минимальных ресурсов.

Да, я на это и надеялся, просто не открывал совсем, боялся испугаться :)

а как открыл, так просветлел сильно и сразу. может кому еще пригодится, тут ссылки оставлю:

этого и этого, по-моему, вполне хватит для написания своего тара.

 

ну и просто обсуждение : тут и тут про тар "на пальцах на русском"

 

В-общем, спасибо огромное, с контейнером все понятно, красиво и просто, и непонятно что тут "ресурсами" называть :)

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

 

Осталось понять что со сжимателем делать, но теперь это совсем не срочно.

 

Глупости. На меге делал модем. Там было сжатие. Примерно 2 коэффициент. Сжатие в потоке даже с адаптивным словарём очень мало рерурсов ест. А распаковка - вообще 0. На CM3 даже не заметишь.

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

Что именно использовали на Меге, какой упаковщик?

 

у меня файл завершен и записан на диск, и времени много. Могу хоть 10 раз его перечитать если это для составления и корректировки полного словаря нужно. Но вот RAM хотелось бы экономить.

Адаптивный словарь меня скорее всего тоже устроит. Текст, причем только нижняя половина ASCII, много похожих строк. То есть по малой части текста можно очень неплохо подходящий всему тексту словарь сделать. Zip эти 6 мегабайт жмет в 10 раз (на минимальной степени сжатия, 1), на максимальной (9) - в 15 раз жмет.

[AlexandrY 3]

Глупости. На меге делал модем. Там было сжатие. Примерно 2 коэффициент. Сжатие в потоке даже с адаптивным словарём очень мало рерурсов ест. А распаковка - вообще 0. На CM3 даже не заметишь.

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

 

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

Хотите подкину файл который после вашего сжатия не уменьшится, а увеличится в объеме?

[SapegoAL 0]

Речь шла о текстовом документе.

Скажем так. Пробовал пересжимать его зипом Особо выигрыша не было.

По сути алгоритм не изменился. Ничего нового не выдумали. Я уже писал. Играет роль размер словаря (особенно на крупных файлах) и предустановленный словарь. Причём словарь можно сделать наиболее употребляемый в данном случае. Это даст существенный выигрыш.

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

В любом случае само сжатие/ распаковка используют мало ресурсов. Не в пример крипто. Только память. Памяти по нынешним временам 64к - не о чём.

[Ruslan1 16]

Речь шла о текстовом документе.

"Имя, сестра, имя!"

[SapegoAL 0]

"Имя, сестра, имя!"

Я писал свой алгоритм для модема. Но все архиваторы построены в основе своей на https://ru.wikipedia.org/wiki/Алгоритм_Лемп..._—_Зива_—_Велча.

То есть ZIP, на сколько я понимаю.

ЗЫ: Прошу прощения, посмотрел, оказывается я не прав. Буква Z ввела в заблуждение. Ну и когда RAR смотришь - там про словарь тоже указывается. Короче я использовал модифицированный метод словаря. Который в модемах применяется. Там словарь передаётся прямо в потоке. И параллельно формируется на обоих концах. Сжатый файл таким методом, сжимается ZIPом совсем не значительно.