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).
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 (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:
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. |
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:
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.
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.
Optional. Dieses Headerfeld kann Beschreibungen zu Nachrichtenteilen enthalten.
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.
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==\012 |
what | d2hhdA== |
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.