Text-zu-Hexadezimal-Konverter

Eine Zeichenkette als die Bytes, in denen sie gespeichert ist

Jede Zeichenkette, mit der ein Programm arbeitet, ist darunter eine Reihe von Bytes, und diese Seite schreibt sie hexadezimal aus, zwei Ziffern für jedes Byte. Geben Sie Hello ein, und Sie erhalten 48 65 6C 6C 6F, ein Byte je Buchstabe, mit einem Leerzeichen nach jedem außer dem letzten. Stellen Sie die Richtung stattdessen auf „Hexadezimal zu Text“ und fügen Sie Hexadezimalcode aus einem Log, einer Datenbank oder einem Debugger ein, und Sie erhalten den Text zurück, den diese Bytes enthalten.

Derselbe Text ergibt in verschiedenen Codierungen verschiedene Bytes, und die Einheit entscheidet, was die Ziffern auf dieser Seite sind. Anfangs steht sie auf UTF-8, der Codierung des Webs, in der H das Byte 48 ist und א die Bytes D7 90. UTF-16 LE und UTF-16 BE verwenden für jedes der beiden Zeichen zwei Bytes, in entgegengesetzter Reihenfolge — 48 00 oder 00 48 für H —, während „Codepunkte“ ganz ohne Bytes auskommt und die Nummer schreibt, die Unicode vergibt, U+05D0 für א. Die eingestellte Einheit gilt für Hexadezimalcode, den Sie lesen, ebenso wie für Text, den Sie schreiben, und sie bleibt eingestellt: Ähnelt eingefügter Hexadezimalcode dem einer anderen Einheit, kann die Seite diese vorschlagen, doch nur Ihr Klick stellt sie um.

Zwei hexadezimale Ziffern für jedes Byte

Ein Byte fasst einen von 256 Werten, 0 bis 255. Hexadezimal zählt in Sechzehnern, mit den Ziffern 0 bis 9 und danach A bis F für zehn bis fünfzehn, und sechzehn Sechzehner sind 256, also benennen zwei hexadezimale Ziffern jedes Byte, und eine dritte wird nie gebraucht: 00 ist 0, 7F ist 127 und FF ist 255. H ist 72, vier Sechzehner und acht, also ist sein Byte 48.

Jede hexadezimale Ziffer steht für genau vier Bits, ein halbes Byte: Die 4 von 48 ist 0100 und die 8 ist 1000, und nebeneinander sind sie die acht Bits von H, 01001000. Die Seite behält beide Ziffern jedes Bytes, also ist ein Zeilenvorschub 0A und ein Leerzeichen 20, und weil jedes Byte dieselbe Breite hat, lässt sich Hexadezimalcode ohne etwas zwischen den Bytes zurücklesen: 4869 ist Hi.

Buchstaben im Hexadezimalcode bedeuten in Groß- und Kleinschreibung dasselbe. Die Seite schreibt Großbuchstaben, sofern Sie nicht „kleinschreibung“ wählen, also ist é C3 A9 oder c3 a9, und sie liest beides, auch wenn es in einem eingefügten Text gemischt vorkommt.

Fünf Stile, jeder auf den Ort zugeschnitten, an dem er eingefügt wird

In Hexadezimal ordnet die Auswahl „Stil“ dieselben Bytes auf fünf Arten an, jede für einen Ort, an den Hexadezimalcode als Nächstes geht. Für Hi, also die zwei Bytes 48 und 69:

• „Mit Leerzeichen“ ergibt 48 69, ein Leerzeichen zwischen den Bytes: am leichtesten zu lesen und zu zählen, und der Stil, mit dem die Seite öffnet.
• „Kompakt“ ergibt 4869, die Ziffern ohne Abstand aneinander, für ein Feld oder einen Parameter, der einen Wert als eine Zeichenkette hexadezimaler Ziffern annimmt.
• „Array“ ergibt 0x48, 0x69, jedes Byte eine Zahl mit 0x davor und einem Komma dazwischen, bereit zum Einfügen in ein Byte-Array in C, C#, JavaScript, Python oder Go.
• „Maskiert“ ergibt \x48\x69, jedes Byte als \x und seine zwei Ziffern, so wie ein Byte in einer C-Zeichenkette oder in einem Python-Bytes-Literal wie b'\x48\x69' geschrieben wird.
• „Hexdump“ legt die Bytes in Zeilen an, mit der Stelle, an der jede Zeile beginnt, und denselben Bytes als Text daneben: Der nächste Abschnitt liest einen.

Das Zurücklesen nimmt alle fünf an, dazu andere Formatierung, die die Bytes nicht verändert: Doppelpunkte wie in 48:69, die Bindestriche, die BitConverter.ToString von .NET schreibt, wie in 48-69, 0x oder 0X vor jedem Byte und den ganzen eingefügten Text, einmal in runde, eckige oder geschweifte Klammern oder in Anführungszeichen gefasst. Der Stil und die Groß- und Kleinschreibung zählen nur beim Schreiben, deshalb verschwinden beide Bedienelemente, wenn die Richtung „Hexadezimal zu Text“ ist.

