Standardfelder des MIME-Headers

Die vorliegenden Informationen enthalten 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/plain. 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 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 dabei 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). Diese Struktur ist zwar syntaktisch korrekt, da jedoch ein gültiger Begrenzungsparameter fehlt, wird diese Nachricht abgewiesen.

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 Werts 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, müssen Sie einen Begrenzungswert verwenden, der eine Zeichenfolge wie z. B. "=_" beinhaltet, die in einem 'quoted-printable' Hauptteil nicht vorkommen kann.

In der folgenden Tabelle werden einige häufig verwendete Content-Type-Werte aufgeführt. Alle anderen Werte sind zulässig und werden 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 mit SwA (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 und können 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 Transformation 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 mithilfe 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 Feld 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 Feld kann Beschreibungen zu Nachrichtenteilen enthalten.

MIME-Codierungen

Im folgenden Abschnitt finden Sie einen Basisleitfaden für die 'base64'- und 'quoted-printable'-Codierung; unter RFC 1521 (Link am Ende dieses Abschnitts) finden Sie eine definitive Spezifikation der MIME-Codierungen.

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).

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==
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.

Bei base64 gilt 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.