1. Wozu Mimechan ?

Bemerkung: Als genaue Referenz rate ich RFC1521 zu lesen, in der Base64 und qouted-printable Konventierung und Probleme mit SMTP beschrieben sind.

1.1 Geschichtliches

Als man den SMTP (Simple Mail Transfer Protocol RFC 822) entworfen hat, war Mail System für kurze unformatierte (reines ASCII) englische Texte gedacht. Die Zeichen wurden nur mit 7Bit Breite durch Netze geschickt. Verschiedene Programme auf den Netzzwischenstationnen veränderten den Inhalt der Nachrichten, die nicht dieser allgemeiner Beschreibung entsprachen, indem sie

• zu Lange Zeilen einfach abschnitten
• alle Zeichen außer ASCII ignorierten
• Zeilen bis zu bestimmten Länge mit Leerzeichen füllten
• die Leerzeichen und Tabulator Zeichen vor Zeilenumbruch Zeichen abschnitten,
• zwischen EBCDIC und ASCII Zeichensatz umwandelten, was Veränderung von Sonderzeichen zu Folge haben könnte
• Zeilenumbruch entweder als CR (Carrige Return) und LF (Line Feed) oder nur als LF interpretierten

1.2 Kodierungen allgemein

Es hat sich herausgestellt, daß die Spezifikation vom SMTP völlig unzureichend war um binäre Dateien oder nicht englischsprachige Nachrichten, die bekanntermaßen einen größeren Zeichenvorrat wie ASCII brauchten, einheitlich zu behandeln. Aus dieser Tatsache ist MIME (Multipurpose Internet Mail Extensions, definiert im RFC 1521) entstanden. Dabei hat man den SMTP als Basis für Erweiterungen genommen. Auf diese Weise können die neue MIME Nachrichten weiter als SMTP Nachrichten behandeln werden. Weil STMP von sich aus keine Übermittlung von binären Dateien zuläßt, sind in MIME Kodierungs- und Dekodierungsalgorithen definiert, die eine binäre Datei in eine pseudo Textdatei umwandeln, die SMTP konform ist, und die man schließlich wieder zu einer binären Datei dekodieren kann.

Bei Realisierung der Kodierungsverfahren waren folgende Tatsachen, die aus Beschaffenheit der STMP resultieren, zu beachten.

• Zeilenlänge ist begrenzt (1000 Zeichen maximal). Weitere Zeichen der Zeile werden ignoriert.
• Zeichenvorrat ist auf 7 Bits ASCII eingeschränkt.
• Leerzeichen und Tabulator Zeichen vor Zeilenumbruch werden allgemein ignoriert.
• Zeilenumbruch kann systemabhängig als CRLF oder LF gedeutet werden.

base64

Beschrieben im RFC 1521

Diese Kodierung ist besonders geeignet für reine binäre Dateien wie gif-Dateien. Jeweils 3 Bytes werden zu 4 ASCII Zeichen umgewandelt. Eine Gruppe von 3 Bytes, zusammen 24 Bits, wird auf 4 Gruppen jeweils 6 Bits aufgeteilt. Die resultierenden 4 Zahlen (je 6 Bits) werden folgendermaßen zu ASCII umgewandelt.

• Zahlen von 0 bis 25 zu ASCII 'A' bis 'Z'
• Zahlen von 26 bis 61 zu ASCII 'a' bis 'z'
• 62 zu '+' und 63 zu '/'

Zeilenlänge beträgt maximal 76 Zeichen (ohne anschließenden Zeilenumbruch). Kodierte Dateien sind beim langen Dateien im Schnitt 36.8 Prozent länger als unkodierte.

Erklärung zu Längenberechnug Voraussetzungen:

• x - Länge der zu kodierenden Datei
• Zeilenlänge 76
• Zeilenumbruch durch CRLF (nach RFC 1521)

Nach dieser Berechnung werden

• 10 Bytes zu 18 Bytes kodiert; 80 Prozent Längen zuwachst
• 30 Bytes zu 42 ; 40 Prozent
• 100 Bytes zu 140 ; 40 Prozent
• 1000 Bytes zu 1372 ; 37,2 Prozent
• 5000 Bytes zu 6844 ; 36,88 Prozent

qouted-printable

Beschrieben im RFC 1521

Gedacht für lesbare Texte die nur ausnahmsweise andere als ASCII Zeichen enthalten. Kodiertes Text ist teilweise lesbar, seine Länge hängt von Inputdatei (von 100 bis 300 Prozent der Läge der Quelle). Für binäre Dateien nicht geeignet

uucode

Älteres Verfahren aus dem Unix Systemen. Fast gleich wie base64. Nachteilig für dieses Kodierungsverfahren ist, daß es mit EBCDIC Zeichensatz nicht kompatibel ist. Sollte durch base64 ersetzt werden. Als Beschreibung des Formats und Kodierung dient man pages uuencode Section 5