Hex kodieren

Hexadezimal ist eine Schreibweise für Bytes, und ein Byte hat genau 256 mögliche Werte, also genau zwei Hexziffern. Das ist der Grund, warum die Ausgabe immer eine gerade Anzahl Ziffern hat — eine ungerade Länge ist ein sicheres Zeichen dafür, dass unterwegs etwas verlorenging.

Ein Zeichen ist dagegen nicht notwendig ein Byte. Ein `a` ist eines, ein `ä` sind zwei, ein chinesisches Zeichen drei und ein Emoji vier. Wer die Länge eines Texts in Bytes wissen will, sieht sie hier direkt — und regelmäßig ist sie um ein Drittel größer als die Zeichenzahl, mit der ein Feldlimit gerechnet wurde.

Ein Text ist eine Folge von Zeichen, Bytes werden daraus erst durch eine Kodierung. Die Frage „welche Bytes hat dieser Text“ ist also unvollständig, solange die Kodierung nicht dabeisteht. Hier ist es UTF-8, weil das Web, Linux, macOS, JSON und praktisch jedes moderne Protokoll darauf festgelegt sind.

Wo noch etwas anderes im Spiel ist — eine alte Windows-Codepage, Latin-1 in einer Datenbankspalte —, weichen die Bytes ab, und zwar genau bei den Zeichen über ASCII. Ein `ä` ist in UTF-8 `c3 a4` und in Latin-1 das eine Byte `e4`. Wenn deine Werte nicht zusammenpassen, ist das die erste Stelle zum Nachsehen.

Doppelpunkte zwischen den Bytes sind die Schreibweise, in der OpenSSL Zertifikatsfingerabdrücke ausgibt und in der man MAC-Adressen liest. Leerzeichen sind die Form eines Hexdumps, wie ihn `xxd` oder ein Paketmitschnitt zeigt. Gar kein Trennzeichen ist, was in ein Datenbankfeld, eine Konfigurationszeile oder einen Hash-Vergleich gehört.

Praktisch heißt das: Die Wahl hier richtet sich danach, wohin der Wert soll, nicht danach, was besser aussieht. Ein Vergleich zweier Fingerabdrücke scheitert überraschend oft nur daran, dass einer mit und einer ohne Doppelpunkte notiert wurde — die Bytes sind dieselben, die Zeichenketten nicht.

Für den Wert eines Bytes macht die Schreibweise der Ziffern keinen Unterschied; `ff` und `FF` sind dieselbe Zahl. Für einen Textvergleich macht sie den ganzen Unterschied, und deshalb ist die Frage nicht kosmetisch, sobald der Wert irgendwo verglichen, gehasht oder als Schlüssel benutzt wird.

Die Konventionen sind uneinheitlich: Unix-Werkzeuge und die meisten Programmierbibliotheken schreiben klein, Windows-Werkzeuge und viele Zertifikatsanzeigen groß, MAC-Adressen je nach Hersteller beides. Wer vergleicht, normalisiert vorher — und wer eine Signatur bildet, muss wissen, welche Schreibweise die Spezifikation verlangt, weil der Hash sonst ein anderer ist.

Der häufigste ernsthafte Anlass, einen Text hexadezimal anzusehen, ist ein Vergleich, der scheitert, obwohl beide Werte gleich aussehen. In der Byte-Ansicht ist sofort sichtbar, was der Bildschirm verbirgt: ein `c2 a0` für ein geschütztes Leerzeichen, ein `0d` vor dem `0a` einer Windows-Zeile, ein `09` für einen Tabulator, wo ein Leerzeichen vermutet wurde.

Ebenso häufig ist ein `ef bb bf` am Anfang — die Byte-Reihenfolge-Markierung, die Excel und einige Windows-Editoren an den Dateianfang setzen. Sie ist unsichtbar, gehört aber zum Inhalt, und sie ist der Grund, warum die erste Spalte einer CSV-Datei manchmal einen Namen hat, den kein Programm wiedererkennt.

Windows beendet eine Zeile mit `0d 0a`, Unix und macOS mit `0a`. Am Bildschirm sieht beides identisch aus, in den Bytes nicht — und deshalb weichen Prüfsummen zweier „gleicher“ Dateien ab, melden Versionsverwaltungen Änderungen an unberührten Zeilen und schlägt ein Vergleich fehl, den man für trivial hielt.

