hex/

Das hängt vom Zeichensatz ab. In UTF-8 belegt ein Umlaut wie ä 2 Bytes (c3 a4), ein gängiges chinesisches Zeichen 3 Bytes, zum Beispiel 中 = e4 b8 ad; ein Emoji belegt in UTF-8 4 Bytes. In ISO-8859-1 ist ä nur 1 Byte (e4), und in GBK und GB2312 braucht 中 2 Bytes: d6 d0. Buchstaben ohne Akzent und Ziffern sind in UTF-8, GBK und ISO-8859-1 jeweils 1 Byte, dort ist das Ergebnis also gleich. Weicht das Ergebnis von einem anderen Tool ab, prüfe zuerst, welchen Zeichensatz dieses Tool verwendet; diese Seite nimmt standardmäßig UTF-8.

Dann sind die Bytes nicht im aktuell gewählten Zeichensatz kodiert; probiere einen anderen. Am häufigsten sind UTF-8 und, bei chinesischem Text, GBK (ältere Software und Datenbank-Exporte verwenden oft GBK); Hex in UTF-16 enthält meist viele 00-Bytes. Dieses Tool zeigt Bytes, die sich nicht dekodieren lassen, nie als Zeichensalat an. Die einzige Ausnahme ist ISO-8859-1: Jedes Byte entspricht dort irgendeinem Zeichen, es gibt also nie einen Fehler, aber aus chinesischem Text wird Zeichensalat. GBK und GB2312 werden beide mit dem im Browser eingebauten GB18030-Decoder dekodiert, der toleranter ist als der von Python oder Java; mit GB2312 lassen sich daher auch Zeichen dekodieren, die es nur in GBK gibt. Waren die Bytes von vornherein kein Text (ein Bild, verschlüsselte Daten, ein Hashwert), lassen sie sich mit keinem Zeichensatz dekodieren.

Groß- und Kleinschreibung ist egal. Bytes können durch Leerzeichen, Zeilenumbrüche, Tabulatoren, Doppelpunkte, Kommas oder Bindestriche getrennt sein oder auch ohne Trennung dastehen, und jedem Byte darf 0x oder \x vorangestellt sein; 0x48,0x65 und \x48\x65 lassen sich also direkt dekodieren. Jede Gruppe zwischen zwei Trennzeichen muss eine gerade Anzahl von Ziffern haben, schreibe also 0x01 statt 0x1. Auch jedes andere Zeichen außer 0-9 und a-f führt zu einem Fehler. Beide Fehler nennen die Position des Zeichens. Schreibweisen wie U+4E2D und %E4%B8%AD werden nicht erkannt; für die URL-Kodierung nimm das URL-Tool dieser Seite.

Wähle als Trennzeichen „,“ und als Präfix „0x“, dann erhältst du 0x48,0x65, was sich in ein Byte-Array in C oder Java einfügen lässt. Wähle als Trennzeichen „Ohne“ und als Präfix „\x“, dann erhältst du \x48\x65, die Byte-Schreibweise in Strings in Python und C. Das Präfix wird jedem Byte vorangestellt; „Ohne“ als Trennzeichen zusammen mit 0x ergibt daher 0x480x65, was selten sinnvoll ist. „Großbuchstaben“ wirkt sich nur auf a-f aus, das x in 0x bleibt klein.

UTF-16 wird wie in Java ausgegeben: Es beginnt mit FE FF (Byte-Order-Mark) und ist Big-Endian, daher wird 中 zu fe ff 4e 2d. UTF-16BE ohne Marke ist 4e 2d; kopiere das Ergebnis und lösche die ersten beiden Bytes. UTF-32 ist Big-Endian ohne Marke, 中 ist also 00 00 4e 2d. Beim Dekodieren akzeptiert UTF-16 am Anfang FE FF (Big-Endian) oder FF FE (Little-Endian) und geht ohne Marke von Big-Endian aus.

ASCII deckt nur 0 bis 127 ab, ä, ö, ü und ß sind darin also nicht enthalten. ISO-8859-1 reicht nur bis U+00FF (westeuropäische Buchstaben mit Akzent, darunter ä, ö, ü und ß, aber weder chinesische Zeichen noch das Euro-Zeichen). Für Zeichen außerhalb des Bereichs erscheint ein Fehler, dass sich das Zeichen im gewählten Zeichensatz nicht kodieren lässt; es wird nicht wie bei getBytes in Java stillschweigend durch ? ersetzt. GBK und GB2312 verhalten sich genauso: Emojis und seltene Zeichen, die in der Zeichentabelle fehlen, führen zu einem Fehler. Mit UTF-8 oder GB18030 lassen sie sich umwandeln.

Von Text zu Hex ja. Jedes Zeichen im Eingabefeld wird umgewandelt, auch Leerzeichen und Zeilenumbrüche am Anfang und Ende: Ein Leerzeichen ist 20, ein Zeilenumbruch 0a. Das Textfeld des Browsers vereinheitlicht Zeilenumbrüche zu \n, deshalb wird ein Zeilenumbruch in mehrzeiligem Text zu 0a statt 0d 0a; brauchst du Windows-Zeilenenden, ändere das Ergebnis selbst. Von Hex zu Text wird Leerraum im Hex ignoriert, nur die Bytes zählen; auch ein 0d 0a im Ergebnis wird als ein einziger Zeilenumbruch angezeigt.

Nein. Die Umwandlung läuft in deinem Browser, sendet keine Anfragen und speichert nichts.