gzip

gzip

Logo
Screenshot
Hilfeanzeige in der Kommandozeile
Basisdaten

MaintainerJim Meyering, Paul Eggert
EntwicklerJean-Loup Gailly und Mark Adler
Erscheinungsjahr1992
Aktuelle Version1.13[1]
(19. August 2023)
Betriebssystemplattformübergreifend verfügbar
Programmier­spracheC
KategorieDatenkompression
LizenzGPL (Freie Software)
gnu.org/software/gzip

gzip ist ein freies Kompressionsprogramm, das – ebenso wie das entsprechende Dateiformat gzip – praktisch für alle Computerbetriebssysteme verfügbar ist (unter den Bedingungen der GPL auch im Quelltext).

Allgemein ist gzip die Kurzform für „GNU zip“, wobei „zip“ vom englischen Wort für den Reißverschluss entlehnt wurde. OpenBSD hat eine BSD-lizenzierte Reimplementierung unter den Namen gzip(1), gunzip(1) sowie gzcat(1) vorgenommen, die völlig kompatibel zu den GNU-Werkzeugen ist.[2]

gzip bietet einen für Text zufriedenstellenden Kompressionsgrad und ist frei von patentierten Algorithmen (deflate wird verwendet). Es wurde ursprünglich von Jean-Loup Gailly entwickelt, um das unter Unix verwendete compress[3] zu ersetzen. Mark Adler schrieb das Dekompressionsprogramm gunzip.

Technik

gzip basiert auf dem Deflate-Algorithmus, der eine Kombination aus LZ77 und Huffman-Kodierung ist. Deflate wurde als Reaktion auf die Patente entwickelt, die auf LZW und anderen Kompressionsalgorithmen bestanden. Auch das ZIP-Dateiformat verwendet hauptsächlich Deflate zur Komprimierung, darf aber ansonsten nicht mit gzip verwechselt werden.

Die Fenstergröße bei gzip beträgt 32 KiB. Wenn eine Abfolge von Bytes sich in den vorherigen 32 KiB nicht wiederholt, wird sie unkomprimiert in der .gz-Datei gespeichert.[4] Diese Fenstergröße ist gegenüber modernen Kompressionsprogrammen (z. B. bzip2 mit 100 bis 900 KiB Blockgröße, rzip als Extremfall mit 900 MiB Fenstergröße) veraltet, jedoch ist gzip immer noch eines der schnellsten Kompressions-Programme und kann vielseitig eingesetzt werden, zum Beispiel in Verbindung mit einer sogenannten Pipeline – die Ausgabe („standard out“) eines Programms kann die Eingabe („standard in“) von gzip darstellen und umgekehrt.

Um die Entwicklung von Software zu vereinfachen, die Datenkompression nutzt, wurde die zlib-Bibliothek geschrieben. Sie unterstützt das gzip-Dateiformat und die Deflate-Kompression. Die Bibliothek ist weit verbreitet, da sie klein, effizient und vielseitig ist.

Aufbau

Das Archiv-Dateiformat für gzip ist gemäß RFC 1952 in Version 4.3 vom Mai 1996 spezifiziert.[5] Wenn einzelne Dateien mit gzip komprimiert werden, werden auch diverse Metadaten gespeichert, u. a. das Betriebssystem, unter dem das Archiv erstellt wurde, sowie die einzelnen Dateinamen und ihre Modifikationszeiten.

Auf modernen Betriebssystemen ergeben sich in dieser letzten Version des Archivformats bei den Metadaten folgende Einschränkungen:

  • Die Dateigröße der Quelldatei ist auf Modulo 232 (entspricht 4 GiB) begrenzt, sodass unkomprimierte Dateigrößen > 4 GiB nicht korrekt angezeigt werden können, obwohl die Dateien selbst korrekt komprimiert wurden und auch dekomprimiert werden können. Es gibt jedoch Workarounds um die korrekten unkomprimierten Dateigrößen zu ermitteln.
  • Die Modifikationszeit ist in der Zukunft auf den 7. Februar 2106, 06:28:15 UTC, beschränkt und speichert nur Sekundengenau. Moderne 64-Bit-Systeme unterstützen jedoch meist auch Mikro- und Nanosekunden – diese können in einem GZIP-Archiv weder gespeichert werden noch können sie wiederhergestellt werden. Auf einigen 32-Bit-Systemen hingegen ist das reale Limit für die Modifikationszeit in der Zukunft real niedriger, wenn diese vom Jahr-2038-Problem betroffen sind, was auf allen älteren Unix-artigen Betriebssystemen der Fall ist.[6]

Eine Gzip-Datei besteht aus folgenden Komponenten in dieser Reihenfolge:

Größe(bytes)OptionalKomponente
10NeinHeader
dynamischJaZusatzinformationen
dynamischJaOriginal-Dateiname
dynamischJaDateikommentar
2JaCRC16 Prüfsumme für Header, Zusatzinformationen, Original-Dateiname und Dateikommentar
dynamischNeinkomprimierte Nutzdaten
4NeinCRC32 Prüfsumme für die unkomprimierte Quelldatei
4NeinGröße der unkomprimierten Quelldatei Modulo 232
PositionLänge(bytes)KürzelBedeutung
02ID1, ID2Magische Zahl (immer 0x1F, 0x8B)
21CMKompressionsmethode

