enpit_banner_blue
Kontakt
Menü
Zurück zur Übersicht

Lesbare IDs dank Crockfords Base32 Kodierung


Till Wiebke

2 Minuten

Es kommt leider immer wieder mal vor, dass in (verteilten) Anwendungen ein Fehler auftritt. Wenden sich dann Anwender:innen an den Support, ist es enorm hilfreich, wenn die Fehlermeldung eine Information (z.B. Trace-ID) beinhaltet, mit deren Hilfe die fehlgeschlagene Operation identifiziert wird. Die Person, die mit der Fehleranalyse betraut wird, kann dann in den Logs die für die Operation relevanten Informationen leichter finden.

Damit der Umgang mit der Trace-ID so komfortabel wie möglich ist, sollte sie zwei Eigenschaften aufweisen:

  1. Die Trace-ID sollte von Menschen gut schreib- und lesbar sein, da sie unter Umständen per Telefon oder E-Mail übermittelt wird.

  2. Es sollte leicht erkennbar sein, ob die Trace-ID gültig ist, oder ob ein Übermittlungsfehler (z.B. ein Buchstabendreher) vorliegt. Anderenfalls versucht man Geister in seinen Logs zu finden.

Je kürzer die ID ist, desto einfacher lässt sie sich per Telefon oder Chatnachricht übermitteln. Daraus folgt, dass pro Zeichen soviele Informationen wie möglich übertragen werden sollten. Nutzt man beispielsweise Buchstaben anstelle von Zahlen, lassen sich pro Zeichen 26 anstelle von 10 Werten übertragen. Man sollte dies aber nicht komplett ausreizen, da die Eindeutigkeit der Zeichen und dadurch die Lese- und Vermittelbarkeit leidet (wer mal am Telefon ein Passwort mit Groß- und Kleinschreibung und Zahlen übermittelt hat, weiß, was ich meine). Einen guten Kompromiss in Bezug auf Lesbarkeit und Informationsdichte pro Zeichen bietet die Base32-Kodierung. Mit ihr lassen sich 32 Werte pro Zeichen abbilden. Nutzt man das Alphabet gemäß RFC4648, werden die Ziffern 0, 1 und 8 aufgrund der Verwechslungsgefahr mit Buchstaben (O, B, I und l) nicht verwendet. Eine weitere Vereinfachung ist, dass nicht zwischen Groß- und Kleinschreibung unterschieden werden muss.

Um einfache Übermittlungsfehler beim Übertragen einer ID entdecken zu können, bietet es sich an, diese um eine Prüfsumme zu erweitern. Douglas Crockford hat in seiner Variante der Base32-Kodierung diese spezifiziert. Diese wird mit einer Modulo-Berechnung erstellt und als Base37-kodiertes Zeichen dem kodierten Text hinten angestellt.

Crockfords Variante bietet auch noch einen weiteren Vorteil in Bezug auf die Lesbarkeit: Bindestriche im kodierten Text werden ignoriert. So kann die ID CNQ70TBM41SP2SVM41462V3CDWGG in mehrere Blöcke (CNQ7-0TBM41SP-2SVM-41462V-3CDWGG) aufgeteilt werden, ohne den Inhalt (die eigentliche ID) zu ändern.

Zum Abschluss noch ein paar Tipps:

Base32-kodierte IDs lassen sich auch nachträglich in bestehende Systeme einbinden: Das Frontend kann die bestehenden IDs vor der Darstellung mittels Base32 kodieren und diesen Wert dann anzeigen. Andere Systembestandteile müssen dann nicht angepasst werden.

Wenn Base32-kodierte IDs auch in Datenbanken geschrieben werden sollten, solltest du die Prüfsumme nicht mitspeichern, da sie nicht Bestandteil der eigentlichen ID ist.

Wenn du eine API designest und überlegst Base64 zur Kodierung von Identifiern zu nutzen, nimm Base32. Im Gegensatz zu Base64 verwendet Base32 keine Zeichen, die im HTTP-Kontext eine andere Bedeutung haben (z.B. /).

Du musst die Kodierung übrigens nicht selbst implementieren. Es gibt bereits einige Pakete (Javascript, .NET, Python), die das für dich übernehmen.

ASMPAV10ADR62WVK41H6ATBD410QAWVGE9QP4TB5E9JPW88 😉

Donnerstag, 18.08.2022

Diesen Artikel teilen über:




enpit GmbH & Co. KG

Marienplatz 11a33098 Paderborn
+49 5251 2027791info@enpit.de
© 2022 – enpit GmbH & Co. KGDatenschutzerklärung | Impressum