Standardfelder des MIME-Headers

Dieser Abschnitt bietet eine Zusammenfassung der allgemeinen MIME-Header und soll als Kurzübersicht dienen. Er enthält keine definitive Spezifikation von MIME. In einigen Fällen lässt der MIME-Parser Dokumente zu, die strenggenommen nicht dem Standard entsprechen. Beispielsweise besteht er nicht auf dem Vorhandensein eines MIME-Version-Headers. Alle standardmäßigen MIME-Headerfelder werden einfach in der Reihenfolge, in der sie im MIME-Dokument vorkommen, in die logische Baumstruktur geschrieben. Für den MIME-Parser hat nur das Headerfeld 'Content-Type' (Inhaltstyp) eine besondere Bedeutung.

Alle MIME-Header können Kommentare in runden Klammern enthalten (siehe Beispiel für MIME-Version-Header).

MIME-Headerfelder

MIME-Version

Beispiel:

MIME-version: 1.0 (generiert von meiner Anwendung 1.2)

Damit ein MIME-Dokument mit RFC 2045 konform ist, muss sich dieses Feld im Header der höchsten Ebene befinden und den Wert 1.0 haben. MIME-Version darf nicht in einzelnen Nachrichtenteilen (parts) angegeben werden.

Content-Type

Content-Type (Inhaltstyp) muss nicht in einem Dokument stehen, damit es mit RFC 2045 konform ist, der MIME-Parser verlangt jedoch ein Content-Type-Headerfeld auf der höchsten Ebene. Content-Type hat standardmäßig den Wert 'text/plains'. Content-Type definiert den Datentyp in jedem Nachrichtenteil als Typ/Subtyp. Der MIME-Parser akzeptiert die meisten Werte für Content-Type und speichert sie einfach in der logischen Baumstruktur. Dazu gibt es nur folgende Ausnahmen:

  • Der MIME-Parser weist jeden Content-Type-Wert mit 'type = message' zurück.
  • Der MIME-Parser setzt voraus, dass ein Content-Type-Wert mit 'type = multipart' ein mehrteiliges MIME-Dokument einleitet und weist einen solchen Wert zurück, wenn es keinen gültigen Begrenzungsparameter enthält. Der Wert des Begrenzungsparameters legt das Trennzeichen zwischen Nachrichtenteilen in einer mehrteiligen Nachricht fest. In einer verschachtelten mehrteiligen Nachricht wird für jede Verschachtelungsebene ein eindeutiger Begrenzungswert benötigt.

Syntax:

Content-Type: Typ/Subtyp;Parameter

Typ und Subtyp definieren den Inhaltstyp, und alle optionalen Parameter werden durch Semikolon voneinander getrennt.

Beispiel 1:

Content-Type: multipart/related;type=text/xml

In Beispiel 1 wird der Inhaltstyp als 'multipart/related' definiert, und es ist eine optionale Parameterdefinition angegeben (type=text/xml). Dies ist zwar syntaktisch korrekt. Da aber kein gültiger Begrenzungsparameter angegeben ist, wird diese Nachricht zurückgewiesen.

Beispiel 2:

Content-Type: multipart/related;boundary=Begrenzung;type=text/xml 

Beispiel 2 zeigt eine gültige Content-Type-Definition sowohl hinsichtlich der Syntax als auch der Semantik. Der 'boundary'-Wert kann optional in Anführungszeichen gesetzt werden. Bei der Darstellung des Wertes im MIME-Hauptteil (body) wird ihm die Zeichenfolge '--' vorangestellt. Dabei ist darauf zu achten, dass der so gebildete Wert (in diesem Beispiel '--Begrenzung') in dieser Form nicht im Hauptteil der Nachricht vorkommen kann. Wenn die Nachrichtendaten als 'quoted-printable' codiert sind, wird empfohlen, einen Begrenzungswert zu verwenden, der eine Zeichenfolge wie z. B. "=_" beinhaltet, die in einem 'quoted-printable' Hauptteil nicht vorkommen kann.

Einige typische Content-Type-Werte sind unten aufgeführt. Alle anderen Werte sind zulässig und werden einfach in der logischen Baumstruktur gespeichert.

Content-Type Beschreibung
text/plain Wird allgemein für eine typische Mail oder Newsnachricht verwendet. 'text/richtext' ist ebenfalls üblich.
text/xml Wird allgemein in Verbindung mit SwA-Nachrichten (SOAP with Attachments) verwendet.
application/octet-stream Wird verwendet, wenn der Typ der Nachricht unbekannt ist, und enthält beliebige Daten als Bytes.
application/xml Wird für anwendungsspezifische XML-Daten verwendet.
x-type Wird für vom Standard abweichende Inhaltstypen verwendet. Muss mit x- beginnen.
image/jpeg Wird für Bilder verwendet. 'image/jpeg' und 'image/gif' sind allgemein gebräuchliche Bildformate.
multipart/related Wird für mehrere zusammengehörige Teile in einer Nachricht verwendet, insbesondere in Verbindung mit SwA-Nachrichten (SOAP with Attachments).
multipart/signed Wird für mehrere zusammengehörige Teile in einer Nachricht, einschließlich Signatur, verwendet (insbesondere in Verbindung mit S/MIME).
multipart/mixed Wird für mehrere unabhängige Teile in einer Nachricht verwendet.
Content-Transfer-Encoding

