Content-Encoding header

Baseline Weitgehend verfügbar *

Diese Funktion ist gut etabliert und funktioniert auf vielen Geräten und in vielen Browserversionen. Sie ist seit Juli 2015 browserübergreifend verfügbar.

* Einige Teile dieser Funktion werden möglicherweise unterschiedlich gut unterstützt.

Der HTTP Content-Encoding Darstellungs-Header listet die Kodierungen und die Reihenfolge auf, in der sie auf eine Ressource angewendet wurden. Dies teilt dem Empfänger mit, wie die Daten dekodiert werden müssen, um das ursprüngliche Inhaltsformat zu erhalten, das im Content-Type-Header beschrieben ist. Content-Encoding 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, wo es angemessen ist, Content-Encoding verwenden. Das Komprimieren bereits komprimierter Medientypen, wie .zip oder .jpeg, ist normalerweise nicht sinnvoll, da dies die Dateigröße erhöhen kann. Wenn das ursprüngliche Medium bereits kodiert ist (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 und nicht auf die ursprüngliche Ressource, es sei denn, es ist ausdrücklich angegeben. Content-Encoding unterscheidet sich von Transfer-Encoding, da Transfer-Encoding behandelt, wie HTTP-Nachrichten selbst über das Netzwerk auf Hop-by-Hop-Basis übertragen werden.

Header-Typ Verbotener Anfrage-Header

Darstellungs-Header

Nein

In diesem Artikel

Syntax

http
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, das die Lempel-Ziv-Kodierung (LZ77) mit einem 32-Bit CRC verwendet. Dies ist das ursprüngliche Format des UNIX gzip Programms. Der HTTP/1.1-Standard empfiehlt auch, dass Server, die dieses Content-Encoding unterstützen, x-gzip als Alias erkennen, aus Gründen der Kompatibilität.

compress

Ein Format, das den Lempel-Ziv-Welch (LZW)-Algorithmus verwendet. Der Wertname wurde vom UNIX compress Programm übernommen, das diesen Algorithmus implementierte. Wie das compress Programm, das aus den meisten UNIX-Distributionen verschwunden ist, wird dieses Content-Encoding heute von vielen Browsern nicht mehr verwendet, teilweise aufgrund eines Patentproblems (es lief 2003 ab).

deflate

Verwendung der zlib-Struktur (definiert in RFC 1950) mit dem deflate-Kompressionsalgorithmus (definiert in RFC 1951).

Ein Format, das den Brotli-Algorithmus (definiert in RFC 7932) verwendet.

zstd

Ein Format, das den Zstandard-Algorithmus (definiert in RFC 8878) verwendet.

dcb

Ein Format, das den Dictionary-Compressed Brotli Algorithmus verwendet. Siehe Compression Dictionary Transport.

dcz

Ein Format, das den Dictionary-Compressed Zstandard Algorithmus verwendet. Siehe Compression Dictionary Transport.

Beispiele

Komprimierung mit gzip

Auf der Clientseite können Sie eine Liste von Komprimierungsschemata angeben, die in einer HTTP-Anfrage gesendet werden. Der Accept-Encoding-Header wird zur Aushandlung der Inhaltskodierung verwendet.

http

Accept-Encoding: gzip, deflate

Der Server antwortet mit dem verwendeten Schema, angezeigt durch den Content-Encoding-Antwortheader.

http

Content-Encoding: gzip

Ob ein Server die vom Client angeforderten Komprimierungsmethoden verwendet, hängt von der Serverkonfiguration und den Fähigkeiten ab.

Help improve MDN

War diese Übersetzung hilfreich?

Ja Nein

Erfahren Sie, wie Sie beitragen können Diese Seite wurde automatisch aus dem Englischen übersetzt.

Übersetzung auf GitHub anzeigen • Fehler mit dieser Übersetzung melden