Base64

In der Computerprogrammierung ist Base64 eine Gruppe von Binär-zu-Text-Kodierungsschemata, die Binärdaten (genauer gesagt, eine Folge von 8-Bit-Bytes) in Sequenzen von 24 Bits darstellen, die durch vier 6-Bit-Base64-Ziffern repräsentiert werden können. ⓘ

Allen Binär-zu-Text-Kodierungsverfahren gemeinsam ist, dass Base64 dazu dient, in Binärformaten gespeicherte Daten über Kanäle zu übertragen, die nur Textinhalte zuverlässig unterstützen. Base64 ist vor allem im World Wide Web weit verbreitet, wo es unter anderem dazu dient, Bilddateien oder andere Binärdaten in Textdateien wie HTML- und CSS-Dateien einzubetten. ⓘ

Base64 wird auch häufig für den Versand von E-Mail-Anhängen verwendet. Dies ist erforderlich, da SMTP - in seiner ursprünglichen Form - nur für die Übertragung von 7-Bit-ASCII-Zeichen konzipiert wurde. Diese Kodierung verursacht einen Overhead von 33-37% (33% durch die Kodierung selbst; bis zu 4% mehr durch die eingefügten Zeilenumbrüche). ⓘ

Base64 ist ein Verfahren zur Kodierung von 8-Bit-Binärdaten (z. B. ausführbare Programme, ZIP-Dateien oder Bilder) in eine Zeichenfolge, die nur aus lesbaren, Codepage-unabhängigen ASCII-Zeichen besteht. ⓘ

Entwurf

Die Auswahl der 64 Zeichen, die zur Darstellung der 64 Ziffern für die Basis gewählt werden, variiert zwischen den Implementierungen. Die allgemeine Strategie besteht darin, 64 Zeichen zu wählen, die in den meisten Kodierungen vorkommen und die auch druckbar sind. Diese Kombination macht es unwahrscheinlich, dass die Daten bei der Übertragung durch Informationssysteme wie E-Mail, die traditionell nicht 8-Bit-sauber sind, verändert werden. Die Base64-Implementierung von MIME verwendet zum Beispiel A-Z, a-z und 0-9 für die ersten 62 Werte. Andere Varianten teilen diese Eigenschaft, unterscheiden sich aber in der Wahl der Symbole für die letzten beiden Werte; ein Beispiel ist UTF-7. ⓘ

Die ersten Instanzen dieser Art von Kodierung wurden für die Einwahlkommunikation zwischen Systemen mit demselben Betriebssystem entwickelt, z. B. uuencode für UNIX und BinHex für den TRS-80 (später für den Macintosh angepasst), und konnten daher mehr Annahmen darüber treffen, welche Zeichen sicher zu verwenden waren. So verwendet uuencode Großbuchstaben, Ziffern und viele Interpunktionszeichen, aber keine Kleinbuchstaben. ⓘ

Base64-Zeichensatz

Wert			Zeichen	Wert			Zeichen	Wert			Zeichen	Wert			Zeichen ⓘ
dez.	binär	hex.	Zeichen	dez.	binär	hex.	Zeichen	dez.	binär	hex.	Zeichen	dez.	binär	hex.	Zeichen ⓘ
0	`000000`	00	`A`	16	`010000`	10	`Q`	32	`100000`	20	`g`	48	`110000`	30	`w`
1	`000001`	01	`B`	17	`010001`	11	`R`	33	`100001`	21	`h`	49	`110001`	31	`x`
2	`000010`	02	`C`	18	`010010`	12	`S`	34	`100010`	22	`i`	50	`110010`	32	`y`
3	`000011`	03	`D`	19	`010011`	13	`T`	35	`100011`	23	`j`	51	`110011`	33	`z`
4	`000100`	04	`E`	20	`010100`	14	`U`	36	`100100`	24	`k`	52	`110100`	34	`0`
5	`000101`	05	`F`	21	`010101`	15	`V`	37	`100101`	25	`l`	53	`110101`	35	`1`
6	`000110`	06	`G`	22	`010110`	16	`W`	38	`100110`	26	`m`	54	`110110`	36	`2`
7	`000111`	07	`H`	23	`010111`	17	`X`	39	`100111`	27	`n`	55	`110111`	37	`3`
8	`001000`	08	`I`	24	`011000`	18	`Y`	40	`101000`	28	`o`	56	`111000`	38	`4`
9	`001001`	09	`J`	25	`011001`	19	`Z`	41	`101001`	29	`p`	57	`111001`	39	`5`
10	`001010`	0A	`K`	26	`011010`	1A	`a`	42	`101010`	2A	`q`	58	`111010`	3A	`6`
11	`001011`	0B	`L`	27	`011011`	1B	`b`	43	`101011`	2B	`r`	59	`111011`	3B	`7`
12	`001100`	0C	`M`	28	`011100`	1C	`c`	44	`101100`	2C	`s`	60	`111100`	3C	`8`
13	`001101`	0D	`N`	29	`011101`	1D	`d`	45	`101101`	2D	`t`	61	`111101`	3D	`9`
14	`001110`	0E	`O`	30	`011110`	1E	`e`	46	`101110`	2E	`u`	62	`111110`	3E	`+`
15	`001111`	0F	`P`	31	`011111`	1F	`f`	47	`101111`	2F	`v`	63	`111111`	3F	`/`

