Base32 beschreibt ein Verfahren zur Kodierung von Binärdaten in eine Zeichenfolge, die nur aus 32 verschiedenen ASCII-Zeichen besteht (plus einem zusätzlichen 33. Zeichen als Füllzeichen am Datenende). Im Vergleich zum verwandten Verfahren Base64 eignet es sich für Datenformate, bei denen nicht zwischen Groß- und Kleinbuchstaben unterschieden wird. Eine Gruppe weiter ähnlicher Kodierungsverfahren ist unter Base85 bekannt.
RFC 3548[1] beschreibt die Kodierung beliebiger Binärdaten wie folgt: Fünf Bytes à 8-Bit (also zusammen 40 Bit) werden in acht 5-Bit-Gruppen zerlegt. Jede dieser Gruppen entspricht einer Zahl zwischen 0 und 31. Diese Zahlen werden anhand der nachfolgenden Umsetzungstabelle in „druckbare ASCII-Zeichen“ umgewandelt und ausgegeben. Wenn am Ende kein kompletter 40-Bit-Block mehr gebildet werden kann, wird dieser Block mit Nullbytes (000000002) aufgefüllt und jene 5-Bit-Gruppen, die nur aus Füllbits bestehen, mit dem Füllzeichen =
kodiert, um dem Dekodierer mitzuteilen, wie viele Füllbits hinzugefügt wurden.
Während Base64 in der Maschine-zu-Maschine-Kommunikation eingesetzt wird, werden Base32-ähnliche Kodierungen oft in Bereichen verwendet, wo sie von Menschen gelesen und eingegeben werden. Es sind verschiedene Kodierungen in Verwendung, die zum Ziel haben, Verwechslungsgefahren zwischen ähnlich aussehenden Zeichen zu minimieren und dafür gezielt einzelne Zeichen, die für missverständlich gehalten werden, von der Verwendung ausschließen. Daher wird in der Regel eine tabellarische Übersetzung der Base32-Zahlen auf kodierte Zeichen vorgenommen.
Wert | Zeichen | Wert | Zeichen | Wert | Zeichen | Wert | Zeichen | |||
---|---|---|---|---|---|---|---|---|---|---|
0 | A | 8 | I | 16 | Q | 24 | Y | |||
1 | B | 9 | J | 17 | R | 25 | Z | |||
2 | C | 10 | K | 18 | S | 26 | 2 | |||
3 | D | 11 | L | 19 | T | 27 | 3 | |||
4 | E | 12 | M | 20 | U | 28 | 4 | |||
5 | F | 13 | N | 21 | V | 29 | 5 | |||
6 | G | 14 | O | 22 | W | 30 | 6 | |||
7 | H | 15 | P | 23 | X | 31 | 7 |
Die Ziffern 0 und 1 werden nicht verwendet, da bei schriftlicher Wiedergabe eine Verwechslungsgefahr mit den Buchstaben O und I besteht.
Wert | Zeichen | Wert | Zeichen | Wert | Zeichen | Wert | Zeichen | |||
---|---|---|---|---|---|---|---|---|---|---|
0 | 0 | 8 | 8 | 16 | G | 24 | O | |||
1 | 1 | 9 | 9 | 17 | H | 25 | P | |||
2 | 2 | 10 | A | 18 | I | 26 | Q | |||
3 | 3 | 11 | B | 19 | J | 27 | R | |||
4 | 4 | 12 | C | 20 | K | 28 | S | |||
5 | 5 | 13 | D | 21 | L | 29 | T | |||
6 | 6 | 14 | E | 22 | M | 30 | U | |||
7 | 7 | 15 | F | 23 | N | 31 | V |
RFC 3548[1] wurde von RFC 4648[2] abgelöst, das eine weitere Kodierung einführt. Diese benutzt – ähnlich wie das Hexadezimalsystem – für die Werte 0 bis 9 die dezimalen Ziffern. Die Werte 10 bis 31 werden durch die Buchstaben A bis V repräsentiert. Damit bleibt, wie bei Hexadezimalzahlen, die Reihenfolge der kodierten Werte bei lexikographischer Sortierung erhalten, allerdings wird darauf verzichtet, optisch ähnliche Zeichen zu vermeiden. Damit ist das Einsatzgebiet dieser Kodierung eher die Maschine-zu-Maschine-Kommunikation in Bereichen, wo nicht zwischen Klein- und Großbuchstaben unterschieden werden kann.
So wird diese Kodierung beispielsweise beim NSEC3 Resource Record von DNSSEC verwendet.
Wert | Zeichen | Wert | Zeichen | Wert | Zeichen | Wert | Zeichen | |||
---|---|---|---|---|---|---|---|---|---|---|
0 | q | 8 | g | 16 | s | 24 | c | |||
1 | p | 9 | f | 17 | 3 | 25 | e | |||
2 | z | 10 | 2 | 18 | j | 26 | 6 | |||
3 | r | 11 | t | 19 | n | 27 | m | |||
4 | y | 12 | v | 20 | 5 | 28 | u | |||
5 | 9 | 13 | d | 21 | 4 | 29 | a | |||
6 | x | 14 | w | 22 | k | 30 | 7 | |||
7 | 8 | 15 | 0 | 23 | h | 31 | l |
Bitcoin-Adressen werden üblicherweise in einer „base58check“ genannten Kodierung angegeben, welche zwar eine relativ kompakte textuelle Darstellung erlaubt, aber in der Praxis einige Nachteile aufweist:
Das im Bitcoin Improvement Proposal 0173 (BIP0173) vorgeschlagene Format namens „Bech32“ versucht, diese Nachteile zu umgehen:[3]
Bech32 benutzt eine spezielle Kodierungstabelle, die so designt wurde, dass die kodierte 5-Bit-Folge von visuell ähnlichen (und daher am ehesten zu verwechselnde) Zeichen sich stets um mehr als nur 1 Bit unterscheidet, so dass die der Prüfsummenalgorithmus davon profitiert. Dabei werden die Buchstaben b, i und o sowie die Ziffer 1 bei der Bech32-Kodierung nicht verwendet. Das Präfix bc1, mit dem jede Bech32-Bitcoin-Adresse beginnt, ist nicht Teil dieser Kodierung, sondern lediglich die Kennung.
In Videospielen werden Passwörter und Level-Codes oft in einer modifizierten Base32-Kodierung dargestellt. Die verwendeten Kodierungsalphabete sind dabei nicht genormt. Oft werden Ziffern und Konsonanten verwendet, um möglichst keine „sprechenden“ Passwörter zu erzeugen.
ZRTP benutzt eine eigene Kodierungstabelle namens z-base-32, die ebenfalls darauf optimiert wurde, bei mündlicher Wiedergabe (etwa via Telefon) Missverständnisse zu vermeiden.[4]
Schritt | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 | Block 6 | Block 7 | Block 8 |
---|---|---|---|---|---|---|---|---|
Integer-Wert | 0 | – | – | – | – | – | – | – |
Repräsentiert als 8 Bits | 00000000 | – | – | – | – | – | – | – |
Aufgeteilt in 8×5 Blöcke | 00000 | 000… | – | – | – | – | – | – |
Fehlende Nullen aufgefüllt | 00000 | 00000 | – | – | – | – | – | – |
Integer-Wert | 0 | 0 | – | – | – | – | – | – |
Base32-Kodierung | A | A | = | = | = | = | = | = |
Schritt | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 | Block 6 | Block 7 | Block 8 |
---|---|---|---|---|---|---|---|---|
Integer-Werte | 65 | 66 | – | – | – | – | – | – |
Repräsentiert als 8 Bits | 01000001 | 01000010 | – | – | – | – | – | – |
Aufgeteilt in 8×5 Blöcke | 01000 | 00101 | 00001 | 0.... | – | – | – | – |
Fehlende Nullen aufgefüllt | 01000 | 00101 | 00001 | 00000 | – | – | – | – |
Integer-Werte | 8 | 5 | 1 | 0 | – | – | – | – |
Base32-Kodierung | I | F | B | A | = | = | = | = |