0x00 bis 0x07 sind reserviert. 0x08 bedeutet „Deflate“.

31FLGBitfeld, siehe FLG-Bitfeld
44MTIMEModifikationszeitstempel als Unixzeit, ein Nullwert bedeutet das kein Zeitstempel verfügbar ist.
81XFLkompressionsmethodenspezifische Zusatzinformationen

Für Deflate sind folgende Werte definiert: 0x02 = Des Kompressionsprogramm hat den stärksten, langsamsten Algorithmus angewandt. 0x04 = Das Kompressionsprogramm hat den schnellsten Algorithmus angewandt.

91OSArt des Dateisystems bzw. Betriebssystems von welchem aus die Kompression durchgeführt wurde.

Siehe Betriebssystemtabelle.

FLG-Bitfeld

Wichtig ist, dass hier immer die Bits beachtet werden. Das bedeutet, dass z. B. 00010011 (binär) = 19 (dezimal) = 0x13 (hexadezimal) folgendes aussagt: Die Datei ist wahrscheinlich ASCII-Text, eine CRC-16 Prüfsumme ist vorhanden, optionale Zusatzinformationen sind nicht vorhanden, der originale Dateiname ist nicht vorhanden und ein Dateikommentar ist vorhanden.

BitpositionDezimalwertKürzelBedeutung
01FTEXTDatei ist wahrscheinlich ASCII-Text
12FHCRCCRC-16 Prüfsumme ist vorhanden
24FEXTRAZusatzinformationen sind vorhanden
38FNAMEOriginal-Dateiname ist vorhanden
416FCOMMENTDateikommentar ist vorhanden
532Reserviert (muss 0 sein)
664Reserviert (muss 0 sein)
7128Reserviert (muss 0 sein)

Betriebssystemtabelle

Byte WertBedeutung
0FAT (Dateisystem)
1AmigaOS
2VMS oder OpenVMS
3Unix
4VM oder CMS
5Atari TOS
6HPFS (Dateisystem)
7Macintosh (Plattform), Mac OS (Betriebssystem)
8Z-System
9CP/M
10TOPS-20
11NTFS (Dateisystem)
12QDOS
13Acorn RISC OS
255Unbekannt

Optionale Felder

Zusatzinformationen

Wenn FEXTRA gesetzt ist, folgt ein zwei Byte großes Feld, welches die Größe der Zusatzinformationen angibt, gefolgt von den Zusatzinformationen selbst in einem speziellen Format.

Original-Dateiname

Wenn FNAME gesetzt ist, folgt der Original-Dateiname als nullterminierte Zeichenkette mit ISO 8859-1 Kodierung.

Dateikommentar

Wenn FCOMMENT gesetzt ist, folgt der Dateikommentar als nullterminierte Zeichenkette mit ISO 8859-1 Kodierung. Der Dateikommentar ist nicht programmatisch zu interpretieren und dient nur dazu vom Endbenutzer gelesen zu werden.

CRC-16 Prüfsumme

Wenn FHCRC gesetzt ist, folgt die CRC-16 Prüfsumme, bestehend aus den zwei niedrigen Bytes der CRC-32 Prüfsumme des Headers inklusive der optionalen Felder(mit Ausnahme der Prüfsumme selbst).

CRC-32 Prüfsumme und Dateigröße

Es folgen eine CRC-32 Prüfsumme und die Größe der unkomprimierten Originaldatei. Die Dateigröße wird Modulo 232 gespeichert, was zur Folge hat, dass das Dateigrößenfeld bei Dateigrößen > 4 GiB nicht aussagekräftig ist.

Beispielaufrufe

Eine Datei packen:

gzip <Dateiname>

Eine gepackte Datei entpacken:

gzip -d <Dateiname>

oder

gunzip <Dateiname>

Rekursiv alle Dateien in einem Verzeichnis packen und die Kompressionsrate angeben:

gzip -rv <Verzeichnis>

Eine komprimierte Text-Datei ausgeben:

zcat <Dateiname>

Eine defekte komprimierte Datei bis zur Fehlerstelle entpacken:

zcat <gzip-Datei> > <Ziel-Datei>

Ermittlung der unkomprimierten Dateigröße bei archivierten Dateien, die größer als 4 GiB sind:[7]

zcat <gzip-Datei> | wc -c

gzip-komprimierte Dateien

gzip
Dateiendung:.gz
MIME-Type:application/gzip[8]
Magische Zahl:\x1F\x8B\x08

(ASCII-C-Notation)

Entwickelt von:Jean-Loup Gailly und Mark Adler
Aktuelle Version1.13[1]
(19. August 2023)
Art:Datenkompression
Container für:eine beliebige Datei
Erweitert von:compress
Standard(s):RFC 1952[5]
gzip.org

Die übliche Dateiendung für gzip-komprimierte Dateien ist heute .gz, früher auch .z.

