z-base-32 Encoder & Decoder

z-base-32 ist die menschenorientierte Base32-Variante von Zooko Wilcox-O'Hearn: ein sorgfältig permutiertes Zweiunddreißig-Symbol-Alphabet, das Lesen, Schreiben und gesprochene Transkription erleichtert und dennoch fünf Bits pro Zeichen packt. Anders als RFC-4648-Base32 entfernt es verwirrende Doppelgänger, ordnet Symbole so um, dass gängige Laute häufiger vorkommen, und lässt das Gleichheitszeichen-Padding weg, damit Tokens kurz bleiben. Diese Fähigkeit wandelt UTF-8-Text in kleingeschriebenes z-base-32 um oder stellt den Originaltext aus einer z-base-32-Zeichenkette wieder her.

Wie z-base-32 Bits mit Zookos Alphabet packt

z-base-32 startet von derselben Idee mit fünf Bits pro Zeichen wie klassisches Base32, aber die Symboltabelle ist völlig anders. Die zweiunddreißig Zeichen sind y b n d r f g 8 e j k m c p q x o t 1 u w i s z a 3 4 5 h 7 6 9 in dieser Reihenfolge. Die Ziffern Null und Zwei, der Buchstabe L und der Buchstabe V entfallen, weil sie leicht mit anderen Glyphen verwechselt werden, wenn jemand einen Code vorliest oder von Hand abschreibt.

Die übrigen Symbole sind so geordnet, dass Vokale und häufige Konsonanten eher früher im Werteraum erscheinen, was Zufallszeichenketten etwas aussprechbarer macht. Die Kodierung behandelt Ihre Eingabe als UTF-8-Bytes, liest sie als kontinuierlichen Bitstrom und gibt für je fünf Bits ein Alphabetzeichen aus. Verbleibende Bits am Ende werden rechts mit Nullen aufgefüllt, um ein letztes Quintett zu bilden; Gleichheitszeichen werden nicht angehängt.

Die Dekodierung kehrt die Abbildung um: Jedes Symbol liefert fünf Bits, vollständige Bytes werden ausgegeben, sobald acht Bits anliegen, und restliche Padding-Bits, die kein vollständiges Byte bilden, werden verworfen. Leerzeichen werden ignoriert, damit mehrzeilige Einfügungen funktionieren, und Großbuchstaben werden vor dem Lookup kleingeschrieben.

Was Sie senden und was Sie zurückerhalten

Senden Sie ein Pflicht-Stringfeld namens text und optional mode mit encode oder decode. Fehlt mode, ist encode der Standard, sodass eine minimale Nutzlast weiterhin sinnvoll ist. Der Encode-Modus behandelt text als reinen UTF-8-Inhalt und liefert eine kleingeschriebene result-Zeichenkette im Zooko-Alphabet ohne Padding.

Der Decode-Modus behandelt text als z-base-32, normalisiert Großschreibung und Leerzeichen, prüft jedes Symbol und gibt die wiederhergestellte UTF-8-Zeichenkette in result zurück. Beide Richtungen spiegeln mode, den Original-text, result, ein length-Feld der Hauptausgabe, alphabet- und charset-Labels, ein padding-Flag auf false und einen kurzen Standardverweis wider, damit Clients das Profil prüfen können. Validierungsfehler verbrauchen kein vorausbezahltes Guthaben.

Typische Prüfungen sind das Kodieren eines kurzen Worts wie Hello, das Dekodieren des Roundtrips zum gleichen Text und das Erzwingen eines Fehlers durch Einfügen eines Symbols, das z-base-32 bewusst ausschließt, etwa Null oder den Buchstaben L.

Wo z-base-32 in der Praxis vorkommt

Menschenzugewandte Kennungen, die am Telefon vorgelesen, auf Papier notiert oder von einem Screenshot abgetippt werden müssen, profitieren von einem Alphabet ohne mehrdeutige Glyphen. z-base-32 wurde genau dafür entworfen: Open-Source-Systeme wie Mnet und Tahoe-LAFS sowie Protokolle wie ZRTP übernahmen es, damit Nutzer kompakte Codes tauschen können, ohne die Null-gegen-O- und Eins-gegen-I-Fallen dichterer Alphabete. Produktteams, die Offline-Wiederherstellungsphrasen, kurze air-gapped Auth-Codes oder Support-Einmal-Tokens bauen, bevorzugen oft Zookos Tabelle, wenn die Zeichenkette gesprochen oder transkribiert statt nur maschinell gescannt wird.

Engineering-Gruppen, die Interop-Tests schreiben, brauchen eine einzige Ground Truth für Encode und Decode, die zu ihren Bibliotheken passt und illegale Zeichen nie stillschweigend ersetzt. Lehrende, die Kodierungsschemata vermitteln, wollen eine eigene Landing für z-base-32 statt es unter RFC-4648-Base32 zu verstecken, weil nach Zooko, humanem Base32 und paddingfreien Tokens als getrennte Absichten gesucht wird. Support-Mitarbeiter, die mehrzeilige Codes aus dem Chat einfügen, brauchen Leerzeichen-Toleranz ohne Müllsymbole, die einen falschen Schlüssel ergeben würden.

Wenn Sie klassisches RFC-4648-Base32 mit A-Z und Zwei bis Sieben, Base64 oder Crockford-Base32 brauchen, behandeln Sie diese als getrennte Landings statt diese z-base-32-Encoder-Seite zu überladen.