Bei Dateinamen oder URL können die Zeichen +, / und = nicht verwendet werden, da sie dort für besondere Funktionen reserviert sind. In einem solchen Fall wird mit base64url eine inkompatible Abwandlung beschrieben. Die Zeichen + und / werden dann durch - (Minus, ASCII 2D_hex) und _ (Unterstrich, ASCII 5F_hex) ersetzt. Das Füllzeichen = am Ende wird prozentkodiert zu %3d, kann aber entfallen, wenn die Länge des Strings bekannt ist. ⓘ

Dies ist das Base64-Alphabet, das in RFC 4648 §4 definiert ist. Siehe auch Variantenübersicht (unten). ⓘ

Beispiele

Im folgenden Beispiel wird der Einfachheit halber ASCII-Text verwendet. Dies ist jedoch kein typischer Anwendungsfall, da er bereits sicher über alle Systeme übertragen werden kann, die Base64 verarbeiten können. Der typischere Anwendungsfall ist die Kodierung von Binärdaten (z. B. ein Bild); die resultierenden Base64-Daten enthalten nur 64 verschiedene ASCII-Zeichen, die alle zuverlässig über Systeme übertragen werden können, die die rohen Quellbytes beschädigen könnten. ⓘ

Es gibt eine bekannte Redewendung aus der verteilten Datenverarbeitung:

Viele Hände machen leichte Arbeit. ⓘ

Wenn das Zitat in Base64 kodiert ist, wird es als eine Bytefolge von 8-Bit-gefüllten ASCII-Zeichen dargestellt, die im Base64-Schema von MIME wie folgt kodiert sind (Zeilenumbrüche und Leerzeichen können überall vorkommen, sind aber bei der Dekodierung zu ignorieren):

TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu ⓘ

In dem obigen Zitat ist der kodierte Wert von Man TWFu. In ASCII kodiert, werden die Zeichen M, a und n als die Byte-Werte 77, 97 und 110 gespeichert, die die 8-Bit-Binärwerte 01001101, 01100001 und 01101110 darstellen. Diese drei Werte werden zu einer 24-Bit-Zeichenkette zusammengefügt, was 010011010110000101101110 ergibt. Gruppen von 6 Bits (6 Bits haben maximal 2⁶ = 64 verschiedene Binärwerte) werden von Anfang bis Ende in einzelne Zahlen umgewandelt (in diesem Fall gibt es vier Zahlen in einer 24-Bit-Zeichenkette), die dann in ihre entsprechenden Base64-Zeichenwerte umgewandelt werden. ⓘ

Wie dieses Beispiel zeigt, wandelt die Base64-Kodierung drei Oktette in vier kodierte Zeichen um. ⓘ

Quelle	Text (ASCII)	M								a								n ⓘ
Quelle	Oktette	77 (0x4d)								97 (0x61)								110 (0x6e)
Bits		0	1	0	0	1	1	0	1	0	1	1	0	0	0	0	1	0	1	1	0	1	1	1	0
Base64 kodiert	Sextette	19						22						5						46
	Zeichen	T						W						F						u
	Oktette	84 (0x54)						87 (0x57)						70 (0x46)						117 (0x75)

= Auffüllzeichen können hinzugefügt werden, damit der letzte kodierte Block vier Base64-Zeichen enthält. ⓘ

Die Umwandlung von Hexadezimal in Oktal ist nützlich, um zwischen Binär und Base64 zu konvertieren. Sowohl für fortgeschrittene Rechner als auch für Programmiersprachen ist eine solche Umwandlung verfügbar. Die hexadezimale Darstellung der obigen 24 Bits ist zum Beispiel 4D616E. Die oktale Darstellung ist 23260556. Diese 8 oktalen Ziffern können in Paare aufgeteilt werden (23 26 05 56), und jedes Paar wird in Dezimalzahlen umgewandelt und ergibt 19 22 05 46. Wenn man diese vier Dezimalzahlen als Indizes für das Base64-Alphabet verwendet, sind die entsprechenden ASCII-Zeichen TWFu. ⓘ