In „Maskiert“ steckt eine Falle. In einer JavaScript-Zeichenkette oder in einer gewöhnlichen Python-Zeichenkette statt eines Bytes-Literals bezeichnet \x ein Zeichen und kein Byte, also steht \xD7\x90 dort für zwei Zeichen und nicht für das א, dessen UTF-8-Bytes D7 90 sind. Jenseits von ASCII übergeben Sie die Bytes an etwas, das Bytes annimmt.

Einen Hexdump lesen, Spalte für Spalte

Ein Hexdump legt Bytes zu sechzehn pro Zeile an, und auf jeder Seite hilft Ihnen eine Spalte, sie zu finden. Im Stil „Hexdump“ geschrieben, füllen Hello, World! und ein Zeilenvorschub eine Zeile: zuerst 00000000, der Versatz, also die Stelle, an der das erste Byte der Zeile steht, von null an gezählt, in acht hexadezimalen Ziffern; dann die vierzehn Bytes, acht und dann sechs, mit einer breiteren Lücke zwischen den Hälften; dann |Hello, World!.|, dieselben Bytes als Zeichen, wobei jedes Byte, das kein druckbares ASCII ist, als Punkt erscheint, der Zeilenvorschub eingeschlossen. Eine letzte Zeile enthält nur 0000000E, also vierzehn: die Stelle, an der das nächste Byte stünde, und damit die Länge. Das ist das Layout, das hexdump -C ausgibt.

• Ist „Hexadezimal zu Text“ gewählt und irgendeine Einheit außer „Codepunkte“, wird ein eingefügter Hexdump allein auf seine Bytes hin gelesen: Die Textspalte bleibt beim Lesen außen vor, kein Versatz wird als Byte gelesen, und ein Hinweis unter dem Ergebnis sagt, dass die Eingabe als Hexdump aufgefasst wurde, und nennt das Layout.
• Zwei Layouts werden so gelesen: das von hexdump -C und das, was xxd ohne Optionen ausgibt, wo auf jeden Versatz ein Doppelpunkt folgt und die Bytes in Gruppen von vier Ziffern stehen. Der schlichte Hexadezimalcode, den xxd -p ausgibt, braucht kein Layout und wird wie jeder andere Hexadezimalcode gelesen.
• hexdump -C gibt anstelle von Zeilen, die die Zeile darüber wiederholen, eine Zeile aus, die nur * enthält, und die Seite füllt diese Zeilen anhand des Versatzes darunter wieder auf, sodass die Bytes vollständig zurückkommen.
• Jeder Versatz nach dem ersten muss sich aus den Bytes darüber ergeben, die Länge in der letzten Zeile von hexdump -C eingeschlossen, und eine Zeile, deren Versatz das nicht tut, wird dort abgelehnt, statt falsch gelesen zu werden: Dort zeigt sich eine ausgelassene Zeile, ein verlorenes Byte oder ein vertippter Versatz. Wonach kein Versatz mehr kommt, lässt sich nicht prüfen, also wird ein Hexdump, dem die ersten Zeilen fehlen, oder das Ende eines Hexdumps ohne Längenzeile danach — xxd schreibt keine — als das gelesen, was übrig ist.

UTF-16 LE, und warum jedes zweite Byte 00 ist

Windows speichert Text in UTF-16 mit dem niederwertigen Byte zuerst, also in UTF-16 LE; in .NET ist das Encoding.Unicode, und SQL Server speichert einen NVARCHAR-Wert auf dieselbe Weise. UTF-16 gibt jedem Zeichen bis U+FFFF zwei Bytes, und für alles bis U+00FF — die englischen Buchstaben, die Ziffern, é und den Rest von Latin-1 — ist das höherwertige Byte 00. Mit dem niederwertigen Byte zuerst landet diese Null hinter jedem Buchstaben: Hi ist 48 00 69 00.

SQL Server zeigt einen VARBINARY-Wert als 0x und seinen Hexadezimalcode an, also erscheint ein NVARCHAR mit Hi, in VARBINARY umgewandelt, als 0x48006900. Fügen Sie das hier ein, während UTF-8 gewählt ist, und der Text kommt als H, ein NUL, i und ein NUL heraus, und der Hinweis darunter sagt, dass jedes zweite Byte 00 ist, wie bei Text in lateinischer Schrift, der in UTF-16 statt in UTF-8 geschrieben ist, mit „Zu UTF-16 LE wechseln“ daneben. Drücken Sie darauf, und dieselben Bytes ergeben Hi.

UTF-16 BE stellt stattdessen das höherwertige Byte voran, dort ist Hi also 00 48 00 69, und א, in UTF-16 LE D0 05, ist 05 D0. Nullen an der ersten Stelle jedes Paars lassen den Hinweis UTF-16 BE anbieten. Er sagt nichts, sobald ein Zeichen jenseits von U+00FF im Text steht, denn dessen höherwertiges Byte ist nicht 00, und er meldet sich nur dort, wo jedes zweite Byte 00 ist.

Eine Bytereihenfolge-Markierung am Anfang