Optional. Viele Inhaltstypen werden als 8-Bit-Zeichen oder binäre Daten dargestellt. Dies kann XML einschließen, da dort typischerweise UTF-8- oder UTF-16-Codierung verwendet wird. Dieser Datentyp kann über einige Transportprotokolle nicht übertragen werden und muss gegebenenfalls in eine 7-Bit-Codierung umgesetzt werden.

Im Headerfeld 'Content-Transfer-Encoding' wird der Typ der Umsetzung angegeben, der für die Codierung dieses Datentyps in ein 7-Bit-Format verwendet wurde.

Das WS-I Basic Profile lässt nur die folgenden Werte zu:

  • 7bit - der Standardwert
  • 8bit
  • binary
  • base64
  • quoted-printable

Die Werte '7bit', '8bit' und 'binary' bedeuten alle nichts anderes, als dass keine Codierung stattgefunden hat. Ein MIME-konformer Mail-Gateway kann mit Hilfe dieser Werte gegebenenfalls seine Vorgehensweise bei der Verarbeitung der Nachricht steuern. Beispielsweise, indem er sie als '7bit' codiert, bevor er sie über SMTP weiterleitet.

Die Werte 'base64' und 'quoted-printable' bedeuten, dass der Inhalt codiert wurde. Der Wert 'quoted-printable' bedeutet, dass nur Zeichen im Original, die kein 7-Bit-Format haben, codiert werden, um so zu erreichen, dass das ausgegebene Dokument weiterhin lesbar ist. Diese Einstellung wird meistens in Verbindung mit dem Inhaltstyp 'text/plain' verwendet.

Content-ID

Optional. Mit diesem Headerfeld können Nachrichtenteile mit einer Inhalts-ID versehen und so von anderen Teilen der Nachricht referenziert werden. Diese Teile werden typischerweise vom ersten Teil der Nachricht (part 0) referenziert.

Content-Description

Optional. Dieses Headerfeld kann Beschreibungen zu Nachrichtenteilen enthalten.

MIME-Codierungen

Der folgende Abschnitt enthält grundlegende Informationen zu den Codierungen 'base64' und 'quoted-printable'. Eine definitive Spezifikation der MIME-Codierungen finden Sie in RFC 1521.

base64

Die Originaldaten werden in Gruppen zu 3 Oktetts aufgeteilt. Anschließend wird jede Gruppe wie vier verkettete 6-Bit-Gruppen behandelt, von denen jede in eine Einzelziffer des Base64-Alphabets umgesetzt wird. Das Base64-Alphabet besteht aus den Zeichen A-Z, a-z, 0-9 und / (mit A=0 und /=63).

Abbildung 1. Base64-DatenumsetzungAufteilung von 8-Bit-Daten in 6-Bit-codierte Daten.

Wenn am Ende der Daten weniger als 24 Bits verfügbar sind, werden die codierten Daten mit dem Zeichen '=' aufgefüllt. Die maximale Zeilenlänge für die codierten Daten beträgt 76 Zeichen. Zeilenumbrüche (und alle anderen Zeichen, die nicht Teil des oben genannten Alphabets sind) werden bei der Decodierung ignoriert.

Beispiele:

Eingabe Ausgabe
Some data encoded in base64. U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg==
life of brian bGlmZSBvZiBicmlhbg==\012
what d2hhdA==
quoted-printable

Diese Codierung ist nur geeignet, wenn der Großteil der Daten aus druckbaren Zeichen besteht. Vor allem Zeichen in den Bereichen 33-60 und 62-126 werden üblicherweise durch die entsprechenden ASCII-Zeichen dargestellt. Steuerzeichen und 8-Bit-Daten müssen durch das Gleichheitszeichen (=), dem ein Hexadezimalziffernpaar folgt, dargestellt werden.

Die Standard-ASCII-Zeichen für Leerzeichen (<SP>) und Horizontaltabulator (<HT>) behalten ihre Bedeutung, außer wenn sie am Ende einer codierten Zeile stehen (ohne einen weichen Zeilenumbruch). In diesem Fall muss das entsprechende hexadezimale Format verwendet werden (=09 bzw. =20).

Zeilenumbrüche in den Daten werden durch den RFC 822-konformen Zeilenumbruch <CR><LF> dargestellt und sollten als '=0D=0A' codiert werden, wenn binäre Daten codiert werden.

Wie für base64 gilt auch für die codierten Daten eine maximale Zeilenlänge von 76 Zeichen. Ein '=' am Ende einer codierten Zeile (ein 'weicher' Zeilenumbruch) zeigt dem Decoder an, dass die Zeile fortgesetzt wird.

Zugehörige Konzepte
Nachrichten modellieren
Das Nachrichtenmodell
Zugehörige Tasks
Nachrichtenmodelle entwickeln
Mit Nachrichtenmodellobjekten arbeiten
Zugehörige Verweise
Nachrichtenmodellverweisinformationen
Eigenschaften von Nachrichtenmodellobjekten
Zusätzliche Informationen zur MRM-Domäne
Zusätzliche Informationen zur MIME-Domäne
Zugehörige Informationen
RFC 1521: MIME Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
RFC 822: Standard for the format of ARPA Internet text messages
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ad30590_