Gibt es eine Möglichkeit zu überprüfen, ob ein Puffer im Brotli-Format vorliegt?

Question

Ich bin ein Praktikant Forschung darüber, ob die Verwendung von Brotli Kompression in einer Software bietet eine Leistungssteigerung gegenüber der aktuellen Version, die GZip verwendet.

Meine Aufgabe ist es, alles mit GZip zu ändern, stattdessen Brotli Kompression zu verwenden. Eine Funktion, die ich ersetzen muss, überprüft, ob ein Puffer Daten enthält, die mit GZip komprimiert wurden. Es tut dies durch die Stromkennung am Anfang überprüft und Ende:

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); 
} 

I ähnliche Funktion bool isBrotliEncoded() erstellen möchten. Ich frage mich, ob es eine ähnliche schnelle Überprüfung gibt, die mit Brotli-kodierten Puffern durchgeführt werden kann? Ich habe mir die Byte-Werte für einige der komprimierten Dateien angesehen, die brotli produziert, aber ich kann keine Regel finden, die für alle von ihnen gilt. Einige beginnen mit 0x5B, andere mit 0x1B, Komprimierung von leeren Dateien führt zu 0x06, und Dateien, die mehrere Male komprimiert wurden, beginnen mit einer Reihe unterschiedlicher Werte. Das Ende jeder Datei ist ebenfalls inkonsistent.

Die einzige Möglichkeit zu testen, ob es im richtigen Format ist, ist Dekompression versuchen und warten auf einen Fehler, der den Zweck dieses Tests vereitelt.

Also meine Frage ist: Weiß jemand, wie man überprüft, ob ein Puffer mit Brotli komprimiert wurde, ohne Dekompression zu versuchen und auf Fehler zu warten?

Answer 1

Leider ist das rohe Brotli-Format für solche Erkennung nicht gut geeignet, auch wenn es einfach versucht, zu dekomprimieren und auf einen Fehler zu warten.

Ich lief eine Studie von einer Million Brotli Dekomprimierungen von Zufallsdaten. Ungefähr 5% von ihnen überprüften als gute brotli Ströme. Du hast also schon ein Problem. 3,5% der Million sind ein einzelnes Byte, da es neun Ein-Byte-Werte gibt, die jeweils ein gültiger Brötli-Strom sind. Die durchschnittliche Länge der zufällig gültigen Streams betrug fast ein Megabyte.

Für diejenigen, bei denen ein Fehler festgestellt wurde (ca. 95% der Millionen Fälle), sind 3,5% mehr als ein Megabyte vergangen, bevor der Fehler erkannt wurde. 1,4% gingen mehr als zehn Megabyte. Die durchschnittliche Anzahl der zufälligen Bytes vor dem Auffinden eines Fehlers betrug 309 KB. Ein weiteres Problem.

Kurz gesagt, die Wahrscheinlichkeit eines falsch positiven ist relativ hoch, und die Anzahl der Bytes, die verarbeitet werden müssen, um ein Negativ zu finden, kann ziemlich groß sein.

Wenn Sie diese Software schreiben, sollten Sie Ihre eigene Kopfzeile vor den Brottli-Daten setzen, um die Erkennung zu erleichtern. Oder Sie können das brotli framing format that I developed at their request verwenden, das einen eindeutigen Vier-Byte-Header vor dem komprimierten bolli-Stream hat. Dies würde die Wahrscheinlichkeit eines falschen Positivs dramatisch reduzieren.

Answer 2

Brotli ist formal in RFC 7932 definiert. Das Format des Datenstroms ist in Section 2: Compressed Representation Overview und Section 9: Compressed Data Format abgedeckt. Brotli verwendet keine führenden/nachgestellten Bezeichner wie gzip, aber es besteht aus einer Folge von unkomprimierten Headern und Befehlen, die die komprimierten Daten beschreiben. Sie sind nicht alle auf Byte-Grenzen ausgerichtet, sondern müssen stattdessen auf der Bit-Ebene analysiert werden (Brotli wird als ein Strom von Bits und Bytes verarbeitet). Informationen zum Lesen dieser Header finden Sie unter Section 10: Decoding Algorithm. Wenn Sie ein paar Header, die dem Brotli-Format folgen, ohne Fehler analysieren, dann ist es gut, dass Sie es mit einem Brotli-komprimierten Puffer zu tun haben.