it-swarm.com.ru

Эффективный алгоритм сжатия коротких текстовых строк

Я ищу алгоритм для сжатия небольших текстовых строк: 50-1000 байт (то есть URL). Какой алгоритм лучше всего подходит для этого?

114
Vasily Korolev

Проверьте Смаз :

Smaz - простая библиотека сжатия, подходящая для сжатия очень коротких строк.

56
stvchu

У Хаффмана статическая цена, стол Хаффмана, поэтому я не согласен, что это хороший выбор.

Есть адаптивные версии, которые устраняют это, но степень сжатия может пострадать. На самом деле, вопрос, который вы должны задать, это "какой алгоритм сжатия текстовых строк с этими характеристиками". Например, если ожидаются длинные повторения, может быть достаточно простого кодирования Run-Lengh. Если вы можете гарантировать наличие только английских слов, пробелов, знаков препинания и случайных цифр, то Хаффман с заранее определенной таблицей Хаффмана может дать хорошие результаты.

Как правило, алгоритмы семейства Lempel-Ziv имеют очень хорошее сжатие и производительность, и библиотек для них предостаточно. Я бы пошел с этим.

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

Например, переводя URL в битовый поток, вы можете заменить "http" битом 1, а все остальное - битом "0", за которым следует фактический протокол (или использовать таблицу для получения других распространенных протоколов, таких как https, ftp, файл). ": //" может быть полностью удален, если вы можете отметить конец протокола. И т.д. Пойдите, прочитайте о формате URL, и подумайте, как их можно кодифицировать, чтобы занять меньше места.

28
Daniel C. Sobral

У меня нет кода под рукой, но мне всегда нравился подход к созданию двумерной справочной таблицы размером 256 * 256 символов ( RFC 1978 , Сжатие предиктора PPP Протокол ). Чтобы сжать строку, вы перебираете каждый символ и используете таблицу поиска, чтобы получить "предсказанный" следующий символ, используя текущий и предыдущий символы в качестве индексов в таблице. Если есть совпадение, вы записываете 1 бит, в противном случае пишите 0, символ и обновите таблицу поиска текущим символом. Этот подход в основном поддерживает динамическую (и грубую) таблицу поиска наиболее вероятного следующего символа в потоке данных.

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

Этот алгоритм не дает блестящей степени сжатия, но он невероятно экономен с памятью и ресурсами ЦП, а также может работать с непрерывным потоком данных - декомпрессор сохраняет свою собственную копию таблицы поиска по мере распаковки, таким образом, таблицу поиска настраивается на тип сжатых данных.

22
redcalx

Любой алгоритм/библиотека, которая поддерживает предустановленный словарь, например Zlib .

Таким образом, вы можете заполнить компрессор тем же текстом, который может появиться на входе. Если файлы в некотором роде похожи (например, все URL-адреса, все программы на C, все сообщения StackOverflow, все рисунки в формате ASCII), то определенные подстроки появятся в большинстве или во всех входных файлах.

Каждый алгоритм сжатия будет экономить место, если одна и та же подстрока повторяется несколько раз в одном входном файле (например, "the" в английском тексте или "int" в коде C.)

Но в случае URL-адресов определенные строки (например, " http: // www .", ".Com", ".html", ".aspx" обычно появляются один раз в каждом входном файле. вам нужно как-то делиться ими между файлами, а не иметь одно сжатое вхождение на файл, это можно сделать, поместив их в заданный словарь.

11
finnw

Если вы говорите о фактическом сжатии текста, а не только об укорочении, тогда Deflate/gzip (обертка вокруг gzip), Zip хорошо работают для небольших файлов и текста. Другие алгоритмы очень эффективны для больших файлов, таких как bzip2 и т.д.

Википедия есть список времени сжатия. (посмотрите на сравнение эффективности)

Name       | Text         | Binaries      | Raw images
-----------+--------------+---------------+-------------
7-Zip      | 19% in 18.8s | 27% in  59.6s | 50% in 36.4s
bzip2      | 20% in  4.7s | 37% in  32.8s | 51% in 20.0s
rar (2.01) | 23% in 30.0s | 36% in 275.4s | 58% in 52.7s
advzip     | 24% in 21.1s | 37% in  70.6s | 57& in 41.6s
gzip       | 25% in  4.2s | 39% in  23.1s | 60% in  5.4s
Zip        | 25% in  4.3s | 39% in  23.3s | 60% in  5.7s
5
Ryan Christensen

кодирование Хаффмана как правило, работает хорошо для этого.

4
Zifre

Возможно, вы захотите взглянуть на Стандартная схема сжатия для Unicode .

SQL Server 2008 R2 использует его внутри и может обеспечить сжатие до 50%.

2
Le Hibou