In dieser Seite kannst du das direkt sehen: Text mit Zeilenumbruch einfügen und nachsehen, ob vor dem `0a` ein `0d` steht. Das ist der schnellste Weg, die Frage zu klären, ob ein Werkzeug in der Kette die Zeilenenden umgeschrieben hat — was Git je nach Einstellung ausdrücklich tut.

Beide schreiben Bytes als druckbaren Text, und die Wahl zwischen ihnen ist eine zwischen Lesbarkeit und Größe. Hexadezimal braucht zwei Zeichen pro Byte, also doppelt so viel Platz; Base64 braucht rund ein Drittel mehr als die Rohdaten und ist damit deutlich sparsamer.

Dafür ist Hex lesbar. Man kann ein einzelnes Byte an einer bestimmten Stelle ablesen, zwei Werte nebeneinanderhalten und den ersten Unterschied finden, und man sieht die Grenzen zwischen den Bytes. In Base64 geht das nicht, weil dort drei Bytes zu vier Zeichen verschmelzen. Für Hashes und Fingerabdrücke ist deshalb Hex üblich, für Nutzdaten Base64.

Ein klassischer Hexdump zeigt sechzehn Bytes pro Zeile, davor die Position und dahinter die druckbaren Zeichen. Sechzehn nicht aus Ästhetik, sondern weil die Position dann in Hex immer auf eine Null endet und sich das Rechnen im Kopf erübrigt.

Diese Seite gibt einen durchgehenden Strom aus, keinen formatierten Dump mit Adressspalte — für ein Datenbankfeld, einen Vergleich oder eine Konfigurationszeile ist genau das die brauchbare Form. Wer den klassischen Dump mit Adressen braucht, ist bei `xxd` oder `hexdump -C` besser aufgehoben; das sind Werkzeuge für Dateien, und dies ist eines für Zeichenketten.

Das Präfix `0x` ist eine Konvention aus Programmiersprachen und sagt dem Compiler, dass die folgenden Ziffern hexadezimal zu lesen sind. Es gehört vor eine einzelne Zahl im Quelltext, nicht vor jedes Byte einer Folge — `0x48 0x61` ist eine Liste zweier Zahlen, `4861` sind zwei Bytes.

Diese Seite erzeugt deshalb kein Präfix. Die Gegenrichtung ist großzügiger: Der Dekodierer auf dieser Website akzeptiert `0x` vor jedem Byte, weil solche Listen aus Quelltext kopiert bei einem tatsächlich ankommen. Erzeugen und Annehmen dürfen sich unterscheiden, und hier tun sie es bewusst.

In dieses Feld kommt oft der Wert, den man gerade nicht bewegen möchte: ein Datensatzfeld, das sich seltsam verhält, ein Schlüssel, ein Passwortkandidat, der mit einer Prüfsumme abgeglichen werden soll. Weil die Umrechnung in der Seite passiert, findet keine Übermittlung an uns statt.

Das ist im Netzwerk-Panel nachprüfbar: Während der Benutzung geht keine Anfrage hinaus, die deine Eingabe trägt. Was bleibt, steht in der Datenschutzerklärung — der Seitenaufruf und die Werbe- und Analytics-Anfragen. Der Inhalt des Textfelds gehört nicht dazu, und genau darauf kommt es bei dieser Art von Wert an.

Für Dateien gibt es auf dieser Website eine Prüfsummen-Seite mit einem Ablagefeld, und sie beantwortet eine andere Frage: ob ein Download unverändert angekommen ist. Diese Seite beantwortet, aus welchen Bytes ein Text besteht — ein Feldwert, eine Zeile aus einem Log, ein Wert aus der Zwischenablage.

Beides zusammenzulegen hieße, jedem die Hälfte der Oberfläche als totes Gewicht hinzustellen. Wer eine ganze Datei als Hexdump sehen will, ist zudem mit einem Werkzeug auf dem eigenen Rechner besser bedient: Eine Datei von hundert Megabyte ergibt zweihundert Megabyte Text, und keine Textfläche im Browser findet das lustig.