5. Content-Type Header-Feld (Content-Type Header Field)
Der Zweck des Content-Type-Feldes besteht darin, die im Body enthaltenen Daten so vollständig zu beschreiben, dass der empfangende Benutzeragent (User Agent) einen geeigneten Agenten oder Mechanismus auswählen kann, um die Daten dem Benutzer zu präsentieren oder die Daten auf andere angemessene Weise zu verarbeiten. Der Wert in diesem Feld wird als Medientyp (Media Type) bezeichnet.
HISTORISCHE ANMERKUNG: Das Content-Type-Header-Feld wurde erstmals in RFC 1049 definiert. RFC 1049 verwendete eine einfachere und weniger leistungsfähige Syntax, die jedoch weitgehend mit dem hier angegebenen Mechanismus kompatibel ist.
Das Content-Type-Header-Feld spezifiziert die Art der Daten im Body einer Entität, indem es Medientyp- und Subtyp-Identifikatoren angibt und Hilfsinformationen bereitstellt, die für bestimmte Medientypen erforderlich sein können. Nach den Medientyp- und Subtyp-Namen ist der Rest des Header-Feldes einfach ein Satz von Parametern, die in einer attribute=value-Notation spezifiziert sind. Die Reihenfolge der Parameter ist nicht signifikant.
Im Allgemeinen wird der Top-Level-Medientyp verwendet, um den allgemeinen Datentyp zu deklarieren, während der Subtyp ein spezifisches Format für diesen Datentyp angibt. Somit genügt ein Medientyp von "image/xyz", um einem Benutzeragenten mitzuteilen, dass die Daten ein Bild sind, selbst wenn der Benutzeragent keine Kenntnis des spezifischen Bildformats "xyz" hat. Solche Informationen können beispielsweise verwendet werden, um zu entscheiden, ob einem Benutzer die Rohdaten eines nicht erkannten Subtyps angezeigt werden sollen oder nicht - eine solche Aktion könnte für nicht erkannte Subtypen von Text vernünftig sein, nicht jedoch für nicht erkannte Subtypen von Bild oder Audio. Aus diesem Grund sollten (should not) registrierte Subtypen von Text, Bild, Audio und Video keine eingebetteten Informationen enthalten, die tatsächlich von einem anderen Typ sind. Solche zusammengesetzten Formate sollten unter Verwendung der Typen "multipart" oder "application" dargestellt werden.
Parameter sind Modifikatoren des Medien-Subtyps und ändern als solche nicht grundlegend die Natur des Inhalts. Die Menge der bedeutungsvollen Parameter hängt vom Medientyp und Subtyp ab. Die meisten Parameter sind mit einem einzelnen spezifischen Subtyp verbunden. Ein gegebener Top-Level-Medientyp kann jedoch Parameter definieren, die auf jeden Subtyp dieses Typs anwendbar sind. Parameter können durch ihren definierenden Inhaltstyp oder Subtyp erforderlich sein oder optional sein. MIME-Implementierungen müssen (must) alle Parameter ignorieren, deren Namen sie nicht erkennen.
Beispielsweise ist der Parameter "charset" auf jeden Subtyp von "text" anwendbar, während der Parameter "boundary" für jeden Subtyp des Medientyps "multipart" erforderlich ist.
Es gibt KEINE (NO) global bedeutungsvollen Parameter, die auf alle Medientypen anwendbar sind. Mechanismen, die in MIME als global angesehen werden könnten, werden im MIME-Modell am besten durch die Definition zusätzlicher Content-*-Header-Felder adressiert.
Ein anfänglicher Satz von sieben Top-Level-Medientypen ist in RFC 2046 definiert. Fünf davon sind diskrete Typen (Discrete Types), deren Inhalt in Bezug auf die MIME-Verarbeitung undurchsichtig ist. Die verbleibenden zwei sind zusammengesetzte Typen (Composite Types), deren Inhalt zusätzliche MIME-Verarbeitung erfordert.
Dieser Satz von Top-Level-Medientypen ist als im Wesentlichen vollständig beabsichtigt. Es wird erwartet, dass Ergänzungen der größeren Menge unterstützter Typen im Allgemeinen durch die Erstellung neuer Subtypen dieser anfänglichen Typen erreicht werden können. In Zukunft können weitere Top-Level-Typen nur durch eine Standards-Track-Erweiterung dieses Standards definiert werden. Wenn ein anderer Top-Level-Typ aus irgendeinem Grund verwendet werden soll, muss (must) ihm ein Name gegeben werden, der mit "X-" beginnt, um seinen nicht standardisierten Status anzuzeigen und einen potenziellen Konflikt mit einem zukünftigen offiziellen Namen zu vermeiden.
5.1. Syntax des Content-Type Header-Feldes (Syntax of the Content-Type Header Field)
In der erweiterten BNF-Notation von RFC 822 ist ein Content-Type-Header-Feldwert wie folgt definiert:
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token
composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
subtype := extension-token / iana-token
iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
5.2. Content-Type-Standardwerte (Content-Type Defaults)
Wenn ein Content-Type-Header-Feld in einer Entität nicht vorhanden ist, hängt der Standard-Content-Type vom Kontext ab:
- Auf der obersten Ebene einer MIME-Nachricht ist der Standard
text/plain; charset=us-ascii - Innerhalb eines Body-Parts einer Multipart-Entität ist der Standard-Content-Type
text/plain; charset=us-ascii - Innerhalb einer "message/rfc822"-Entität ist der Standard-Content-Type
text/plain; charset=us-ascii
Schlüsselpunkte:
- Content-Type-Format:
type/subtype; parameter=value - Typ und Subtyp sind nicht von Groß-/Kleinschreibung abhängig
- Parameternamen sind nicht von Groß-/Kleinschreibung abhängig, aber Werte sind normalerweise abhängig
- Standardwert:
text/plain; charset=us-ascii
Sieben Top-Level-Medientypen:
Diskrete Typen (Discrete Types)
- text: Textdaten
- image: Bilddaten
- audio: Audiodaten
- video: Videodaten
- application: Anwendungsdaten
Zusammengesetzte Typen (Composite Types)
- message: Gekapselte Nachricht
- multipart: Mehrere Teile