Алгоритмы сжатия специально оптимизированы для содержимого HTML?

Question

Существуют ли какие-либо алгоритмы сжатия - с потерями или без потерь, которые были специально адаптированы для работы с реальным (грязным и недействительным) контентом HTML?

Если нет, какими характеристиками HTML мы могли бы воспользоваться, чтобы создать такой алгоритм? Каковы потенциальные улучшения производительности?

Кроме того, я не задаю вопрос о предоставлении такого контента (через Apache или любой другой сервер), хотя это, конечно, интересно, но хранить и анализировать его.

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

Answer 1

Я не знаю о готовой библиотеке сжатия явно , оптимизированной для содержимого HTML .

Тем не менее, HTML-текст должен хорошо сжиматься с помощью универсальных алгоритмов (прочитайте основание этого ответа для лучших алгоритмов). Как правило, все варианты Lempel-Ziv хорошо работают на HTML-подобных языках благодаря высокой повторяемости определенных языковых идиом; GZip , который часто цитируется, использует такой алгоритм на основе LZ (я думаю, LZ77).

Идея, возможно, улучшить эти универсальные алгоритмы состояла бы в том, чтобы заполнить круговой буфер типа LZ наиболее распространенными html-тегами и шаблонами в целом. Таким образом, мы уменьшили бы сжатый размер, используя цитаты из самого первого экземпляра такого шаблона. Это усиление будет особенно чувствительным для небольших HTML-документов.

Дополнительная, похожая идея состоит в том, чтобы методы сжатия и распаковки подразумевали (то есть не отправляли) информацию для другого алгоритма сжатия алгоритма LZ-x (скажем, дерево Хаффмана в случае LZH и т. Д.) при статистике, характерной для типичного HTML, следует тщательно исключать из символов подсчет [статистически взвешенных] экземпляров символов, закодированных цитатой. Такое отфильтрованное распределение символов, вероятно, станет ближе к обычному английскому (или национальному языку целевых веб-сайтов), чем к полному тексту HTML.

---

Не имея отношения к вышеизложенным [образованным, я надеюсь] догадкам, я начал искать в Интернете информацию по этой теме.

'нашел это 2008 научная статья (формат pdf) Пшемыслава Скибинского из Вроцлавского университета. Аннотация статьи указывает на улучшение на 15% по сравнению с GZIP при сопоставимой скорости сжатия .

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

Answer 2

Достаточно ли gzip сжатия для ваших нужд? Это дает вам степень сжатия 10: 1, не только с содержимым HTML, но также с JavaScript, CSS и т.д. файлов и легко доступны на большинстве серверов или обратных прокси (например, Apache mod_deflate, Nginx NginxHttpGzipModule и т. д.) и во всех современных браузерах (вы можете поручить Apache и Nginx пропускать сжатие для определенных браузеров на основе User-Agent.)

Вы будете удивлены, насколько близко gzip сжатие к оптимальному. Некоторые люди предлагают минимизировать ваших файлов ; однако, если ваши файлы не содержат много комментариев (которые минификатор может полностью отбросить, т. е. то, что вы, вероятно, называете «потерями»), но что-то, что вы, вероятно, не хотите делать с HTML в любом случае, если только вы не уверены, что ни один из ваших тегов <script> или <style> не находится внутри HTML-комментариев <!-- --> для размещения допотопных браузеров), помните, что минимизация достигает большей части своей выгоды от техники, аналогичной (но более ограниченной, чем) DEFLATE - поэтому ожидайте, что минимизированный файл будет больше или намного больше, чем gzip оригинал (особенно это касается HTML, в котором вы застряли с тегами и атрибутами W3C, и только gzip может помочь вы там), и что gzip пинг минифицированного файла даст вам минимальный выигрыш по сравнению с gzip по сравнению с оригинальным файлом (опять же, если исходный файл не содержит много комментариев, которые могут быть безопасно удалены Minifier.)

Answer 3

Brotli - это специализированный алгоритм сжатия HTML / English.

Источник: https://en.wikipedia.org/wiki/Brotli

В отличие от большинства алгоритмов сжатия общего назначения, Бротли использует предопределенный словарь на 120 килобайт. Словарь содержит более 13000 общих слов, фраз и других подстрок, полученных из большого корпус текстовых и HTML документов. [6] [7] Предопределенный словарь может повысить плотность сжатия для коротких файлов данных.

Answer 4

О единственной «потере», с которой я готов иметь дело в контенте HTML, грязном или нет, является выравнивание пробелов. Это типичный шаг после публикации, который выполняют сайты с большим объемом контента, также называемый выравниванием.

Вы также можете выравнивать большие библиотеки Javascript с помощью YUI-компрессора, который переименовывает все переменные Javascript в короткие имена, удаляет пробелы и т. Д. Это очень важно для больших приложений, использующих такие наборы, как ExtJS, Dojo и т. Д.

Answer 5

Вы можете рассматривать каждую уникальную группу (т. Е. Теги и атрибуты) как символ, определять минимальное количество символов и перекодировать с использованием энтропии Шеннона; это сгенерирует один большой блок байтов с максимальным сжатием. Я скажу, что это не намного лучше, чем gzip.

Answer 6

Используйте вместо этого S-выражения, сохраняя количество символов в теге:)

Answer 7

Обычно вы используете общий алгоритм, такой как gzip, который поддерживается большинством браузеров по протоколу HTTP. Документация Apache показывает, как включить mod_deflate, не нарушая поддержку браузера вашего сайта.

Кроме того, вы можете минимизировать статические файлы HTML (или делать это динамически).

Answer 8

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

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

Answer 9

Запустите ваш код через некоторый минимизатор / обфускатор HTML, который удаляет как можно больше разметки, а затем разрешите вашему веб-серверу сжать его с помощью gzip.

Answer 10

Gzip обычно используется для сжатия веб-страниц (например, HTML), но некоторые версии IE не поддерживают его.

Статья в Википедии