LZH ist ein verlustfreies Datenkomprimierungsarchivformat, das nach Lempel-Ziv-Huffman benannt ist, den Algorithmen, auf denen es basiert. Es wurde erstmals 1987 von Haruyasu Yoshizaki als Verbesserung gegenüber den früheren Komprimierungsformaten LZ77 und LZ78 veröffentlicht, die Ende der 1970er Jahre von Abraham Lempel und Jacob Ziv entwickelt wurden. LZH bot effizientere Komprimierungsverhältnisse und ermöglichte gleichzeitig eine schnelle Dekomprimierung.
Die in LZH verwendeten Kernkomprimierungsalgorithmen basieren auf Wörterbüchern und nutzen zuvor gesehene Daten, um zukünftige Daten kompakter zu kodieren. Der Encoder verwaltet einen gleitenden Fensterpuffer der zuletzt verarbeiteten Daten. Wenn neue Daten gefunden werden, sucht der Encoder nach der längsten übereinstimmenden Sequenz im gleitenden Fenster. Wenn eine Übereinstimmung gefunden wird, werden die Daten als Referenz auf die übereinstimmende Fensterposition und -länge kodiert, anstatt als wörtliche Daten. Diese Referenz benötigt normalerweise weniger Speicherplatz als der ursprüngliche Inhalt.
LZ77, das als Grundlage für LZH verwendet wird, verfügt über eine Kodierungsschleife, die wie folgt aussieht: 1. Durchsuche das gleitende Fenster nach der längsten Übereinstimmung mit der bevorstehenden Eingabe 2. Gib das (Offset, Länge)-Paar aus, das sich auf die Übereinstimmung bezieht 3. Wenn keine Übereinstimmung gefunden wird, gib ein wörtliches Byte aus 4. Verschiebe das Fenster um die Übereinstimmungslänge nach vorne
1986 veröffentlichte Terry Welch einen verbesserten LZW-Algorithmus, der die Arbeit von LZ78 adaptierte. Er verwendete Indexnummern in einem Wörterbuch mit Zeichenfolgen, um eine höhere Dichte als LZ77 zu erreichen. Im nächsten Jahr wurde LZH veröffentlicht, das den gleitenden Wörterbuchansatz von LZ77 übernahm, aber als zusätzlichen Schritt die Huffman-Kodierung auf die LZ77-Symbole hinzufügte, um die Komprimierungsverhältnisse zu verbessern.
Die Huffman-Kodierung weist häufig verwendeten Symbolen kurze Bitfolgen und seltenen Symbolen längere Folgen zu. In LZH sind die möglichen Symbole wörtliche Bytes, End-of-Block-Markierungen und Übereinstimmungsreferenzen im gleitenden Fensterwörterbuch. Das Huffman-Kodierungsmodell wird für jeden Datenblock eindeutig basierend auf der Symbolhäufigkeitsverteilung dieses Blocks berechnet. Häufigeren Übereinstimmungsreferenzen werden kürzere Bitcodes zugewiesen. Dieser Entropiekodierungsschritt wird nach dem Abgleich mit dem gleitenden Fenster angewendet.
Die Dekomprimierung analysiert die Huffman-Codes variabler Länge aus dem Eingabestream und übersetzt sie zurück in wörtliche Bytes und Übereinstimmungsreferenzen. Referenzen werden aufgelöst, indem im Fensterpuffer auf die dekodierten Daten zurückgeblickt und die Übereinstimmung in die Ausgabe kopiert wird. Das Fenster wird nach jedem Symbol nach vorne verschoben. Die Dekomprimierung ist schnell, da keine Suche nach Übereinstimmungen erforderlich ist.
LZH-Dateien enthalten eine Reihe von Blöcken, die jeweils unabhängig mit diesem LZ77+Huffman-Modell komprimiert werden. Separate Blöcke ermöglichen wahlfreien Zugriff und Fehlerbehebung. Jeder Block beginnt mit einem Header, der die Huffman-Kodierungstabellen speichert, die zum Dekodieren der Daten dieses Blocks erforderlich sind.
Das Standard-LZH-Format ermöglicht eine gleitende Fenstergröße von 13 Bit oder 8.192 Bytes. Das Fenster wird normalerweise zu Beginn jedes Blocks auf alle Nullbytes initialisiert. Es wird kein voreingestelltes Wörterbuch verwendet, sondern nur zuvor komprimierte Daten. Übereinstimmungsreferenzen sind auf eine Länge von höchstens 256 Bytes beschränkt.
Nelson H.F. Beebe erweiterte LZH, um beliebig große gleitende Fenstergrößen zu unterstützen, und nannte sein Format LZHXa. Fenstergrößen sind auf Zweierpotenzen beschränkt, wobei 2^15 (32.768) und 2^16 (65.536) Bytes üblich sind. Durch Vergrößern des Fensters wird die Komprimierung verbessert, da mehr Verlaufsdaten durchsucht werden, was jedoch zu einer langsameren Kodierung und einem höheren Speicherverbrauch führt.
LZH enthält Prüfsummen, um die Datenintegrität zu überprüfen. Jeder Block endet mit einem 16-Bit-CRC-Code. Mehrdateiarchive speichern eine zusätzliche CRC für jede vollständige Datei. Die meisten Implementierungen verwenden CRC-16 mit dem Polynom x^16 + x^15 + x^2 + 1, einige verwenden jedoch CRC-16-CCITT.
Komprimierte LZH-Archive verwenden herkömmlicherweise die Dateierweiterung .lzh. Das Format fand in Japan die größte Verbreitung und erreichte Anfang der 1990er Jahre seinen Höhepunkt, als es mit ZIP und ARJ konkurrierte. Es entwickelte sich ein informeller Standard namens LHA, der von den beliebten Archivierern LArc und LHarc verwendet wurde. Es fügte Unterstützung für Kommentare, Zeitstempel, Passwörter und Mehrdateiarchive hinzu.
Die Hauptvorteile von LZH waren seine im Vergleich zu ZIP höheren Komprimierungsverhältnisse sowie die schnelle Dekomprimierung. Mitte der 1990er Jahre gewann ZIP jedoch an Popularität und verdrängte die meisten anderen Formate. Die schnelle Übernahme von ZIP als Standard unter Windows sowie die plattformübergreifende Bibliotheks- und Tool-Unterstützung führten dazu, dass es den Markt für verlustfreie Komprimierung dominierte.
Heute wird LZH außerhalb Japans und Ostasiens kaum noch verwendet. Neue Komprimierungsformate wie bzip2, LZMA und andere bieten deutlich bessere Komprimierungsverhältnisse. Einige Legacy-Anwendungen können immer noch auf .lzh-Dateien stoßen, für die Archivierung werden jedoch moderne ZIP-, 7z- oder xz-Formate empfohlen. Es gibt Open-Source-Tools wie lhasa, um alte .lzh-Archive zu extrahieren.
Zusammenfassend lässt sich sagen, dass LZH innovativ die Lempel-Ziv-Wörterbuchkodierung mit der Huffman-Bitreduktion kombinierte, um bei seiner Einführung eine hochmoderne Komprimierung zu erreichen. Es wurde kurzzeitig übernommen, insbesondere in Japan, bevor es vom ZIP-Standard überholt wurde. Es spielte jedoch eine wichtige Rolle in der Geschichte der Datenkomprimierung und der Entwicklung moderner Archivformate. LZH zeigte Techniken wie gleitende Fensterwörterbücher und Symbolentropiekodierung, die nach wie vor grundlegend für die effiziente Komprimierung von Daten sind.
Die Dateikomprimierung reduziert Redundanzen, damit dieselben Informationen mit weniger Bits auskommen. Die Obergrenze wird von der Informationstheorie gesetzt: Bei verlustfreier Komprimierung bestimmt die Entropie der Quelle das Limit (siehe Shannons Source-Coding-Theorem und seinen ursprünglichen Aufsatz von 1948 „A Mathematical Theory of Communication“). Bei verlustbehafteter Komprimierung beschreibt die Rate-Distortion-Theorie den Kompromiss zwischen Bitrate und Qualität.
Die meisten Kompressoren arbeiten in zwei Phasen. Zuerst sagt ein Modell Struktur in den Daten voraus oder legt sie frei. Danach wandelt ein Coder diese Vorhersagen in nahezu optimale Bitmuster um. Eine klassische Modellfamilie ist Lempel–Ziv LZ77 (1977) und LZ78 (1978) entdecken wiederholte Teilstrings und geben Referenzen statt Rohbytes aus. Auf der Codierungsseite weist die Huffman-Codierung (den Originalartikel finden Sie 1952) wahrscheinlicheren Symbolen kürzere Codes zu. Arithmetische Codierung und Range Coding arbeiten noch feiner und rücken näher an die Entropiegrenze, während moderne Asymmetric Numeral Systems (ANS) ähnliche Raten mit tabellengesteuerten Implementierungen erreichen.
DEFLATE (verwendet von gzip, zlib und ZIP) kombiniert LZ77 mit Huffman-Codierung. Die Spezifikationen sind öffentlich: DEFLATE RFC 1951, der zlib-Wrapper RFC 1950und das gzip-Dateiformat RFC 1952. Gzip ist für Streaming ausgelegt und garantiert ausdrücklich keinen zufälligen Zugriff. PNG-Bilder standardisieren DEFLATE als einzige Komprimierungsmethode (mit maximal 32 KiB Fenster) laut der PNG-Spezifikation „Compression method 0… deflate/inflate… at most 32768 bytes“ und W3C/ISO PNG 2nd Edition.
Zstandard (zstd): ein neuer Allzweckkompressor für hohe Raten bei sehr schneller Dekompression. Das Format ist dokumentiert in RFC 8878 (und dem HTML-Spiegel) sowie der Referenzspezifikation auf GitHub. Wie gzip zielt der Basis-Frame nicht auf zufälligen Zugriff. Eine der Superkräfte von zstd sind Wörterbücher: kleine Proben aus Ihrem Korpus, die viele kleine oder ähnliche Dateien deutlich besser komprimieren (siehe python-zstandard Wörterbuch-Dokumentation und Nigel Taos Beispiel). Implementierungen akzeptieren sowohl „unstrukturierte“ als auch „strukturierte“ Wörterbücher (Diskussion).
Brotli: optimiert für Web-Inhalte (z. B. WOFF2-Fonts, HTTP). Es kombiniert ein statisches Wörterbuch mit einem DEFLATE-ähnlichen LZ+Entropie-Kern. Die Spezifikation ist RFC 7932, der auch ein Gleitfenster von 2WBITS−16 mit WBITS in [10, 24] (1 KiB−16 B bis 16 MiB−16 B) beschreibt und festhält, dass es keinen zufälligen Zugriff bereitstellt. Brotli schlägt gzip bei Webtext oft und dekodiert trotzdem schnell.
ZIP-Container: ZIP ist ein Datei-Archiv, das Einträge mit verschiedenen Komprimierungsmethoden (deflate, store, zstd usw.) speichern kann. Der De-facto-Standard ist PKWAREs APPNOTE (siehe APPNOTE-Portal, eine gehostete Kopieund die LC-Überblicke ZIP File Format (PKWARE) / ZIP 6.3.3).
LZ4 zielt auf pure Geschwindigkeit bei moderaten Raten. Siehe die Projektseite („extremely fast compression“) und das Frame-Format. Ideal für In-Memory-Caches, Telemetrie oder Hot Paths, in denen Dekompression nahezu RAM-Geschwindigkeit erreichen muss.
XZ / LZMA strebt hohe Dichte (große Raten) mit relativ langsamer Kompression an. XZ ist ein Container; die Schwerarbeit leisten typischerweise LZMA/LZMA2 (LZ77-ähnliche Modellierung + Range Coding). Siehe .xz-Dateiformat, die LZMA-Spezifikation (Pavlov)und Linux-Hinweise zu XZ Embedded. XZ komprimiert meist besser als gzip und konkurriert oft mit modernen Hochratencodecs, braucht aber längere Encode-Zeiten.
bzip2 setzt auf die Burrows–Wheeler-Transformation (BWT), Move-to-Front, RLE und Huffman-Codierung. Typisch kleiner als gzip, aber langsamer; siehe das offizielle Handbuch und die Manpages (Linux).
Die „Fenstergröße“ zählt. DEFLATE-Referenzen können nur 32 KiB zurückblicken (RFC 1951) sowie das PNG-Limit von 32 KiB hier erläutert. Brotli deckt Fenster von etwa 1 KiB bis 16 MiB ab (RFC 7932). Zstd passt Fenster und Suchtiefe über die Level an (RFC 8878). Basis-Streams von gzip/zstd/brotli sind für sequentielles Dekodieren gebaut; die Grundformate versprechen keinen zufälligen Zugriff, obwohl Container (z. B. Tar-Indizes, Chunked Framing oder format-spezifische Indizes) ihn nachrüsten können.
Die oben genannten Formate sind verlustfrei: Sie rekonstruieren exakt dieselben Bytes. Medien-Codecs sind oft verlustbehaftet: Sie verwerfen unmerkliche Details, um niedrigere Bitraten zu erreichen. Bei Bildern ist klassisches JPEG (DCT, Quantisierung, Entropiecodierung) in ITU-T T.81 / ISO/IEC 10918-1standardisiert. In Audio nutzen MP3 (MPEG-1 Layer III) und AAC (MPEG-2/4) Wahrnehmungsmodelle und MDCT-Transformationen (siehe ISO/IEC 11172-3, ISO/IEC 13818-7und eine MDCT-Übersicht hier). Verlustbehaftet und verlustfrei können koexistieren (z. B. PNG für UI-Assets; Web-Codecs für Bilder/Video/Audio).
Theorie Shannon 1948 · Rate–distortion · Codierung Huffman 1952 · Arithmetische Codierung · Range Coding · ANS. Formate DEFLATE · zlib · gzip · Zstandard · Brotli · LZ4 frame · XZ format. BWT-Stack Burrows–Wheeler (1994) · bzip2 manual. Medien JPEG T.81 · MP3 ISO/IEC 11172-3 · AAC ISO/IEC 13818-7 · MDCT.
Fazit: Wählen Sie einen Kompressor, der zu Ihren Daten und Randbedingungen passt, messen Sie auf echten Eingaben und vergessen Sie nicht die Gewinne durch Wörterbücher und clevere Frames. Mit der richtigen Kombination erhalten Sie kleinere Dateien, schnellere Übertragungen und reaktionsschnellere Apps – ohne Korrektheit oder Portabilität zu opfern.
Dateikompression ist ein Prozess, der die Größe einer Datei oder Dateien reduziert, normalerweise um Speicherplatz zu sparen oder die Übertragung über ein Netzwerk zu beschleunigen.
Die Dateikompression funktioniert, indem sie Redundanzen in den Daten identifiziert und entfernt. Sie verwendet Algorithmen, um die ursprünglichen Daten in einem kleineren Raum zu kodieren.
Die beiden primären Arten der Dateikompression sind verlustfreie und verlustbehaftete Kompression. Verlustfreie Kompression ermöglicht die perfekte Wiederherstellung der Originaldatei, während verlustbehaftete Kompression eine größere Größenreduktion ermöglicht, dies jedoch auf Kosten eines Qualitätsverlusts bei den Daten.
Ein populäres Beispiel für ein Dateikompressionstool ist WinZip, das mehrere Kompressionsformate unterstützt, darunter ZIP und RAR.
Bei verlustfreier Kompression bleibt die Qualität unverändert. Bei verlustbehafteter Kompression kann es jedoch zu einem spürbaren Qualitätsverlust kommen, da weniger wichtige Daten zur Reduzierung der Dateigröße stärker eliminiert werden.
Ja, die Dateikompression ist sicher in Bezug auf die Datenintegrität, insbesondere bei der verlustfreien Kompression. Wie alle Dateien können jedoch auch komprimierte Dateien von Malware oder Viren angegriffen werden. Daher ist es immer wichtig, eine seriöse Sicherheitssoftware zu haben.
Fast alle Arten von Dateien können komprimiert werden, einschließlich Textdateien, Bilder, Audio, Video und Softwaredateien. Das erreichbare Kompressionsniveau kann jedoch zwischen den Dateitypen erheblich variieren.
Eine ZIP-Datei ist ein Dateiformat, das verlustfreie Kompression verwendet, um die Größe einer oder mehrerer Dateien zu reduzieren. Mehrere Dateien in einer ZIP-Datei werden effektiv zu einer einzigen Datei gebündelt, was das Teilen einfacher macht.
Technisch ja, obwohl die zusätzliche Größenreduktion minimal oder sogar kontraproduktiv sein könnte. Das Komprimieren einer bereits komprimierten Datei kann manchmal deren Größe erhöhen, aufgrund der durch den Kompressionsalgorithmus hinzugefügten Metadaten.
Um eine Datei zu dekomprimieren, benötigen Sie in der Regel ein Dekompressions- oder Entzip-Tool, wie WinZip oder 7-Zip. Diese Tools können die Originaldateien aus dem komprimierten Format extrahieren.