Есть ли способ проверить, находится ли буфер в сжатом формате Brotli?
Я стажер, занимаюсь исследованием того, обеспечивает ли сжатие Brotli в программном обеспечении повышение производительности по сравнению с текущей версией, в которой используется GZip.
Моя задача — изменить что-либо, используя GZip, вместо этого использовать сжатие Brotli. Одна функция, которую мне нужно заменить, выполняет проверку, чтобы проверить, содержит ли буфер данные, сжатые с помощью GZip. Это делается путем проверки идентификатора потока в начале и конце:
bool isGzipped() const
{
// Gzip file signature (0x1f8b)
return
(_bufferEnd >= _bufferStart + 2) &&
(static_cast<unsigned char>(_bufferStart[0]) == 0x1f) &&
(static_cast<unsigned char>(_bufferStart[1]) == 0x8b);
}
Я хочу создать подобную функцию bool isBrotliEncoded(), Мне было интересно, есть ли подобная быстрая проверка, которая может быть сделана с закодированными буферами Brotli? Я взглянул на значения в байтах для некоторых сжатых файлов, которые создает brotli, но я не могу найти правило, которое подходит для всех из них. Некоторые начинают с 0x5Bнекоторые с 0x1B, сжатие пустых файлов приводит к 0x06и файлы, которые были сжаты несколько раз, начинаются с диапазона различных значений. Конец каждого файла также несовместим.
Единственный известный мне способ проверить, находится ли он в правильном формате, — это попытаться распаковать и дождаться ошибки, которая не отвечает цели проведения этого теста.
Итак, мой вопрос: кто-нибудь знает, как проверить, был ли буфер сжат с помощью Brotli, не пытаясь распаковать и ждать сбоя?
Решение
К сожалению, необработанный формат brotli не очень подходит для такого обнаружения, даже когда он просто пытается распаковать и ждет ошибки.
Я провел испытание миллиона разборок случайных данных. Около 5% из них зарекомендовали себя как хорошие потоки brotli. Итак, у вас уже есть проблема. 3,5% от миллиона составляют один байт, поскольку существует девять однобайтовых значений, каждое из которых является допустимым потоком brotli. Средняя длина случайных действительных потоков была почти мегабайт.
Для тех, в которых была обнаружена ошибка (около 95% миллионов случаев), 3,5% превысили мегабайт до того, как была обнаружена ошибка. 1,4% ушло более десяти мегабайт. Среднее количество случайных байтов до обнаружения ошибки составляло 309 КБ. Другая проблема.
Короче говоря, вероятность ложного срабатывания относительно высока, и число байтов для обработки, чтобы найти отрицательный результат, может быть довольно большим.
Если вы пишете это программное обеспечение, то вы должны поставить свой собственный заголовок перед данными brotli, чтобы помочь в обнаружении. Или вы можете использовать формат фреймворка, который я разработал по их просьбе, который имеет уникальный четырехбайтовый заголовок перед сжатым потоком brotli. Это значительно уменьшило бы вероятность ложного срабатывания.
Другие решения
Бротли формально определяется в RFC 7932. Формат потока данных рассматривается в Раздел 2: Обзор сжатого представления а также Раздел 9: сжатый формат данных. Brotli не использует начальные / конечные идентификаторы, как это делает gzip, но он состоит из последовательности несжатых заголовков и команд, которые описывают сжатые данные. Они не все выровнены по границам байтов, вместо этого вы должны анализировать их на уровне битов (Brotli обрабатывается как поток битов и байтов). Ссылаться на Раздел 10: Алгоритм декодирования как читать эти заголовки. Если вы без ошибок разбираете несколько заголовков, которые следуют формату Brotli, то лучше иметь дело с сжатым буфером Brotli.
detector