Wenn es nur zwei signifikante Eingabeoktette gibt (z. B. "Ma") oder wenn die letzte Eingabegruppe nur zwei Oktette enthält, werden alle 16 Bits in den ersten drei Base64-Ziffern (18 Bits) erfasst; die beiden niedrigstwertigen Bits des letzten inhaltshaltigen 6-Bit-Blocks erweisen sich als Null und werden bei der Dekodierung verworfen (zusammen mit dem nachfolgenden =-Auffüllzeichen):

Quelle	Text (ASCII)	M								a								ⓘ
Quelle	Oktette	77 (0x4d)								97 (0x61)								ⓘ
Bits		0	1	0	0	1	1	0	1	0	1	1	0	0	0	0	1	0	0
Base64 kodiert	Sextette	19						22						4						Auffüllen
	Zeichen	T						W						E						=
	Oktette	84 (0x54)						87 (0x57)						69 (0x45)						61 (0x3D)

Wenn es nur ein signifikantes Eingabeoktett gibt (z. B. "M") oder wenn die letzte Eingabegruppe nur ein Oktett enthält, werden alle 8 Bits in den ersten beiden Base64-Ziffern (12 Bits) erfasst; die vier niedrigstwertigen Bits des letzten inhaltshaltigen 6-Bit-Blocks werden zu Null und bei der Dekodierung verworfen (zusammen mit den beiden nachfolgenden = Füllzeichen):

Quelle	Text (ASCII)	M								ⓘ
Quelle	Oktette	77 (0x4d)								ⓘ
Bits		0	1	0	0	1	1	0	1	0	0	0	0
Base64 kodiert	Sextette	19						16						Auffüllen	Auffüllen
	Zeichen	T						Q						=	=
	Oktette	84 (0x54)						81 (0x51)						61 (0x3D)	61 (0x3D)

Auffüllen der Ausgabe

Da Base64 eine 6-Bit-Kodierung ist und die dekodierten Werte auf einem modernen Computer in 8-Bit-Oktetts aufgeteilt werden, entsprechen alle vier Zeichen des Base64-kodierten Textes (4 Sextetts = 4 × 6 = 24 Bits) drei Oktetts des nicht kodierten Textes oder der Daten (3 Oktetts = 3 × 8 = 24 Bits). Wenn also die Länge der nicht codierten Eingabe nicht ein Vielfaches von drei ist, muss die codierte Ausgabe aufgefüllt werden, damit ihre Länge ein Vielfaches von vier ist. Das Auffüllzeichen ist =, was bedeutet, dass keine weiteren Bits benötigt werden, um die Eingabe vollständig zu kodieren. (Dies unterscheidet sich von A, was bedeutet, dass die verbleibenden Bits alle Nullen sind.) Das folgende Beispiel veranschaulicht, wie das Kürzen der Eingabe des obigen Zitats die Auffüllung der Ausgabe verändert:

Eingabe		Ausgabe		Auffüllen ⓘ
Text	Länge	Text	Länge	Auffüllen ⓘ
leichte Arbeit.	11	bGlnaHQgd29yay4=	16	1
leichte Arbeit	10	bGlnaHQgd29yaw==	16	2
leichte Arbeit	9	bGlnaHQgd29y	12	0
leicht wo	8	bGlnaHQgd28=	12	1
helles w	7	bGlnaHQgdw==	12	2

Das Auffüllzeichen ist für die Dekodierung nicht unbedingt erforderlich, da die Anzahl der fehlenden Bytes aus der Länge des kodierten Textes abgeleitet werden kann. In einigen Implementierungen ist das Auffüllzeichen obligatorisch, während es in anderen nicht verwendet wird. Eine Ausnahme, in der Auffüllzeichen erforderlich sind, ist, wenn mehrere Base64-kodierte Dateien verkettet wurden. ⓘ

Dekodierung von Base64 mit Auffüllzeichen

Bei der Dekodierung von Base64-Text werden in der Regel vier Zeichen in drei Bytes zurückgewandelt. Die einzigen Ausnahmen sind, wenn Auffüllzeichen vorhanden sind. Ein einzelnes = bedeutet, dass die vier Zeichen in nur zwei Bytes dekodiert werden, während == bedeutet, dass die vier Zeichen in nur ein Byte dekodiert werden. Ein Beispiel:

Kodiert	Auffüllen	Länge	Dekodiert ⓘ
bGlnaHQgdw==	`==`	1	helles w
bGlnaHQgd28=	`=`	2	leicht wo
bGlnaHQgd29y	Keine	3	leichte Arbeit

Dekodierung von Base64 ohne Auffüllen

