Base16-RFC-4648-Encoder & -Decoder

RFC 4648 Base16 ist die standardisierte Hexadezimalkodierung in Großbuchstaben: Jedes Eingabebyte wird zu genau zwei Zeichen aus dem Alphabet 0-9 und A-F, ohne Füllzeichen und ohne mehrdeutige Glyphen. Dieses Werkzeug kodiert reinen UTF-8-Text in diese kanonische Base16-Form und dekodiert Base16-Hex-Strings zurück zu Text, sodass Sie in beide Richtungen einfügen können, ohne eine Krypto-Bibliothek zu installieren. Die Kodierung gibt stets Großbuchstaben aus, wie der Standard es verlangt; die Dekodierung akzeptiert übliches Einfüge-Rauschen wie Leerzeichen, Doppelpunkte und gemischte Groß- und Kleinschreibung und normalisiert und validiert dann vor der Umwandlung.

Was RFC 4648 Base16 ist und wie das Alphabet funktioniert

Base16 ist in RFC 4648 als Binär-zu-Text-Kodierung definiert, die jedes Acht-Bit-Oktett auf zwei Symbole eines Alphabets aus sechzehn Zeichen abbildet: die Dezimalziffern null bis neun gefolgt von den lateinischen Großbuchstaben A bis F. Dieses Alphabet ist identisch mit der vertrauten Hexadezimalschreibweise in Großbuchstaben aus Protokolldokumenten, Paketmitschnitten und vielen Hardware-Handbüchern. Die Kodierung durchläuft die Eingabe von links nach rechts, teilt jedes Byte in ein hohes und ein niedriges Nibble und bildet jedes Nibble auf ein Alphabetzeichen ab, wodurch ein String entsteht, dessen Länge immer das Doppelte der Byteanzahl beträgt.

Es gibt kein Füllzeichen und keine Zeilenumbruchregel in der Kernkodierung; Verbraucher, die Zeilenumbrüche oder Trennzeichen brauchen, fügen sie nur zur Anzeige hinzu. Die Dekodierung kehrt die Abbildung um: Jeweils zwei aufeinanderfolgende Hex-Ziffern werden zu einem Byte. Implementierungen, die RFC-4648-Konformität beanspruchen, kodieren mit Großbuchstaben A–F; viele Decoder akzeptieren auch Kleinbuchstaben a–f für die Interoperabilität mit Werkzeugen, die gemischte Schreibweise ausgeben.

Leerzeichen und dekorative Trennzeichen wie Doppelpunkte, Unterstriche oder Bindestriche tauchen oft in manuell bearbeiteten Dumps auf und sollten vor den Längen- und Alphabetprüfungen entfernt werden; der verbleibende durchgehende String muss eine gerade Länge haben. Wenn ein Zeichen außerhalb von 0-9A-Fa-f erscheint oder die Ziffernzahl ungerade ist, muss der Decoder laut fehlschlagen.

Praktische Tipps, Grenzen und Unterschiede zu anderen Kodierungen

Bevorzugen Sie encode, wenn Sie von lesbarem Text oder kurzen UTF-8-Nutzlasten ausgehen, die Sie als kanonischen Hex-Dump in Großbuchstaben für Spezifikationen, Tickets oder Unit-Tests brauchen. Round-Trip-Prüfungen sind der schnellste Smoke-Test: Kodieren Sie ein bekanntes Wort wie Hello, bestätigen Sie das klassische Ergebnis in Großbuchstaben 48656C6C6F, dekodieren Sie dann diesen String und bestätigen Sie, dass Sie die ursprüngliche Phrase Byte für Byte zurückerhalten. Halten Sie Nutzlasten unter dem veröffentlichten Zeichenlimit; Dumps von mehreren Megabyte gehören offline oder in dedizierte Binärwerkzeuge.

Dieses Werkzeug ist nicht Base64 oder Base64URL — jene Alphabete verwenden vierundsechzig Symbole mit Füllzeichen und dichterer Packung. Es ist auch nicht Base58, das mehrdeutige Glyphen für die menschliche Übertragung weglässt. Und es ist kein Basis-Konverter für Ganzzahlen oder Floats: Um eine einzelne Hex-Zahl in Dezimal oder Binär umzuwandeln, nutzen Sie die dedizierten Zahlenformat-Fähigkeiten, statt die Ziffern als opake Bytefolge zu behandeln.

Bevorzugen Sie Base16, wenn Sie einen 1:1 nibble-sichtbaren Dump brauchen, der zu RFC 4648 und zum Lehrbuch-Hex passt; bevorzugen Sie Base64, wenn Dichte wichtiger ist als Lesbarkeit. Zeigen Sie im Unterricht denselben Satz in Base16 und Base64 nebeneinander kodiert, damit Lernende sehen, warum Hex länger und immer von gerader Länge ist und warum A–F in Großbuchstaben die standardisierte Form in RFC 4648 Tabelle 5 ist.