Base64-Alphabet-Tabelle

Die 64 Zeichen

Base64 liest die Eingabe in Gruppen zu 3 Bytes (24 Bit) und teilt jede Gruppe in vier 6-Bit-Zahlen. Jede Zahl von 0 bis 63 ist ein Index in diese Tabelle. Die Reihenfolge legt RFC 4648 fest: Großbuchstaben für 0 bis 25, Kleinbuchstaben für 26 bis 51, Ziffern für 52 bis 61, dann + und /. Die letzte Spalte ist der ASCII-Code des Zeichens, also das, was tatsächlich gespeichert oder übertragen wird.

Zwei Bereiche lohnt es sich zu merken. Jedes Zeichen von A bis P (0 bis 15) beginnt mit den Bits 00, und jedes Zeichen von w bis / (48 bis 63) beginnt mit 11. Das reicht, um ein Zeichen im Kopf zu dekodieren, wenn Sie ein Präfix von Hand prüfen. Ein durchgerechnetes Beispiel für die Bit-Aufteilung steht in So funktioniert Base64.

Die Reihenfolge des Alphabets ist nicht die ASCII-Reihenfolge. In ASCII kommen + und / zuerst, dann Ziffern, dann Groß-, dann Kleinbuchstaben. Sortiert man Base64-Zeichenketten, sortiert man deshalb nicht die zugrunde liegenden Bytes: +A== (das Byte F8) steht vor AA== (dem Byte 00). Wenn kodierte Werte wie die Rohbytes sortiert werden sollen, nehmen Sie base32hex aus RFC 4648 oder einfach Hex.

Das URL-sichere Alphabet

+ und / haben in URLs beide eine besondere Bedeutung. + wird in Query-Strings und Formulardaten zu einem Leerzeichen dekodiert, und / trennt Pfadsegmente. Base64URL, definiert in Abschnitt 5 von RFC 4648, behält die Indizes 0 bis 61 und tauscht die letzten beiden aus:

Alles andere, einschließlich der Bit-Anordnung, ist identisch. Die Umwandlung zwischen beiden besteht also aus einer Zeichenersetzung und dem Ergänzen oder Entfernen des Paddings. JWTs, viele API-Tokens und dateinamensichere Kennungen verwenden Base64URL, meist ohne =. Der Base64URL-Encoder erzeugt es direkt. Den vollständigen Vergleich finden Sie unter Base64 vs. Base64URL.

Das Padding-Zeichen

= (ASCII 0x3D) gehört nicht zum 64-Zeichen-Alphabet und kodiert nie Daten. Es füllt nur die letzte 4-Zeichen-Gruppe auf, wenn die Eingabelänge kein Vielfaches von 3 ist:

• 1 Byte übrig: 2 Datenzeichen plus ==.
• 2 Bytes übrig: 3 Datenzeichen plus =.
• Kein Byte übrig: kein Padding.

Eine Zeichenkette mit Padding hat also immer eine durch 4 teilbare Länge, und === kommt nie vor. Ohne Padding lässt die Länge bei Division durch 4 den Rest 0, 2 oder 3, nie 1. Die Anleitung zum Padding erklärt, wann = wegfallen darf und wie Sie es wiederherstellen.

Welche Zeichen wo auftauchen

Einige Muster ergeben sich direkt aus der Bit-Anordnung. Sie wurden per Brute Force über alle relevanten Bytewerte geprüft.

Vor == stehen nur A, Q, g oder w. Bleibt ein Byte übrig, trägt das zweite Zeichen 2 Datenbits, gefolgt von 4 Nullbits, sein Index ist also 0, 16, 32 oder 48. Vor einem einzelnen = hat das dritte Zeichen am Ende 2 Nullbits und ist damit eines von 16 Zeichen: A E I M Q U Y c g k o s w 0 4 8. Alles andere an dieser Stelle bedeutet eine nicht kanonische Kodierung, die strenge Decoder ablehnen.

Zufällige Bytes nutzen alle 64 Zeichen gleich häufig. Jede 6-Bit-Gruppe aus Zufallsdaten ist gleichverteilt, daher erzeugen verschlüsselte Daten, Schlüssel und komprimierte Dateien eine flache Zeichenverteilung. Eine schiefe Verteilung deutet darauf hin, dass die Daten Text sind oder eine Struktur haben.

ASCII-Text beginnt eine Gruppe nie mit kleinem g bis z, Ziffern, + oder /. Das erste Zeichen jeder 4-Zeichen-Gruppe enthält die oberen 6 Bits eines Bytes. Bei 7-Bit-ASCII ist das oberste Bit 0, also liegt dieses Zeichen immer zwischen A und f (Index 0 bis 31). In SGVsbG8gd29ybGQh (Hello world!) beginnen die Gruppen mit S, b, d und b.

In Base64 von ASCII-Text sind + und / selten. Bei Bytes unter 0x80 kann + nur als viertes Zeichen einer Gruppe vorkommen, wenn das dritte Byte > oder ~ ist. / kann dort nur stehen, wenn dieses Byte ? oder das Steuerzeichen DEL ist. Deshalb wird Hi?> zu SGk/Pg== und <b> zu PGI+.

Folgen von A sind Nullbytes, Folgen von / sind 0xFF. AAAA sind drei 00-Bytes, //// sind drei FF-Bytes. Lange Strecken aus A sind typisch für dünn besetzte Binärformate, UTF-16-Text (Hello ist SABlAGwAbABvAA==) und die Längenfelder am Anfang von SSH-Schlüsseln. Weitere erkennbare Muster stehen unter Häufige Base64-Präfixe.

Andere Base64-Alphabete

Mehrere Systeme haben die Idee von 64 Zeichen für je 6 Bit übernommen, aber andere Zeichen gewählt:

• IMAP ersetzt / durch ,, weil / in Postfachnamen oft als Hierarchietrenner dient. Ein Ordner namens Entwürfe wird als Entw&APw-rfe gespeichert.
• bcrypt stellt . und / an den Anfang und setzt Buchstaben vor Ziffern. Salts und Hashes sind Base64 in diesem Alphabet ohne Padding, weshalb ein Standard-Decoder dafür die falschen Bytes liefert.
• crypt(3) verwendet ./0-9A-Za-z, also die ASCII-Reihenfolge. Außerdem packt es die Bits vom niederwertigsten Ende her, sodass ein Standard-Decoder selbst mit übersetztem Alphabet die Hash-Bytes nicht reproduziert.
• uuencode und xxencode sind älter als MIME. Die Tools uuencode und xxencode lesen und schreiben beide.

Kodierungen mit anderer Alphabetgröße wie Base32, Base58 und Base85 behandelt Base64 vs. Hex, Base32, Base58 und Base85. Definitionen der hier verwendeten Begriffe stehen im Glossar.

Häufige Fragen