Ohne Auffüllen kann es vorkommen, dass nach der normalen Dekodierung von vier Zeichen in drei Bytes weniger als vier kodierte Zeichen übrig bleiben. In diesem Fall können nur zwei oder drei Zeichen übrig bleiben. Ein einzelnes verbleibendes kodiertes Zeichen ist nicht möglich, da ein einzelnes Base64-Zeichen nur 6 Bits enthält und 8 Bits erforderlich sind, um ein Byte zu erzeugen, so dass mindestens zwei Base64-Zeichen erforderlich sind: Das erste Zeichen steuert 6 Bits bei, und das zweite Zeichen steuert seine ersten 2 Bits bei. Zum Beispiel:

Länge	Kodiert	Länge	Dekodiert ⓘ
2	bGlnaHQgdw	1	helles w
3	bGlnaHQgd28	2	leicht wo
4	bGlnaHQgd29y	3	leichte Arbeit

Implementierungen und Geschichte

Übersichtstabelle der Varianten

In den Implementierungen kann es Einschränkungen hinsichtlich des Alphabets geben, das zur Darstellung einiger Bitmuster verwendet wird. Dies betrifft vor allem die letzten beiden Zeichen des Alphabets an den Positionen 62 und 63 sowie das Zeichen, das für das Auffüllen verwendet wird (das in einigen Protokollen zwingend vorgeschrieben sein kann, in anderen dagegen nicht). Die nachstehende Tabelle fasst diese bekannten Varianten zusammen und enthält Links zu den nachstehenden Unterabschnitten. ⓘ

Kodierung	Kodierungszeichen			Getrennte Kodierung von Zeilen			Dekodierung nicht kodierter Zeichen ⓘ
Kodierung	62.	63.	Auffüllen	Trennzeichen	Länge	Prüfsumme	Dekodierung nicht kodierter Zeichen ⓘ
RFC 1421: Base64 for Privacy-Enhanced Mail (veraltet)	`+`	`/`	`=[[Kategorie:Seiten, die eine Vorlage anstelle eines Zauberworts verwenden\|TBase64]]` obligatorisch	CR+LF	64, oder niedriger für die letzte Zeile	Nein	Nein
RFC 2045: Base64-Übertragungscodierung für MIME	`+`	`/`	`=[[Kategorie:Seiten, die eine Vorlage anstelle eines Zauberworts verwenden\|TBase64]]` obligatorisch	CR+LF	Höchstens 76	Nein	Verworfen
RFC 2152: Base64 für UTF-7	`+`	`/`	Nein	Nein			Nein
RFC 3501: Base64-Kodierung für IMAP-Postfachnamen	`+`	`,`	Nein	Nein			Nein
RFC 4648 §4: base64 (Standard)	`+`	`/`	`=[[Kategorie:Seiten, die eine Vorlage anstelle eines Zauberworts verwenden\|TBase64]]` optional	Nein			Nein
RFC 4648 §5: base64url (URL- und Dateinamen-sicherer Standard)	`-`	`_`	`=[[Kategorie:Seiten, die eine Vorlage anstelle eines Zauberworts verwenden\|TBase64]]` optional	Nein			Nein
RFC 4880: Radix-64 für OpenPGP	`+`	`/`	`=[[Kategorie:Seiten, die eine Vorlage anstelle eines Zauberworts verwenden\|TBase64]]` obligatorisch	CR+LF	Höchstens 76	Radix-64 kodierte 24-Bit CRC	Nein
Andere Varianten	siehe Anwendungen, die nicht mit RFC 4648 Base64 kompatibel sind (unten)

Mail mit erhöhtem Datenschutz

Die erste bekannte standardisierte Verwendung der heute als MIME Base64 bezeichneten Kodierung war im Privacy-enhanced Electronic Mail (PEM)-Protokoll, das 1987 mit RFC 989 vorgeschlagen wurde. PEM definiert ein "druckbares Kodierungsschema", das die Base64-Kodierung verwendet, um eine beliebige Folge von Oktetten in ein Format umzuwandeln, das in kurzen Zeilen von 6-Bit-Zeichen ausgedrückt werden kann, wie es von Übertragungsprotokollen wie SMTP verlangt wird. ⓘ

Die aktuelle Version von PEM (spezifiziert in RFC 1421) verwendet ein 64-Zeichen-Alphabet, das aus römischen Groß- und Kleinbuchstaben (A-Z, a-z), den Ziffern (0-9) und den Symbolen + und / besteht. Das Symbol = wird auch als Auffüllsuffix verwendet. In der ursprünglichen Spezifikation RFC 989 wurde zusätzlich das Symbol * verwendet, um verschlüsselte, aber unverschlüsselte Daten innerhalb des Ausgabestroms abzugrenzen. ⓘ

