Was ist 48 65 6C 6C 6F als Text?
Hello 48 ist H, 65 ist e, 6C ist l und 6F ist o in ASCII und UTF-8.
Hex in Text umwandeln und zurück. Hex in jeder Form einfügen – mit Leerzeichen, 0x, \x, xxd- oder hexdump-Ausgabe, Java- oder C-Byte-Arrays. ASCII, UTF-8, GBK oder UTF-16 wird automatisch erkannt. Läuft im Browser.
Erkannt als reines Hex · 13 Bytes
Hello, 世界
Automatisch erkannt: UTF-8 – jede Multibyte-Sequenz ist wohlgeformt.
Das Ergebnis ist selbst Hex – vermutlich wurde zweimal umgewandelt. Eine weitere Runde ergibt:
| Kodierung | Gelesen als |
|---|---|
| UTF-8 Sauber dekodierbar | Hello, 世界 |
| GBK / GB18030 Sauber dekodierbar | Hello, 涓栫晫 |
| UTF-16LE Enthält nicht dekodierbare Bytes | 效汬Ɐ隸闧� |
| UTF-16BE Enthält nicht dekodierbare Bytes | 䡥汬漬⃤뢖� |
| ISO-8859-1 Sauber dekodierbar | Hello, ä¸<96>ç<95><8C> |
48 65 6C 6C 6F 2C 20 E4 B8 96 E7 95 8C
Geschrieben und geprüft von den Entwicklern der Kodierungswerkzeuge von Go Tools. Jeder Hex-Wert und jede Ausgabe auf dieser Seite stammt aus der Engine der Seite selbst und wird durch automatisierte Tests geprüft.
Hello 48 ist H, 65 ist e, 6C ist l und 6F ist o in ASCII und UTF-8.
Meist 3 Bytes in UTF-8, 2 in GBK 你 ist E4 BD A0 in UTF-8 und C4 E3 in GBK.
CR LF (\r\n) Wagenrücklauf gefolgt von Zeilenvorschub – das Zeilenende von Windows, HTTP und den meisten seriellen Befehlssätzen.
41 Das kleine a ist 61; Groß- und Kleinbuchstabe unterscheiden sich immer um 20.
Hexadezimal ist eine Schreibweise für Bytes: Jedes Byte, von 0 bis 255, wird als zwei Ziffern von 00 bis FF geschrieben. Beim Umwandeln von Hex in einen String werden diese Bytes wieder zu lesbarem Text, und dazu gehört immer die Wahl einer Zeichenkodierung – der Tabelle, die festlegt, welches Byte oder welche Bytefolge für welches Zeichen steht.
Bei englischem Text fällt diese Wahl kaum auf, weil ASCII, UTF-8, GBK und die meisten anderen Kodierungen bei den Bytes 00 bis 7F übereinstimmen. Bei allem anderen zeigt sie sich sofort. Die Bytes C4 E3 BA C3 sind 你好 in GBK und ungültig in UTF-8, während 你好 in UTF-8 E4 BD A0 E5 A5 BD ist. Das Hex ist nur die halbe Information; die Kodierung ist die andere Hälfte.
String in Hex ist der umgekehrte Weg: den Text in Bytes kodieren und dann jedes Byte als zwei Hexziffern schreiben. Entwickler nutzen das, um genau zu sehen, was über eine serielle Leitung oder in eine Datenbankspalte geht, um Binärdaten in Quellcode einzubetten und um zu vergleichen, was zwei Systeme tatsächlich gesendet haben.
$ echo 48656c6c6f | xxd -r -p
Hello
>>> bytes.fromhex('c4e3bac3').decode('gbk')
'你好'
>>> bytes.fromhex('c4e3bac3').decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc4 in position 0: invalid continuation byte Mit Leerzeichen, kompakt, durch Doppelpunkte oder Bindestriche getrennt, 0x-Werte, \x-Escapes, %-Kodierung, C-, Go- und Java-Arrays, Javas vorzeichenbehaftete Arrays.toString-Ausgabe, Python-Bytes-Literale, Node.js-Buffer sowie komplette Bildschirme von xxd, hexdump -C und od. Die Seite zeigt, was sie erkannt und was sie entfernt hat.
Die automatische Erkennung prüft auf eine Byte-Order-Mark, wohlgeformtes UTF-8, UTF-16, reines ASCII und zuletzt GBK und nennt die Regel, die entschieden hat. GBK wird nur gewählt, wenn sich die Bytes als gängige chinesische Schriftzeichen lesen lassen; kurze Binär-Frames werden daher als „wahrscheinlich kein Text“ gemeldet statt als sinnloses Chinesisch.
Dieselben Bytes erscheinen als UTF-8, GBK, UTF-16LE, UTF-16BE und ISO-8859-1, jeweils mit der Angabe, ob sie sauber dekodieren oder nicht. Kommt Text als Zeichensalat heraus, steht die richtige Lesart meist eine Zeile tiefer.
NUL, CR, LF, ESC und andere Steuerbytes werden als ␀ ␍ ␊ ␛ angezeigt, sodass ein abschließendes 00 oder ein fehlendes 0D in Protokolldaten auffällt. Beim Kopieren erhalten Sie trotzdem die echten Zeichen.
Text → Hex erzeugt Hex mit Leerzeichen oder kompakt, 0x-Listen, \x-Escapes, ein C-Array im Stil von xxd -i, ein Java-byte[] mit vorzeichenbehafteten Werten, ein Python-Bytes-Literal passend zu repr(), ein Go-[]byte oder einen xxd-Dump – und die Seite kann jedes dieser Formate wieder einlesen.
Einlesen und Dekodieren laufen lokal in JavaScript. Nichts wird hochgeladen, gespeichert oder in die URL geschrieben, deshalb können Sie auch Paketmitschnitte und Produktions-Logs bedenkenlos einfügen.
bytes.fromhex(h).decode() bytes.fromhex('48 65 6c 6c 6f').decode('utf-8') gibt 'Hello' zurück; Leerzeichen zwischen den Bytes sind erlaubt, ein 0x-Präfix nicht. Die Gegenrichtung ist s.encode('utf-8').hex() oder .hex(' ') für eine Ausgabe mit Leerzeichen. Übergeben Sie 'gbk', um chinesischen Text in GBK zu dekodieren oder zu kodieren.
Buffer.from(h, 'hex') Buffer.from(h, 'hex').toString('utf8') dekodiert, Buffer.from(s, 'utf8').toString('hex') kodiert. Ungültige Eingabe ist kein Fehler: Das Dekodieren bricht beim ersten fehlerhaften Paar ab, und eine übrig gebliebene ungerade Ziffer wird verworfen – validieren Sie also vorher.
TextDecoder / TextEncoder Paare mit parseInt(pair, 16) in ein Uint8Array einlesen, dann new TextDecoder('utf-8').decode(bytes). TextDecoder liest auch 'gbk', 'big5' und 'shift_jis', TextEncoder erzeugt dagegen nur UTF-8.
HexFormat.of() new String(HexFormat.of().parseHex(h), StandardCharsets.UTF_8) dekodiert und HexFormat.of().formatHex(s.getBytes(StandardCharsets.UTF_8)) kodiert. In älteren Versionen formatieren Sie jedes Byte mit String.format("%02x", b); meiden Sie Integer.toHexString(b), das für negative Bytes ffffffe4 ausgibt.
encoding/hex hex.DecodeString(h) liefert die Bytes, und string(b) macht daraus einen String; hex.EncodeToString([]byte(s)) geht den Weg zurück. Das Paket ist strikt: Leerzeichen liefern invalid byte: U+0020 ' ' und eine ungerade Länge liefert odd length hex string.
sscanf with %2hhx Den String in Zweierschritten in einen unsigned char-Puffer einlesen und ein abschließendes '\0' anhängen. Für die Hex-Ausgabe nach unsigned char casten und %02X verwenden – sonst können Bytes über 0x7F als FFFFFFE4 ausgegeben werden, wo char vorzeichenbehaftet ist.
hex2bin() / bin2hex() hex2bin('48656c6c6f') gibt Hello zurück und bin2hex('Hello') gibt 48656c6c6f zurück. Laut Handbuch gibt hex2bin() bei ungerader Länge oder ungültiger Eingabe false zurück und löst eine E_WARNING aus.
xxd -r -p / xxd -p echo 48656c6c6f | xxd -r -p gibt Hello aus, und printf 'Hello' | xxd -p gibt 48656c6c6f aus. Verwenden Sie beim Kodieren printf statt echo, denn echo hängt einen Zeilenumbruch an, 0a.
Convert.FromHexString() Encoding.UTF8.GetString(Convert.FromHexString(h)) dekodiert und Convert.ToHexString(Encoding.UTF8.GetBytes(s)) kodiert (in Großbuchstaben, ohne Trennzeichen). FromHexString lehnt Leerzeichen und ein 0x-Präfix ab. .NET Core und .NET 5+ bringen kein GBK mit: Rufen Sie zuerst Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) und dann Encoding.GetEncoding(936) auf.
48 65 6C 6C 6F 2C 20 E4 B8 96 E7 95 8C
Hello, 世界
Die ersten sieben Bytes sind reines ASCII: 48 65 6C 6C 6F ist Hello, 2C ein Komma und 20 ein Leerzeichen. E4 B8 96 und E7 95 8C sind UTF-8-Sequenzen aus drei Bytes für 世 und 界 – die meisten chinesischen Schriftzeichen belegen in UTF-8 drei Bytes. Weil jede Sequenz wohlgeformt ist, liest die automatische Erkennung die Daten als UTF-8.
CE C2 B6 C8 3A 32 35 2E 33 A1 E6
温度:25.3℃
Viele serielle Geräte senden chinesischen Text in GBK. Hier ist CE C2 温 und B6 C8 度, 3A 32 35 2E 33 ist das ASCII :25.3, und A1 E6 ist das vollbreite ℃-Zeichen – zwei Bytes pro chinesischem Schriftzeichen oder Symbol. Als UTF-8 gelesen sind die Bytes ungültig (CE leitet eine Sequenz aus zwei Bytes ein, aber C2 ist kein Folgebyte); als GBK gelesen ergeben sie gängige Zeichen, daher wählt die automatische Erkennung GBK. Ein Konverter, der nur UTF-8 kennt, zeigt hier Ersatzzeichen.
00000000: 4869 20e4 bda0 e5a5 bd0d 0a Hi ........
Hi 你好␍␊
Genau das gibt printf 'Hi 你好\r\n' | xxd aus. Der Offset 00000000: und die Zeichenspalte rechts werden vor dem Dekodieren entfernt; würden sie als Daten gelesen, ergäben allein die acht Nullen vier NUL-Bytes am Anfang. Die letzten beiden Bytes, 0d 0a, sind ein Windows-Zeilenumbruch und werden als ␍␊ angezeigt.
[-28, -72, -83, -26, -106, -121]
中文
Arrays.toString(bytes) gibt Javas vorzeichenbehaftete Bytes dezimal aus. Negative Werte sind Bytes ab 0x80: -28 ist 256 − 28 = 228 = 0xE4. Die sechs Bytes E4 B8 AD E6 96 87 sind die UTF-8-Kodierung von 中文.
AT+CSQ\r\n
41 54 2B 43 53 51 0D 0A
Modems und die meisten UART-Befehlssätze erwarten, dass jedes Kommando mit Wagenrücklauf plus Zeilenvorschub endet. Ein Textfeld erzeugt bei Enter nur 0A; setzen Sie daher das Häkchen bei Zeilenumbrüche als CR LF, dann wird das Zeilenende zu 0D 0A.
653462646130653561356264
e4bda0e5a5bd → 你好
Jedes Byte hier ist eine ASCII-Hexziffer (65 ist e, 34 ist 4, 62 ist b), daher ergibt die erste Dekodierung wieder einen Hex-String. Das passiert, wenn ein Hex-String als Text behandelt und erneut umgewandelt wird. Die Seite bietet eine zweite Runde an, die 你好 ergibt. Um Fehlalarme zu vermeiden, bietet sie das nur an, wenn das erste Ergebnis mindestens 12 Hexziffern lang ist und die zweite Runde echten Text ergibt – Datumsangaben, Zeitstempel, CRC32-Werte und MD5-Hashes lösen sie nicht aus.
Fügen Sie die Daten im Tab „Hex → Text“ in das Feld ein, in welcher Form auch immer sie vorliegen: mit Leerzeichen, kompakt, als 0x-Werte, \x-Escapes, Byte-Array oder kompletter xxd-Bildschirm. Die Zeile unter dem Feld zeigt, wie sie gelesen wurden.
Der Text erscheint rechts, zusammen mit der automatisch erkannten Kodierung und dem Grund dafür. Liegt die Erkennung daneben, zeigt die Tabelle darunter jede Lesart; wählen Sie die richtige im Menü „Kodierung“.
Steuerbytes wie NUL, CR und LF werden als ␀ ␍ ␊ angezeigt. Entfernen Sie das Häkchen bei „Unsichtbare Zeichen anzeigen“, um den reinen Text zu sehen, und kopieren Sie dann das Ergebnis.
Wählen Sie im Tab „Text → Hex“ die Kodierung und ein Ausgabeformat – Hex mit Leerzeichen, 0x-Werte, ein C-, Java-, Python- oder Go-Array oder einen xxd-Dump. Setzen Sie für serielle und Netzwerkprotokolle das Häkchen bei CR LF.
Chinesischer Text aus älterer Windows-Software, vielen seriellen Geräten und Altdatenbanken ist GBK. Als UTF-8 dekodiert schlägt er entweder fehl, oder die Ausgabe füllt sich mit Ersatzzeichen. Sehen Sie in der Kodierungstabelle nach und nehmen Sie die Lesart, die Sinn ergibt.
>>> bytes.fromhex('c4e3bac3').decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc4 in position 0: invalid continuation byte >>> bytes.fromhex('c4e3bac3').decode('gbk')
'你好' charCodeAt() liefert eine UTF-16-Codeeinheit. Bei ASCII stimmt sie zufällig mit dem Byte überein, der Fehler zeigt sich also erst bei anderen Zeichen – und dann ist das Ergebnis nicht das, was irgendein UTF-8-System sendet.
'你'.charCodeAt(0).toString(16) // '4f60' — a UTF-16 code unit
Buffer.from('你', 'utf8').toString('hex') // 'e4bda0' — the UTF-8 bytes Javas byte ist vorzeichenbehaftet, Bytes ab 0x80 sind also negativ. Integer.toHexString() arbeitet mit einem int, gibt negative Werte als vorzeichenloses 32-Bit-Hex aus und lässt führende Nullen weg.
Integer.toHexString(b) // "ffffffe4" for 0xE4, "a" for 0x0A
String.format("%02x", b) // "e4", "0a" Buffer.from(hex, 'hex') wirft nie einen Fehler. Es bricht beim ersten Paar ab, das kein gültiges Hex ist, und ignoriert eine übrig gebliebene ungerade Ziffer – ein Tippfehler liefert also einen kürzeren Buffer statt einer Fehlermeldung.
Buffer.from('486', 'hex') // <Buffer 48> — the 6 is silently dropped
Buffer.from('48zz65', 'hex') // <Buffer 48> — stops at zz if (!/^([0-9a-f]{2})*$/i.test(hex)) throw new Error('invalid hex');
Buffer.from(hex, 'hex'); Ein Konverter, der nur Leerzeichen entfernt, liest den Offset 00000000: als Daten und die Zeichenspalte, wo es geht, als weiteres Hex. Das Ergebnis beginnt mit NUL-Bytes und verrutscht von da an. Verwenden Sie xxd -p für reines Hex, oder fügen Sie den Dump hier ein, wo die Spalten erkannt werden.
00000000: 4869 20e4 bda0 e5a5 bd0d 0a Hi ........ → read naively: 00 00 00 00 48 69 20 e4 …
$ printf 'Hi 你好\r\n' | xxd -p 486920e4bda0e5a5bd0d0a
AT-Modems und viele zeilenbasierte Protokolle schließen jedes Kommando mit Wagenrücklauf plus Zeilenvorschub ab. Ein Kommando, das nur auf 0A endet, wird oft ignoriert – ganz ohne Fehlermeldung.
41 54 2B 43 53 51 0A AT+CSQ followed by LF only
41 54 2B 43 53 51 0D 0A AT+CSQ followed by CR LF
0D 0A oder 00 am Ende zu erkennen – oder gehen Sie den umgekehrten Weg und bauen Sie ein Kommando mit CR-LF-Zeilenenden, das ein Gerät akzeptiert.b'...'-Literale und Node.js als <Buffer ...>. Fügen Sie das Log-Fragment unverändert ein, um den Text zu sehen – einschließlich der Frage, ob er in UTF-8 oder GBK vorlag.00 bis FF, und die Anzahl der Bytes ist immer die Hälfte der Ziffernanzahl. Groß- und Kleinschreibung bedeuten dasselbe. Trennzeichen, Präfixe und Array-Syntax sind nur Schreibweise: 4865, 48 65, 0x48, 0x65 und \x48\x65 sind dieselben zwei Bytes.00 bis 7F. Druckbare Zeichen reichen von 20 (Leerzeichen) bis 7E (~); der Rest sind Steuerzeichen, von denen 00 (NUL), 09 (Tabulator), 0A (Zeilenvorschub), 0D (Wagenrücklauf) und 1B (Escape) in echten Daten am häufigsten vorkommen. UTF-8, GBK und ISO-8859-1 behalten diese Werte alle bei, weshalb reiner englischer Text fast jede falsche Kodierung übersteht.C2–DF für zwei Bytes, E0–EF für drei, F0–F4 für vier –, und jedes folgende Byte muss im Bereich 80–BF liegen. Wegen dieser strengen Struktur ist ein GBK-Satz fast nie gültiges UTF-8 – in unserem Test mit 33.910 chinesischen Sätzen traf das auf 55 zu –, und deshalb vertraut die automatische Erkennung einer sauberen UTF-8-Dekodierung. Bei einem einzelnen chinesischen Schriftzeichen sieht es anders aus: Rund 18 % der GBK-Zeichen ergeben zufällig eine gültige UTF-8-Sequenz aus zwei Bytes.81 bis FE, gefolgt von einem zweiten Byte von 40 bis FE, ausgenommen 7F. Weil der Bereich des zweiten Bytes so groß ist, lässt sich kurzer UTF-8-Text als GBK oft ganz ohne Fehler dekodieren – nur eben zu Zeichen, die nichts damit zu tun haben: E4 BD A0 E5 A5 BD (你好) wird zu 浣犲ソ. Deshalb probiert diese Seite zuerst UTF-8. GB18030 erweitert GBK um Sequenzen aus vier Bytes für seltenere Zeichen; die Dekodierung hier akzeptiert sie.41 00 –, UTF-16BE das höherwertige – 00 41. Windows-APIs und viele Dateien verwenden Little-Endian und beginnen unter Umständen mit einer Byte-Order-Mark, FF FE; UTF-8-Dateien beginnen manchmal mit EF BB BF. Die automatische Erkennung entfernt eine Byte-Order-Mark und weist darauf hin.getBytes(), encode(), eine Einstellung im seriellen Terminal, der Zeichensatz einer Datenbankverbindung –, setzen Sie die Kodierung explizit und notieren sie neben dem Hex, damit die Gegenseite nicht raten muss.charCodeAt() oder Javas char-Werte, geben UTF-16-Codeeinheiten zurück, keine kodierten Bytes. Kodieren Sie den String zuerst mit TextEncoder, Buffer.from() oder getBytes(StandardCharsets.UTF_8) und formatieren Sie dann die Bytes.%02x oder etwas Gleichwertiges, nie einen bloßen Zahl-zu-Hex-Aufruf. a und 0a sehen im Log ähnlich aus, doch aneinandergehängte, nicht aufgefüllte Werte ergeben einen String ungerader Länge – oder schlimmer, einen, der zu anderen Bytes dekodiert.00 bis FF, 48656c6c6f besteht also aus den fünf Bytes 48, 65, 6C, 6C, 6F. Zweitens dekodieren Sie diese Bytes mit einer Zeichenkodierung. In ASCII und UTF-8 ist 48 H, 65 e, 6C l und 6F o – das ergibt Hello. Beim zweiten Schritt gehen die Ergebnisse auseinander: Bytes über 7F stehen in UTF-8, GBK und anderen Kodierungen für unterschiedliche Zeichen. Deshalb erkennt diese Seite die Kodierung und zeigt alle Lesarten nebeneinander. C4 E3 BA C3 ist 你好 in GBK, aber ungültiges UTF-8, und E4 BD A0 E5 A5 BD ist 你好 in UTF-8, ergibt als GBK gelesen aber 浣犲ソ. Sehen Sie sich die Kodierungstabelle unter dem Ergebnis an – die Zeile, die sinnvollen Text zeigt, ist die Kodierung, in der die Daten geschrieben wurden. Bei nur ein oder zwei Zeichen kann die automatische Erkennung das nicht immer entscheiden: D2 BB ist gültiges UTF-8 (һ) und zugleich GBK (一). Prüfen Sie dann die GBK-Zeile, die die Seite unter dem Ergebnis anzeigt. Zwei weitere Ursachen sollten Sie ausschließen: eine überzählige oder fehlende Hexziffer, die jedes folgende Byte um ein halbes Byte verschiebt, und einen eingefügten Hex-Dump, an dem noch die Offset-Spalte hängt. Liegt Ihnen statt Hex bereits Zeichensalat vor (etwa 浣犲ソ), fügen Sie den Text stattdessen in den Kodierungs-Konverter ein. E4 BD A0 E5 A5 BD für 你好 als 浣犲ソ. Oder der Text enthält Steuerbytes wie 00 oder 0D 0A, die als Kästchen oder Zeilenumbrüche erscheinen. Fügen Sie die Hex-Daten hier ein: Die Kodierungstabelle zeigt die UTF-8- und die GBK-Lesart nebeneinander, und Steuerbytes erscheinen als ␀ ␍ ␊. 00 bis 7F: Buchstaben, Ziffern, Satzzeichen und Steuerzeichen. UTF-8 ist so aufgebaut, dass genau diese Bytes dieselben Zeichen bedeuten, und verwendet für alles andere Bytefolgen ab 80 – 2 Bytes für lateinische Buchstaben mit diakritischen Zeichen, 3 für die meisten chinesischen, japanischen und koreanischen Zeichen, 4 für Emoji. Für reinen englischen Text liefern Hex zu ASCII und Hex zu UTF-8 daher identische Ergebnisse. Sie unterscheiden sich, sobald ein Byte 80 oder höher ist: Ein reiner ASCII-Konverter kann diese Bytes nicht als Zeichen darstellen, UTF-8 dagegen dekodiert sie in den gesamten Unicode-Zeichenvorrat. Wofür jedes Byte von 00 bis 7F steht, zeigt die ASCII-Tabelle. E4 BD A0. In GBK und GB2312 sind es 2 Bytes: 你 ist C4 E3. In UTF-16 belegen Zeichen der Basic Multilingual Plane 2 Bytes, und die Byte-Reihenfolge spielt eine Rolle: 你 ist 60 4F in UTF-16LE und 4F 60 in UTF-16BE. Seltene Zeichen außerhalb dieser Ebene belegen 4 Bytes in UTF-8, 4 in UTF-16 (ein Surrogatpaar) und 4 in GB18030. Wechseln Sie im Tab „Text → Hex“ die Kodierung, um die Byteanzahl für Ihren eigenen Text zu sehen. bytes.fromhex() und dekodieren Sie danach: bytes.fromhex('48656c6c6f').decode('utf-8') gibt 'Hello' zurück. fromhex akzeptiert Leerzeichen zwischen den Bytes, bytes.fromhex('48 65 6c 6c 6f') funktioniert also auch, ein 0x-Präfix lehnt es aber mit einem ValueError ab. GBK-Daten dekodieren Sie mit 'gbk': bytes.fromhex('c4e3bac3').decode('gbk') gibt '你好' zurück, während dieselben Bytes als UTF-8 dekodiert einen UnicodeDecodeError auslösen. Die Gegenrichtung ist '你好'.encode('utf-8').hex(), das 'e4bda0e5a5bd' zurückgibt; mit einem Trennzeichen wie .hex(' ') erhalten Sie eine durch Leerzeichen getrennte Ausgabe. Buffer.from('48656c6c6f', 'hex').toString('utf8') den Wert 'Hello' zurück. Vorsicht bei fehlerhafter Eingabe: Node wirft keinen Fehler – es bricht beim ersten ungültigen Paar ab und verwirft eine übrig gebliebene ungerade Ziffer stillschweigend, Buffer.from('486', 'hex') ist also ein Buffer mit einem Byte. Im Browser bauen Sie die Bytes selbst zusammen und verwenden TextDecoder, der auch GBK liest: new TextDecoder('gbk').decode(Uint8Array.from('c4e3bac3'.match(/../g), h => parseInt(h, 16))) gibt '你好' zurück. Verwenden Sie nicht charCodeAt(), um Bytes zu erhalten: '你'.charCodeAt(0).toString(16) ist '4f60', eine UTF-16-Codeeinheit, nicht die UTF-8-Bytes e4bda0. unsigned char-Puffer und schließen Sie ihn danach ab: for (size_t i = 0; i < n; i++) sscanf(hex + 2 * i, "%2hhx", &buf[i]); buf[n] = '\0';, wobei n gleich strlen(hex) / 2 ist. Ist hex auf 48656c6c6f2c20e4b896e7958c gesetzt, ergibt die Ausgabe von buf auf einem UTF-8-Terminal Hello, 世界. Für die Gegenrichtung geben Sie jedes Byte mit printf("%02X ", (unsigned char)s[i]) aus. Der Cast ist wichtig: Auf Plattformen, auf denen char vorzeichenbehaftet ist, würde ein Byte wie 0xE4 sonst vorzeichenerweitert und als FFFFFFE4 ausgegeben. In C++ hängen Sie jedes Paar mit s.push_back(static_cast<char>(std::stoi(hex.substr(i, 2), nullptr, 16))) an; mit demselben hex ergibt sich Hello, 世界. new String(HexFormat.of().parseHex(hex), StandardCharsets.UTF_8); für GBK-Daten verwenden Sie stattdessen Charset.forName("GBK"). In der Gegenrichtung sorgt klassischerweise ffffffe4 für Überraschung. Das liegt daran, dass Javas byte vorzeichenbehaftet ist und Integer.toHexString() einen int erwartet. Das Byte 0xE4 wird als -28 gespeichert; bei der Erweiterung zu int bleibt der Wert -28, und toHexString gibt negative Zahlen als vorzeichenlosen 32-Bit-Wert aus, ffffffe4. Dieselbe Methode lässt außerdem führende Nullen weg, 0x0A wird also zu a. Verwenden Sie String.format("%02x", b), das ein negatives Byte als vorzeichenlosen 8-Bit-Wert formatiert, oder Integer.toHexString(b & 0xff) mit Auffüllen. Ab Java 17 wandelt HexFormat.of().formatHex(bytes) ein ganzes Array um, und HexFormat.of().parseHex(hex) geht den Weg zurück. hex2bin() dekodiert einen Hex-String in einen Binärstring, bin2hex() geht den umgekehrten Weg: bin2hex('Hello') gibt 48656c6c6f zurück. Laut PHP-Handbuch gibt hex2bin() false zurück und löst eine E_WARNING aus, wenn die Eingabe eine ungerade Länge hat oder kein gültiges Hexadezimal ist. Entfernen Sie daher Leerzeichen und 0x-Präfixe vor dem Aufruf. PHP-Strings sind Bytes, das Ergebnis hat also die Kodierung, die der Originaltext hatte – wandeln Sie GBK-Ausgabe mit mb_convert_encoding() um, wenn Ihre Seite UTF-8 verwendet. xxd (auch mit -u, -c und -g), hexdump -C, Gos hex.Dump, od -A x -t x1 und GNU od -t x1z und expandiert die *-Zeile, die hexdump und od anstelle wiederholter Zeilen ausgeben. Sie kommt auch mit einfachem hexdump und od -x zurecht, die 16-Bit-Wörter statt Bytes ausgeben: Auf einer Little-Endian-Maschine erscheinen die Bytes 48 69 als 6948. Die Seite tauscht daher jedes Paar zurück und entfernt anhand des letzten Offsets das Füllbyte, das bei Daten ungerader Länge hinzukommt. Jede Variante von xxd, hexdump und od wurde mit 600 echten Dumps von Zufallsdaten getestet. a statt 0a), ein beim Kopieren abgeschnittenes Zeichen oder ein verirrter Buchstabe wie O anstelle von 0. Ein Hex-String, der entsteht, wenn man alle Bytes als eine einzige große Zahl umwandelt – etwa mit Pythons hex(int.from_bytes(data, 'big')) –, verliert die Null am Anfang: \r\n wird zu 0xd0a. Die Seite rät nicht, welche Ziffer fehlt, denn ein falscher Tipp verschiebt jedes folgende Byte um ein halbes Byte und erzeugt überzeugend wirkenden Unsinn. Stattdessen bietet sie zwei Korrekturen per Klick an – eine 0 vorne ergänzen oder die letzte Ziffer entfernen –, damit Sie die Ergebnisse vergleichen können. Einzeln mit Präfix geschriebene Werte wie 0x0 0xa sind kein Problem: Jeder wird als ganzes Byte gelesen. Kodierung & Formatierung
Die vollständige ASCII-Tabelle: 128 Zeichen in Dezimal, Hex, Oktal und Binär, dazu ein Konverter in beide Richtungen. Steuerzeichen mit Escape-Sequenzen, Caret-Notation und dem Ort, an dem sie Ihnen wirklich begegnen.
Kodierung & Formatierung
Base64 online kostenlos dekodieren und kodieren. Echtzeitkonvertierung mit voller UTF-8- und Emoji-Unterstützung. 100 % privat — läuft in Ihrem Browser. Keine Anmeldung nötig.
Kodierung & Formatierung
Eine Base64-Zeichenkette oder einen Data-URI im Browser zurück in ein Bild dekodieren. Vorschau, Abmessungen & MIME ablesen, dann als PNG, JPG, GIF, SVG herunterladen. Kein Upload.
Kodierung & Formatierung
CSV im Browser nach JSON konvertieren. RFC 4180, Typinferenz, Kopfzeile, Big-Int-sicher. 100 % privat, kein Upload.
Kodierung & Formatierung
Kaputten Text einfügen und den Originaltext zurückbekommen. Jede plausible Kodierungskette — UTF-8, GBK, Big5, Shift_JIS, EUC-KR, Windows-1252 — wird geprüft, bewertet und mit Kette angezeigt. Kostenlos, privat, im Browser.
Kodierung & Formatierung
Eine .env-Datei einfügen, sofort JSON erhalten. Datenbankpasswörter, API-Keys und Tokens verlassen nie deinen Browser — 100% privat, kein Upload.