Ein Text kann mit U+FEFF beginnen, einem Zeichen, das nichts anzeigt und dazu da ist, eine Bytereihenfolge-Markierung zu sein. In UTF-16 geben seine zwei Bytes die Reihenfolge jedes folgenden Paars an, FF FE für UTF-16 LE und FE FF für UTF-16 BE, und in UTF-8 sind es die drei Bytes EF BB BF, eine Signatur dafür, dass der Text UTF-8 ist, das nur eine Reihenfolge hat.

Die Seite behält eine solche Markierung, statt sie zu verwerfen. Hexadezimalcode, der mit der eigenen Markierung der gewählten Einheit beginnt, wird als Text gelesen, der mit U+FEFF beginnt, und ein Hinweis sagt, dass die Markierung behalten wurde, sodass erneutes Schreiben dieses Textes dieselben Bytes ergibt, die Markierung eingeschlossen. Hexadezimalcode, der mit der Markierung der anderen UTF-16-Reihenfolge beginnt oder mit einer UTF-16-Markierung, während UTF-8 gewählt ist, bekommt einen Hinweis, dass die Bytes mit der Markierung einer anderen Einheit beginnen, neben einer Schaltfläche, die zu der Reihenfolge wechselt, die von der Markierung genannt wird. Überall nach dem Anfang ist U+FEFF ein gewöhnliches Zeichen und löst keinen Hinweis aus.

Bytes, die kein Text sind, als U+FFFD angezeigt

Nicht jede Bytefolge ist Text in der gewählten Einheit: Ein Zeichen, dem sein letztes Byte fehlt, ein verirrtes Byte wie E9, das ältere Codepages für é schreiben, und ein einzelnes Byte, das am Ende von UTF-16 übrig bleibt, ergeben alle nichts. Eine fehlerhafte Folge bringt aber nicht den ganzen eingefügten Text zu Fall: Jede wird durch U+FFFD ersetzt, das Ersatzzeichen, und alles andere wird normal gelesen.

Ein Hinweis nennt dann ihre Anzahl und bezeichnet die erste durch ihre Stelle unter den Bytes, durch die Ziffern, die Sie dafür geschrieben haben, und durch ihre Zeile und Spalte. Café, in Windows-1252 gespeichert, der Windows-Codepage für westeuropäischen Text, ist 43 61 66 E9, wobei é dort das eine Byte E9 ist; als UTF-8 gelesen, kommt es als Caf und U+FFFD zurück, und der Hinweis nennt Byte 4, geschrieben als E9, in Zeile 1, Spalte 10. In UTF-8 ist das Wort 43 61 66 C3 A9.

Er zählt Folgen, nicht Bytes: F0 9F 98, drei der vier Bytes von 😀, sind ein U+FFFD. Und ein U+FFFD, das wirklich im Text steht, die Bytes EF BF BD, wird als Text gelesen und gar nicht gezählt, sodass es im Hinweis immer nur um Bytes geht, die sich nicht lesen ließen.

Hexadezimalcode wieder in eine Datei verwandeln

Das Zurücklesen liefert die Bytes ebenso wie den Text. Steht die Richtung auf „Hexadezimal zu Text“ und ist UTF-8, UTF-16 LE oder UTF-16 BE gewählt, speichert „Herunterladen“ als Datei namens bytes.bin genau die Bytes, die gelesen wurden, auch die, die kein Text waren, und bevor eines davon ersetzt wurde: die Aufgabe, die xxd -r mit einem Hexdump erledigt. Für Codepunkte, die keine Bytes sind, gibt es kein „Herunterladen“, und ebenso wenig beim Schreiben, wenn das, was Sie mitnehmen, Ziffern sind.

So kommt auch der Hexadezimalcode von etwas, das nie Text war, vollständig zurück. Jedes PNG-Bild beginnt mit den acht Bytes 89 50 4E 47 0D 0A 1A 0A; als UTF-8 gelesen, erscheinen sie als U+FFFD, die Buchstaben PNG und vier Steuerzeichen, mit einem Hinweis zu der einen Folge, die kein Text ist, und „Herunterladen“ speichert alle acht unverändert. Die Datei heißt immer bytes.bin, da Bytes keinen Namen tragen, geben Sie ihr also einen eigenen, etwa image.png, sobald sie gespeichert ist.

Wohin Sie für ein Zeichen, seine Bits oder eine Zahl gehen

Für das, was ein Zeichen ist — seinen Namen, seine Kategorie und ob es eines der unsichtbaren ist —, zerlegt der Unicode-Zeichen-Inspektor einen Text Codepunkt für Codepunkt und zeigt auch die UTF-8-Bytes jedes einzelnen.

Der Text-zu-Binär-Konverter ist dieselbe Seite, geöffnet mit Binär, wo sich das Muster, dem UTF-8 folgt, in den ersten Bits jedes Bytes ablesen lässt. Und eine Zahl ist kein Text: 255, hier eingegeben, sind die Ziffern 2, 5 und 5 und damit die Bytes 32 35 35, während der Zahlensystem-Umrechner 255 als Zahlenwert nimmt und hexadezimal als ff schreibt.