Hex dekodieren

Leerzeichen, Doppelpunkte, Kommata, Zeilenumbrüche und `0x`-Präfixe werden entfernt, bevor gelesen wird. Was du einfügst, darf also aus einem Paketmitschnitt, aus einer OpenSSL-Ausgabe oder aus einer C-Array-Definition stammen, ohne dass du vorher aufräumst.

Was nicht egal ist, ist die Anzahl der übrigbleibenden Ziffern: Sie muss gerade sein, weil ein Byte zwei Ziffern hat. Eine ungerade Länge ist kein Randfall, den man stillschweigend mit einer Null auffüllen sollte — sie bedeutet, dass beim Kopieren etwas verlorenging, und wird deshalb gemeldet.

Nicht jede Bytefolge ist Text. Ein PNG beginnt mit `89 50 4e 47`, ein PDF mit `25 50 44 46`, eine ZIP-Datei mit `50 4b`. Solche Daten als UTF-8 zu lesen ergibt entweder Ersatzzeichen oder eine Folge, die technisch gültig ist und trotzdem nichts bedeutet.

Statt in diesem Fall etwas auszugeben, das wie ein Ergebnis aussieht, sagt diese Seite, dass die Bytes kein Text sind, und nennt ihre Anzahl. Das ist die nützlichere Antwort: Sie beendet die Suche nach einem Kodierungsfehler und lenkt die Aufmerksamkeit dorthin, wo sie hingehört — auf die Frage, was das für Daten eigentlich sind.

UTF-8 hat eine Struktur, die man mit etwas Übung liest. Bytes unter `80` sind ASCII, also je ein Zeichen. Ein Byte zwischen `c2` und `df` beginnt eine Zwei-Byte-Folge, `e0` bis `ef` eine mit drei, `f0` bis `f4` eine mit vier, und alle Folgebytes liegen zwischen `80` und `bf`.

Daraus folgt eine praktische Faustregel: Ein `c3` mitten im Dump ist fast sicher ein deutsches Sonderzeichen, denn `c3 a4` ist ä, `c3 b6` ist ö und `c3 bc` ist ü. Wer in einem Log ein `c3` sieht, wo ein Umlaut stehen sollte, weiß damit, dass die Bytes stimmen und die Anzeige das Problem hat.

Beginnt die Folge mit `ef bb bf`, steht dort eine UTF-8-BOM. Sie ist unsichtbar, gehört aber zum Inhalt, und sie ist der Grund, warum die erste Spalte einer aus Excel exportierten CSV-Datei manchmal einen Namen trägt, den kein einlesendes Programm wiedererkennt.

Dieselbe Markierung kann bei anderer Kodierung `fe ff` oder `ff fe` lauten — dann liegt UTF-16 vor und nicht UTF-8, und die Bytes sind hier entsprechend nicht als Text lesbar. Ein `ff fe` am Anfang gefolgt von lauter Nullbytes zwischen den Buchstaben ist die typische Signatur einer Datei aus dem Windows-Notepad in älterer Fassung.

Wenn im Dump zwischen jedem lesbaren Byte eine `00` steht, ist die Kodierung UTF-16 und nicht UTF-8. Ein `48 00 61 00` ist „Ha“ in UTF-16 mit niederwertigem Byte zuerst — dieselben Buchstaben, andere Kodierung, und als UTF-8 gelesen ergibt es Text mit eingestreuten Steuerzeichen.

Das begegnet einem bei Windows-Registry-Exporten, bei manchen SQL-Server-Feldern und bei allem, was durch die Windows-API in ihrer Unicode-Variante gelaufen ist. Die Erkennung ist einfach, sobald man die Bytes sieht — und das ist der eigentliche Nutzen dieser Seite gegenüber einem Werkzeug, das nur eine Antwort ausspuckt.

Jede Bytefolge lässt sich als Latin-1 lesen, weil dort jedes der 256 Bytes ein Zeichen ist. Ein Dekodierer, der bei ungültigem UTF-8 stillschweigend darauf ausweicht, gibt deshalb immer etwas aus — und dieses Etwas ist bei Binärdaten Unsinn und bei falsch gelesenem UTF-8 die berüchtigte Ä-Doppelbuchstaben-Erscheinung.

