Base32 Encoder & Decoder

Base32 wandelt beliebigen UTF-8-Text in eine kompakte Zeichenkette um, die nur aus den Buchstaben A bis Z und den Ziffern zwei bis sieben besteht, optional mit Gleichheitszeichen aufgefüllt, damit jeder Block auf einer Acht-Zeichen-Grenze endet. Anders als Base64 verzichtet das Alphabet auf Plus, Schrägstrich und andere Satzzeichen, die URLs, Shell-Argumente oder Dateisysteme ohne Groß-/Kleinschreibung stören – genau deshalb werden geheime Seeds, TOTP-Schlüssel und viele Protokoll-Tokens weiterhin als Base32 ausgeliefert. Diese Fähigkeit implementiert das Alphabet aus RFC 4648 Abschnitt sechs vollständig: Der Kodier-Modus liest Ihren Klartext als UTF-8-Bytes und gibt ein aufgefülltes Base32-Ergebnis aus; der Dekodier-Modus akzeptiert Base32 in beliebiger Groß-/Kleinschreibung, entfernt Leerraum, prüft jedes Zeichen und liefert den ursprünglichen UTF-8-Text zurück.

Wie RFC 4648 Base32 Bits in A-Z und 2-7 packt

RFC 4648 Abschnitt sechs definiert ein Alphabet aus zweiunddreißig Symbolen: die sechsundzwanzig lateinischen Großbuchstaben gefolgt von den sechs Ziffern zwei bis sieben. Die Kodierung beginnt bei den Rohbytes. Bei Text wandelt diese Fähigkeit Ihre Zeichenkette zunächst mit UTF-8 um, damit Mehrbyte-Zeichen sprach- und plattformübergreifend portabel bleiben.

Diese Bytes werden dann als fortlaufender Bitstrom gelesen. Jeweils fünf Bits wählen einen Alphabet-Index und ergeben ein Base32-Zeichen. Fünf Eingabebytes liefern vierzig Bits, die sich sauber in acht Base32-Zeichen aufteilen; kürzere Reste hinterlassen ein unvollständiges letztes Quintett, das rechts mit Nullbits aufgefüllt und anschließend mit Gleichheitszeichen ergänzt wird, sodass die Gesamtlänge stets ein Vielfaches von acht ist.

Das Dekodieren kehrt die Abbildung um: Jedes Nicht-Füllzeichen trägt fünf Bits bei, volle Bytes werden ausgegeben, sobald acht Bits gesammelt sind, und abschließende Füllzeichen werden auf zulässige Platzierung geprüft. Leerraum wird ignoriert, damit mehrzeilige Tokens aus E-Mails weiterhin funktionieren. Kleinbuchstaben werden vor der Suche in Großbuchstaben gewandelt.

Der auf dieser Seite implementierte Standard ist das klassische RFC-4648-Base32-Alphabet, nicht Base32hex und nicht Crockford Base32, die andere Symboltabellen verwenden und die Interoperabilität mit TOTP und vielen älteren APIs zerstören würden.

Was Sie senden und was Sie zurückerhalten

Senden Sie ein erforderliches String-Feld namens text und ein optionales Feld mode mit dem Wert encode oder decode. Fehlt mode, ist encode die Vorgabe, sodass schon eine einzelne Nutzlast sinnvolle Arbeit leistet. Der Modus encode behandelt text als reinen UTF-8-Inhalt und liefert einen Ergebnis-String im RFC-4648-Alphabet mit Padding.

Der Modus decode behandelt text als Base32, normalisiert Groß-/Kleinschreibung und Leerraum, validiert das Alphabet und gibt die wiederhergestellte UTF-8-Zeichenkette in result zurück. Beide Richtungen spiegeln mode, den ursprünglichen text, result, ein Längenfeld für den primären Ausgabe-String, Alphabet- und Zeichensatz-Bezeichnungen, ein Padding-Flag und einen kurzen Standard-Verweis-String, damit Clients prüfen können, welches Profil getroffen wurde. Klassische Prüfungen sind das Kodieren von Hello zu JBSWY3DP, das Kodieren des einzelnen Buchstabens f zu MY mit sechs Gleichheitszeichen und das Dekodieren eines bekannten aufgefüllten Blocks zurück zu foobar.

Wo Base32-Kodierung in der Praxis auftaucht

Geheimnisse für zeitbasierte Einmalpasswörter nach RFC 6238 und Authenticator-Apps reisen fast immer als Base32, damit Anwender sie abtippen können, ohne null mit dem Buchstaben O oder eins mit dem Buchstaben I so leicht zu verwechseln wie bei Base64. DNS und einige Netzwerk-Konfigurationssysteme bevorzugen Base32-ähnliche Alphabete für undurchsichtige Labels, die das Falten der Groß-/Kleinschreibung überstehen müssen. Mobile Deep Links und kurze Offline-Tokens wählen häufig Base32, weil der Zeichensatz nach der Normalisierung unempfindlich gegenüber Groß-/Kleinschreibung ist und URL-reservierte Zeichen vermeidet.

Support-Teams fügen mehrzeilige Geheimnisse aus Tickets ein und brauchen Leerraum-Toleranz, ohne ungültige Zeichen zu akzeptieren, die einen falschen Schlüssel erzeugen würden. Autoren von Lehrmaterial zu Kodierungsverfahren wünschen eine eigene Seite für Base32, statt es unter einer generischen Base64-Landingpage zu verstecken, denn Suchintention und Alphabet-Regeln unterscheiden sich. Wenn Sie Base64 mit URL-sicherem Alphabet, Prozent-Kodierung für URLs oder Integer-Konvertierung zwischen Basen benötigen, behandeln Sie diese als eigenständige Suchintentionen und Landingpages, statt diese Base32-Encoder-Seite zu überladen.