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

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

ОТВЕТЫ

Ответ 1

Отъезд Smaz:

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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