Content-Encoding
Baseline Widely available *
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
* Some parts of this feature may have varying levels of support.
Please take two minutes to fill out our short survey.
Der HTTP-Content-Encoding-Repräsentations-Header listet die Kodierungen und deren Reihenfolge auf, in der sie auf eine Ressource angewendet wurden. Damit wird dem Empfänger mitgeteilt, wie die Daten dekodiert werden müssen, um das ursprüngliche Inhaltsformat zu erhalten, das im Content-Type-Header beschrieben ist. Die Inhaltskodierung wird hauptsächlich verwendet, um Inhalte zu komprimieren, ohne Informationen über den ursprünglichen Medientyp zu verlieren.
Server sollten Daten so weit wie möglich komprimieren und dort eine Inhaltskodierung verwenden, wo es angemessen ist. Das Komprimieren von bereits komprimierten Medientypen wie .zip oder .jpeg ist in der Regel nicht sinnvoll, da dies die Dateigröße erhöhen kann. Sollte das ursprüngliche Medium bereits kodiert sein (z.B. als .zip-Datei), wird diese Information nicht im Content-Encoding-Header angegeben.
Wenn der Content-Encoding-Header vorhanden ist, beziehen sich andere Metadaten (z.B. Content-Length) auf die kodierte Form der Daten, nicht auf die ursprüngliche Ressource, es sei denn, es wird ausdrücklich darauf hingewiesen. Die Inhaltskodierung unterscheidet sich von der Transfer-Encoding, da Transfer-Encoding damit umgeht, wie HTTP-Nachrichten selbst über das Netzwerk auf hop-by-hop-Basis übertragen werden.
| Header-Typ | Repräsentations-Header |
|---|---|
| Verbotener Anforderungs-Header | Nein |
Syntax
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br
Content-Encoding: zstd
Content-Encoding: dcb
Content-Encoding: dcz
// Multiple, in the order in which they were applied
Content-Encoding: deflate, gzip
Direktiven
gzip-
Ein Format unter Verwendung der Lempel-Ziv-Kodierung (LZ77) mit einer 32-Bit-CRC. Dies ist das ursprüngliche Format des UNIX-gzip-Programms. Der HTTP/1.1-Standard empfiehlt auch, dass die Server, die diese Inhaltskodierung unterstützen,
x-gzipals Alias erkennen, zu Kompatibilitätszwecken. compress-
Ein Format unter Verwendung des Lempel-Ziv-Welch (LZW)-Algorithmus. Der Name des Werts stammt vom UNIX-compress-Programm, das diesen Algorithmus implementierte. Wie das Komprimierprogramm, das aus den meisten UNIX-Distributionen verschwunden ist, wird diese Inhaltskodierung heute von vielen Browsern nicht mehr verwendet, teilweise aufgrund eines Patentproblems (das 2003 abgelaufen ist).
deflate-
Unter Verwendung der zlib-Struktur (definiert in RFC 1950) mit dem Deflate-Kompressionsalgorithmus (definiert in RFC 1951).
br-
Ein Format unter Verwendung der Brotli-Algorithmusstruktur (definiert in RFC 7932).
zstd-
Ein Format unter Verwendung der Zstandard-Algorithmusstruktur (definiert in RFC 8878).
dcbExperimentell-
Ein Format, das den Dictionary-Compressed Brotli-Algorithmus verwendet. Siehe Transport von Kompressionswörterbüchern.
dczExperimentell-
Ein Format, das den Dictionary-Compressed Zstandard-Algorithmus verwendet. Siehe Transport von Kompressionswörterbüchern.
Beispiele
Komprimieren mit gzip
Auf der Clientseite können Sie eine Liste von Kompressionsschemata angeben, die in einer HTTP-Anfrage gesendet werden. Der Accept-Encoding-Header wird für die Aushandlung der Inhaltskodierung verwendet.
Accept-Encoding: gzip, deflate
Der Server antwortet mit dem verwendeten Schema, angegeben im Content-Encoding-Antwortheader.
Content-Encoding: gzip
Ob ein Server die vom Client angeforderten Komprimierungsmethoden verwendet, hängt von der Serverkonfiguration und den Möglichkeiten ab.
Spezifikationen
| Specification |
|---|
| HTTP Semantics # field.content-encoding |