Da gzip nur einzelne Dateien komprimieren kann, werden mehrere Dateien bzw. Verzeichnisbäume üblicherweise zunächst mit tar zu einer Tarball genannten Archivdatei zusammengefasst, welche anschließend mit gzip komprimiert wird.

Zunächst werden Dateien (Kreise) mit tar gepackt, anschließend wird dieses Archiv mit gzip komprimiert.

Solche komprimierten Archivdateien tragen dann meist die doppelte Endung .tar.gz oder auch einfach .tgz. Diese Methode ermöglicht insgesamt bessere Komprimierung, da so Redundanzen zwischen den einzelnen Dateien ausgenutzt werden können (progressive Kompression), erschwert aber den Zugriff auf die einzelnen Bestandteile.

Verbreitung

Unter Unix ist die Komprimierung mit gzip heute Standard, weil sie für viele Aufgaben einen guten Kompromiss aus hoher Geschwindigkeit und guter Datenreduktion ermöglicht. Wo es weniger auf Geschwindigkeit als auf minimale Dateigrößen ankommt (etwa bei der breiten Verteilung von Daten über relativ langsame Netze), werden allerdings zunehmend bzip2 und LZMA verwendet (ebenso wie bei gzip in Kombination mit tar).

Das zlib-komprimierte Dateiformat, der Deflate-Algorithmus und das gzip-Dateiformat wurden 1996 als Request for Comments RFC 1950,[9] RFC 1951[10] und RFC 1952[5] standardisiert.

Siehe auch

  • Brotli ist ein Datenkompressions-Algorithmus auf Basis von LZ77 und Huffman-Kodierung, der von Zoltán Szabadka und Jyrki Alakuijala entwickelt wurde
  • Zopfli wird als der dateigrößeneffizienteste verfügbare Deflate-Kodierer angesehen
  • pigz ist eine von Mark Adler programmierte Version von gzip, welche sämtliche verfügbaren Prozessorkerne und -threads benutzt, und so die Kompression merklich beschleunigt
  • Liste von Datenkompressionsprogrammen
  • gzip.org – ursprüngliche Projektseite (englisch)
  • P. Deutsch: RFC1952 – GZIP File Format Specification version 4.3. Mai 1996 (englisch).
  • gzip(1): gzip, gunzip, zcat – Dateien komprimieren und expandieren – Debian GNU/Linux Ausführbare Programme oder Shell-Befehle Handbuchseite
  • goethe.ira.uka.de (Memento vom 8. September 2012 im Internet Archive) ira.uka.de – gut verständliche Beschreibung der verschiedenen Komprimiermöglichkeiten

Einzelnachweise

  1. a b Jim Meyering: gzip-1.13 released [stable]. 19. August 2023 (abgerufen am 20. August 2023).
  2. gzip(1): compress and expand data (deflate mode) – OpenBSD General Commands Manual
  3. compress: compress data – Open Group Base Specification
  4. Jean-loup Gailly, Mark Adler:Compression algorithm (deflate) (Memento vom 16. Februar 2014 im Internet Archive) gzip.org. 1. September 1997 (Last-Modified).
  5. a b c P. Deutsch: RFC1952 – GZIP File Format Specification version 4.3. Mai 1996 (englisch).
  6. GNU Gzip Documentation. Free Software Foundation, abgerufen am 15. September 2020 (englisch).
  7. GNU Gzip Documentation. Free Software Foundation, abgerufen am 15. September 2020 (englisch).The gzip format represents the input size modulo 2^32, so the uncompressed size and compression ratio are listed incorrectly for uncompressed files 4 GiB and larger. To work around this problem, you can use the following command to discover a large uncompressed file’s true size: zcat file.gz | wc -c
  8. RFC6713 – The ‘application/zlib’ and ‘application/gzip’ Media Types. August 2012 (englisch).
  9. RFC1950 – ZLIB Compressed Data Format Specification version 3.3. Mai 1996 (englisch).
  10. RFC1951 – DEFLATE Compressed Data Format Specification version 1.3. Mai 1996 (englisch).

Auf dieser Seite verwendete Medien

Gzip-screenshot.png
Autor/Urheber: Meph666 in der Wikipedia auf Deutsch
, Lizenz: GPL
Screenshot der Kommandozeilenhilfe von de:gzip
Targzip.svg
Autor/Urheber: Th0msn80, Lizenz: CC BY 3.0
Schema of tar-creation and compressing via gzip. In this diagram, the entropy of data corresponds with how much of the data can fit in a square of the same width and height: the more that can fit, the more it has been compressed and the higher the entropy. The files are represented as circles and the gzip stream is represented as a square to show the change in entropy. The tar container data occupies space equal to the area of the green rectangle (shown in the middle), and the file data occupies space equal to the area to the blue circles. Mathematically, they are in a ratio approximately 25:39, respectively. 64 blocks are shown in the gzip stream: the 25 green blocks are compressed tar container data and the 39 blue blocks are compressed file data. In real-world situations, certain data would be difficult to compress, such as a JPG image, and in the gzip stream, it would consume several times more data than the tar container data as tar data is relatively simple to compress. Other types of data, such as those with unusually long run-lengths, might be easier to compress than tar data.
Gzip-Logo.png
gzip Logo