Um Daten in die druckbare PEM-Kodierung zu konvertieren, wird das erste Byte in den höchstwertigen acht Bits eines 24-Bit-Puffers abgelegt, das nächste in den mittleren acht und das dritte in den niedrigstwertigen acht Bits. Wenn weniger als drei Bytes zum Kodieren übrig sind (oder insgesamt), sind die verbleibenden Pufferbits Null. Der Puffer wird dann, sechs Bits auf einmal, das höchstwertige zuerst, als Indizes in der Zeichenkette verwendet: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", und das angegebene Zeichen wird ausgegeben. ⓘ

Der Vorgang wird mit den verbleibenden Daten so lange wiederholt, bis weniger als vier Oktette übrig sind. Wenn drei Oktette verbleiben, werden sie normal verarbeitet. Wenn weniger als drei Oktette (24 Bits) zum Kodieren übrig bleiben, werden die Eingabedaten mit Nullbits aufgefüllt, um ein ganzzahliges Vielfaches von sechs Bits zu bilden. ⓘ

Nach der Kodierung der nicht aufgefüllten Daten werden, wenn zwei Oktette des 24-Bit-Puffers mit Nullen aufgefüllt sind, zwei =-Zeichen an die Ausgabe angehängt; wenn ein Oktett des 24-Bit-Puffers mit Nullen aufgefüllt ist, wird ein =-Zeichen angehängt. Dies signalisiert dem Decoder, dass die durch das Auffüllen hinzugefügten Null-Bits aus den rekonstruierten Daten ausgeschlossen werden sollten. Dies garantiert auch, dass die kodierte Ausgabelänge ein Vielfaches von 4 Byte ist. ⓘ

PEM verlangt, dass alle kodierten Zeilen aus genau 64 druckbaren Zeichen bestehen, mit Ausnahme der letzten Zeile, die weniger druckbare Zeichen enthalten kann. Die Zeilen werden durch Leerzeichen entsprechend den lokalen (plattformspezifischen) Konventionen getrennt. ⓘ

MIME

Die MIME-Spezifikation (Multipurpose Internet Mail Extensions) führt Base64 als eines von zwei Binär-zu-Text-Kodierungsschemata auf (das andere ist quoted-printable). Die Base64-Kodierung von MIME basiert auf der RFC 1421-Version von PEM: Sie verwendet dasselbe 64-Zeichen-Alphabet und denselben Kodierungsmechanismus wie PEM und verwendet das =-Symbol für die Ausgabeauffüllung auf dieselbe Weise, wie in RFC 2045 beschrieben. ⓘ

MIME legt keine feste Länge für Base64-kodierte Zeilen fest, aber es gibt eine maximale Zeilenlänge von 76 Zeichen vor. Darüber hinaus wird festgelegt, dass alle extra-alphabetischen Zeichen von einem konformen Decoder ignoriert werden müssen, obwohl die meisten Implementierungen ein CR/LF-Zeilenpaar zur Abgrenzung kodierter Zeilen verwenden. ⓘ

Somit beträgt die tatsächliche Länge von MIME-konformen Base64-kodierten Binärdaten in der Regel etwa 137 % der ursprünglichen Datenlänge (4⁄3×78⁄76), obwohl der Overhead bei sehr kurzen Nachrichten aufgrund des Overheads der Kopfzeilen viel höher sein kann. Grob gesagt entspricht die endgültige Größe der Base64-kodierten Binärdaten dem 1,37-fachen der ursprünglichen Datengröße + 814 Byte (für Kopfzeilen). Die Größe der dekodierten Daten lässt sich mit dieser Formel annähernd bestimmen:

bytes = (string_length(encoded_string) - 814) / 1.37 ⓘ

UTF-7

Mit UTF-7, das zuerst in RFC 1642 beschrieben und später durch RFC 2152 ersetzt wurde, wurde ein System namens modifiziertes Base64 eingeführt. Dieses Datenkodierungsschema wird verwendet, um UTF-16 als ASCII-Zeichen für die Verwendung in 7-Bit-Transporten wie SMTP zu kodieren. Es ist eine Variante der Base64-Kodierung, die in MIME verwendet wird. ⓘ

Das "Modified Base64"-Alphabet besteht aus dem MIME-Base64-Alphabet, verwendet aber nicht das Auffüllzeichen "=". UTF-7 ist für die Verwendung in Mail-Headern vorgesehen (definiert in RFC 2047), und das "="-Zeichen ist in diesem Zusammenhang als Escape-Zeichen für "quoted-printable"-Kodierung reserviert. Modified Base64 lässt einfach das Padding weg und endet unmittelbar nach der letzten Base64-Stelle, die nützliche Bits enthält, wobei bis zu drei unbenutzte Bits in der letzten Base64-Stelle übrig bleiben. ⓘ