Solche Ausweichmanöver machen aus einem erkennbaren Fehler ein plausibles Ergebnis, und das ist die schlechtere Eigenschaft. Hier gibt es deshalb keine stille Zweitkodierung: Entweder es ist gültiges UTF-8, oder du erfährst, dass es keines ist, und kannst selbst entscheiden, was das bedeutet.

Ein häufiger Anlass ist der Vergleich zweier Zertifikatsfingerabdrücke oder Prüfsummen, von denen einer mit Doppelpunkten und in Großbuchstaben notiert ist und der andere ohne und klein. Die Bytes sind identisch, die Zeichenketten nicht, und ein Textvergleich meldet folgerichtig einen Unterschied.

Wer beide durch dieses Feld schickt, sieht sofort, ob es dieselben Bytes sind. Wenn ja, war es ein Formatierungsproblem; wenn nein, unterscheiden sie sich tatsächlich, und dann ist die nächste Frage eine sicherheitsrelevante und keine kosmetische.

Beim Lesen sind beide Schreibweisen gleichwertig und dürfen sich sogar innerhalb derselben Eingabe abwechseln — `4A6f` und `4a6F` bezeichnen dieselben zwei Bytes. Das ist keine Nachlässigkeit, sondern die Regel: Hexziffern sind Zahlen, und Zahlen haben keine Schreibweise.

Streng ist es nur in der Gegenrichtung. Wer aus Bytes eine Zeichenkette macht, die später verglichen oder gehasht wird, muss sich für eine Schreibweise entscheiden und dabeibleiben. Die Kodierseite auf dieser Website bietet die Wahl an, damit du dich nach dem richten kannst, was dein Gegenüber erwartet.

Es gibt keine Datei-Ausgabe. Wenn die Bytes eine PNG-Datei sind, hätte diese Seite genug Informationen, um sie zum Download anzubieten — sie tut es nicht, weil das eine andere Aufgabe ist und eine, bei der man wissen sollte, was man tut. Aus einem Hexdump aus fremder Quelle eine ausführbare Datei zu bauen, ist kein Handgriff, den ein Textwerkzeug beiläufig anbieten sollte.

Es gibt auch keine automatische Erkennung der Kodierung. Sie wäre bei kurzen Eingaben unzuverlässig und würde genau dann falsch raten, wenn es darauf ankommt. Was die Seite stattdessen tut, ist dir zu sagen, dass es kein UTF-8 ist — die Entscheidung, was es dann ist, hast du besser in der Hand als eine Heuristik.

Ein Hexdump aus einem Log oder einem Paketmitschnitt enthält regelmäßig, was gerade übertragen wurde — Zugangsdaten, Sitzungsschlüssel, Nutzdaten mit Namen darin. Weil hier in der Seite dekodiert wird, findet keine Übermittlung an uns statt und keine Auftragsverarbeitung für diesen Inhalt.

Bei genau dieser Art von Wert ist das der entscheidende Punkt. Ein Mitschnitt ist per Definition etwas, das man nicht ein zweites Mal nach draußen geben will, und ein Werkzeug, das ihn auf einem fremden Server dekodiert, hat ihn damit gesehen. Das Netzwerk-Panel zeigt, dass hier nichts hinausgeht.

Kodieren und Dekodieren scheitern völlig unterschiedlich. Beim Kodieren geht es um die Wahl des Trennzeichens und um die Frage, warum ein Umlaut zwei Bytes ergibt; beim Dekodieren um ungerade Ziffernzahlen, um Bytes, die kein Text sind, und um die Erkennung, dass eigentlich UTF-16 vorliegt.

Wer eine dieser beiden Fragen hat, hat die andere fast nie. Eine gemeinsame Seite mit Umschalter müsste beide Erklärungen tragen und wäre für jeden zur Hälfte Ballast. Die Engine ist dieselbe — getrennt sind die Seiten, weil die Fehler es sind.