Новинки:

Сайт подключен к Orphus. Если вы заметили опечатку, выделите слово и нажмите Ctrl+Enter. Спасибо!

Re: Дополнение


Сайт о сжатии >> Форум #Компрессор# >> [Ответить] [Ответы]

Автор: Vadim,
12 июля 2004 года в 08:32:26

В ответ на : Re: Дополнение от Savenger в 10 июля 2004 года в 00:00:23:


> Сейчас же сделал парсер страницы, который режет её на отдельные кусочки (Normal, Script, PRE, Meta, ...), а далее обработка идёт для каждого вида "куска" своим индивидуальным образом.

Однако, будет интересно ознакомиться с результатами работы :)

> Может быть порекомедуете какие-то конкретные "рецепты", что бы не изобретать свой велосипед?
> Пока мыслей 2:
> 1) Составить словарик замен, куда вписать какому тегу (или даже сочетанию тэгов) как представляться:

Кстати, при замене теги имеет смысл менять на что-нибудь эдакое, что при сжатии не перепутается с контекстами обычного текста.

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

> 2) Менять всё "на лету" по каким-то правилам, которые будут знать и кодер и декодер, в результате чего смогут подстраиваться под любую страницу, а не только под ту, что удачно сочетается со словариком.

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

> Стоит ли искать наиболее длинные повторяющиеся последовательности (и как это правильно делать, если CPU Time ограничено?) и заменять на более короткие (добавляя список замен к передаваемому файлу) или же я буду просто отбирать хлеб у компрессора?

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

Прошу отметить также, что для разных методов сжатия препроцессинг тоже будет разным. Например, для LZ* имеет смысл выбирать такие замены, которые дадут самый короткий текст на выходе. Для PPM и BWT - важна замена контекстов, которые по своей вероятностной статистике отличаются от остального текста. А длина текста на выходе роли почти не играет.

Ответы:



Ответить на это сообщение

Тема:

Имя (желательно полное):

E-Mail:

URL:

Город:

Страна:

Вежливый и подробный комментарий:
(Форматируйте его, пожалуйста, как почту - короткими строками
Еnter в конце строки, пустая строка между параграфами).

Пожалуйста, заполните все поля.
И не нажимайте по два раза на кнопку! Дождитесь ответа сервера.