OpenPGP

Das OpenPGP-Datenformat definiert eine Variante von Base64, die ASCII Armor genannt wird. Diese besteht aus genormten Kopf- und Fußzeilen, welche zum einen den Anfang und das Ende der Daten anzeigen, zum anderen einen Hinweis für den menschlichen Leser geben, welche Art von Daten kodiert sind und mit welchem Programm die Daten erzeugt worden sind. ⓘ

An die Base64-kodierten Daten wird eine Prüfsumme (CRC-24) angehängt; dieses leicht modifizierte Verfahren trägt den Namen Radix-64. ⓘ

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux) <span title="Aus: Deutsche Wikipedia, Abschnitt "Radix-64"" class="plainlinks">[https://de.wikipedia.org/wiki/Base64#Radix-64 <span style="color:#dddddd">ⓘ</span>]</span>

jA0EAwMCxamDRMfOGV5gyZPnyX1BBPOQAE4BHbh7PfTDInn+94hXmnBr9D8+4x5R
kNNl4E499Me3Fotq8/zvznEycz2h7vJ21SdP5akLhRPd4W1S79LoCvbZYh2x4t6x
Cnqev6S97ys4chOPgz0FePfKQos0I7+rrMSAc9+vXHmUCthFqp7FJJ7/D9bCfmdF
1qkYNhtk/P5uvZ0N2zAUsiScDJA=
=XXuR
-----END PGP MESSAGE-----

Der Base64-Teil in diesem Beispiel beginnt mit jA0E… und endet mit …DJA=. Anschließend folgt ein Zeilenumbruch, ein Gleichheitszeichen und die base64-kodierte CRC-24-Prüfsumme über die Original-Nachricht (also vor der Base64-Kodierung). ⓘ

RFC 3548

J. Linn: RFC 1421. – Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. Februar 1993. (Löst RFC 1113 ab – historisch – englisch).
N. Borenstein, N. Freed: RFC 1521. – MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. September 1993. Standard: [draft]. (Löst RFC 1341 ab – Aktualisiert durch RFC 1590 – veraltet – englisch).
S. Josefsson: RFC 3548. – The Base16, Base32, and Base64 Data Encodings. [Errata: RFC 3548]. Juli 2003. (veraltet, abgelöst durch RFC 4648 – englisch).
S. Josefsson: RFC 4648. – The Base16, Base32, and Base64 Data Encodings. [Errata: RFC 4648]. Oktober 2006. Standard: [proposed]. (Löst RFC 3548 ab – englisch).
J. Callas, L. Donnerhacke, H. Finney, D. Shaw, R. Thayer: RFC 4880. – OpenPGP Message Format. [Errata: RFC 4880]. November 2007. Standard: [proposed]. (Aktualisiert durch RFC 5581 – Löst RFC 1991 und RFC 2440 ab – englisch). ⓘ

Sofern Implementierungen nicht nach einer Spezifikation geschrieben sind, die auf RFC 3548 verweist und ausdrücklich etwas anderes vorschreibt, verbietet RFC 3548 Implementierungen, Nachrichten zu erzeugen, die Zeichen außerhalb des Kodierungsalphabets oder ohne Auffüllung enthalten, und erklärt außerdem, dass Decoder-Implementierungen Daten zurückweisen müssen, die Zeichen außerhalb des Kodierungsalphabets enthalten. ⓘ

RFC 4648

Dieser RFC ersetzt RFC 3548 und konzentriert sich auf Base64/32/16:

Dieses Dokument beschreibt die häufig verwendeten Base64-, Base32- und Base16-Kodierungsverfahren. Außerdem werden die Verwendung von Zeilenvorschüben in kodierten Daten, die Verwendung von Auffüllungen in kodierten Daten, die Verwendung von Nicht-Alphabet-Zeichen in kodierten Daten, die Verwendung verschiedener Kodierungsalphabete und kanonische Kodierungen behandelt. ⓘ

URL-Anwendungen

Die Base64-Kodierung kann hilfreich sein, wenn in einer HTTP-Umgebung relativ lange Identifizierungsinformationen verwendet werden. So kann beispielsweise ein Datenbank-Persistenz-Framework für Java-Objekte die Base64-Kodierung verwenden, um eine relativ lange eindeutige Kennung (in der Regel 128-Bit-UUIDs) in eine Zeichenfolge zu kodieren, die als HTTP-Parameter in HTTP-Formularen oder HTTP-GET-URLs verwendet werden kann. Außerdem müssen viele Anwendungen Binärdaten so kodieren, dass sie sich gut in URLs einfügen lassen, auch in versteckte Webformularfelder, und Base64 ist eine geeignete Kodierung, um sie kompakt darzustellen. ⓘ

Die Verwendung von Base64 in URL erfordert die Kodierung der Zeichen "+", "/" und "=" in spezielle prozentual kodierte hexadezimale Sequenzen ("+" wird zu "%2B", "/" wird zu "%2F" und "=" wird zu "%3D"), wodurch die Zeichenfolge unnötig länger wird. ⓘ

Aus diesem Grund gibt es modifizierte Base64 für URL-Varianten (z. B. base64url in RFC 4648), bei denen die Zeichen "+" und "/" des Standard-Base64 durch "-" bzw. "_" ersetzt werden, so dass die Verwendung von URL-Encodern/Decodern nicht mehr erforderlich ist und keine Auswirkungen auf die Länge des codierten Wertes hat, so dass die gleiche codierte Form für die Verwendung in relationalen Datenbanken, Webformularen und Objektbezeichnern im Allgemeinen erhalten bleibt. Eine beliebte Website, die davon Gebrauch macht, ist YouTube. Einige Varianten erlauben oder erfordern das Weglassen der '='-Zeichen, um zu vermeiden, dass sie mit Feldtrennzeichen verwechselt werden, oder erfordern, dass solche Auffüllungen prozentual kodiert werden. Einige Bibliotheken kodieren '=' in '.', wodurch Anwendungen möglicherweise relativen Pfadangriffen ausgesetzt sind, wenn ein Ordnername aus Benutzerdaten kodiert wird. ⓘ

HTML

Die JavaScript-Methoden atob() und btoa(), die im HTML5-Spezifikationsentwurf definiert sind, bieten Base64-Kodierungs- und Dekodierungsfunktionen für Webseiten. Die btoa()-Methode gibt Füllzeichen aus, die in der Eingabe der atob()-Methode jedoch optional sind. ⓘ

Andere Anwendungen

Beispiel für ein SVG mit eingebetteten JPEG-Bildern, die in Base64 kodiert sind ⓘ

Base64 kann in einer Vielzahl von Kontexten verwendet werden:

Base64 kann zur Übertragung und Speicherung von Text verwendet werden, bei dem es sonst zu Kollisionen von Begrenzungszeichen kommen könnte
Base64 wird zur Kodierung von Zeichenketten in LDAP Data Interchange Format-Dateien verwendet
Base64 wird häufig verwendet, um binäre Daten in eine XML-Datei einzubetten, wobei eine Syntax ähnlich wie bei … z. B. Favicons in der von Firefox exportierten bookmarks.html.
Base64 wird verwendet, um Binärdateien wie Bilder innerhalb von Skripten zu kodieren, um die Abhängigkeit von externen Dateien zu vermeiden.
Das Daten-URI-Schema kann Base64 zur Darstellung von Dateiinhalten verwenden. So können beispielsweise Hintergrundbilder und Schriftarten in einer CSS-Stylesheet-Datei als Daten angegeben werden: URIs angegeben werden, anstatt in separaten Dateien geliefert zu werden.
Obwohl nicht Teil der offiziellen Spezifikation für SVG, können einige Viewer Base64 interpretieren, wenn sie für eingebettete Elemente wie Bilder innerhalb von SVG verwendet werden. ⓘ

Anwendungen, die nicht mit RFC 4648 Base64 kompatibel sind

Einige Anwendungen verwenden ein Base64-Alphabet, das sich deutlich von den Alphabeten unterscheidet, die in den gängigsten Base64-Varianten verwendet werden (siehe Übersichtstabelle der Varianten oben). ⓘ

Ein Problem mit dem RFC 4648-Alphabet besteht darin, dass sich die Reihenfolge der Elemente ändert, wenn eine sortierte Liste von ASCII-kodierten Zeichenfolgen in Base64 umgewandelt und erneut sortiert wird. Dies liegt daran, dass das Auffüllzeichen und die Zeichen im Substitutionsalphabet nicht nach dem ASCII-Zeichenwert geordnet sind (was durch Verwendung der Sortierschaltflächen in der folgenden Beispieltabelle deutlich wird). Alphabete wie (ungefüllt) B64 schaffen hier Abhilfe. ⓘ

ASCII	Base64	Base64, ohne Auffüllen	B64 ⓘ
helles w	`bGlnaHQgdw==`	`bGlnaHQgdw`	`P4ZbO5EURk`
leicht wo	`bGlnaHQgd28=`	`bGlnaHQgd28`	`P4ZbO5EURqw`
leichte Arbeit	`bGlnaHQgd29y`	`bGlnaHQgd29y`	`P4ZbO5EURqxm`

Das Uuencoding-Alphabet enthält keine Kleinbuchstaben, sondern verwendet nacheinander die ASCII-Codes 32 (" " (Leerzeichen)) bis 95 ("_"). Uuencoding verwendet das Alphabet " !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_". Der Verzicht auf Kleinbuchstaben war hilfreich, da viele ältere Drucker nur Großbuchstaben druckten. Die Verwendung aufeinanderfolgender ASCII-Zeichen sparte Rechenleistung, da nur 32 Zeichen addiert werden mussten, ohne dass eine Nachschlagetabelle erforderlich war. Die Verwendung der meisten Interpunktionszeichen und des Leerzeichens kann seine Nützlichkeit in einigen Anwendungen einschränken, z. B. in solchen, die diese Zeichen als Syntax verwenden.
BinHex 4 (HQX), das im klassischen Mac OS verwendet wurde, schließt einige visuell verwirrende Zeichen wie '7', 'O', 'g' und 'o' aus. Das Alphabet enthält zusätzliche Interpunktionszeichen. Es verwendet das Alphabet "!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr".
Mehrere andere Anwendungen verwenden ähnliche Alphabete wie die gängigen Varianten, jedoch in einer anderen Reihenfolge:
- Unix speichert mit crypt berechnete Passwort-Hashes in der Datei /etc/passwd unter Verwendung einer B64 genannten Kodierung. Das Alphabet von crypt setzt die Interpunktion . und / vor die alphanumerischen Zeichen. crypt verwendet das Alphabet "./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz". Padding wird nicht verwendet.
- Der Standard GEDCOM 5.5 für den Austausch genealogischer Daten kodiert Multimediadateien in seinem hierarchischen Textzeilen-Dateiformat. GEDCOM verwendet das gleiche Alphabet wie crypt, nämlich "./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".
- bcrypt-Hashes sind so konzipiert, dass sie auf dieselbe Weise wie herkömmliche crypt(3)-Hashes verwendet werden können, aber das Alphabet von bcrypt hat eine andere Reihenfolge als das von crypt. bcrypt verwendet das Alphabet "./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789".
- Xxencoding verwendet einen größtenteils alphanumerischen Zeichensatz ähnlich wie crypt, aber mit + und - anstelle von . und /. Xxencoding verwendet das Alphabet "+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".
- 6PACK, das mit einigen Terminal Node Controllern verwendet wird, verwendet ein Alphabet von 0x00 bis 0x3f.
- Bash unterstützt numerische Literale in Base64. Bash verwendet das Alphabet "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_". ⓘ

Beispiel

Polyfon zwitschernd aßen Mäxchens Vögel Rüben, Joghurt und Quark ⓘ

Dieser 64 Zeichen lange Text wäre in UTF-8-Kodierung 68 Byte lang, da in UTF-8 das Eszett und die Umlaute jeweils eine Länge von zwei Bytes haben. Mit der Umwandlung zu Base64 wird daraus eine 92 Zeichen lange Base64-Zeichenkette:

UG9seWZvbiB6d2l0c2NoZXJuZCBhw59lbiBNw6R4Y2hlbnMgVsO2Z2VsIFLDvGJl
biwgSm9naHVydCB1bmQgUXVhcms= ⓘ

Erkennbar ist hierbei, dass Base64 eine für Menschen nicht lesbare Kodierung erstellt. Dieser Umstand ist jedoch nicht als wirksame Verschlüsselung anzusehen, da der Datenstrom der Eingabe sehr leicht aus der Zeichenfolge am Ausgang zurückgewonnen werden kann, sobald diese als Base64-kodiert erkannt ist. ⓘ

Umwandlung der Zeichen "Pol" in Base64 ⓘ
Phase	Daten	Anmerkungen
Ursprungstext	`Pol`
Unicode-Zeichen	`U+0050 U+006F U+006C`	gemäß Unicodeblock Basis-Lateinisch
Bytes	`0x50 0x6F 0x6C`	gemäß UTF-8
Binärschreibweise	`0101 0000 0110 1111 0110 1100`	siehe Hexadezimalsystem
Gruppierung in 6er-Blöcken	`010100 000110 111101 101100`	jeder 6er-Block entspricht einem Base64-Zeichen
Codierung als Base64-Zeichen	`U G 9 s`	gemäß der Tabelle oben von „binär“ nach „Zeichen“
Ohne Leerzeichen	`UG9s`

Siehe auch

Quoted-Printable-Kodierung
UUencode
Base32
Base85 ⓘ