§

Options

Režim
Seskupení hex
0x prefix
Velikost písmen
Kódování textu
§

Vstup

§

Výstup

Američtí incident respondéři pracující na případech ICS-CERT spoléhají na hex ↔ ASCII převod pokaždé, když vytáhnou packet capture do Wiresharku a prohlížejí bajtový panel Modbus nebo DNP3 rámce, protože protokolové hlavičky se čtou čistě v hex, zatímco payloady často skrývají ASCII text uvnitř binárního rámování. Britští NCSC CHECK assessoři auditující HMG IA Standard No.1 evidence packy přepínají mezi hex a ASCII při revizi kryptografického materiálu vyměněného s HSM, protože session klíče se dodávají jako hex řetězce, ale vendor-specific tag bajty vkládají prosté ASCII popisky. Embedded firmware inženýři na obou stranách Atlantiku čtou JTAG dumpy stejným způsobem a tento převodník zvládá stejný překlad bez opuštění záložky prohlížeče.

Jak funguje hex kódování

Každý znak na stránce je uložen jako jeden nebo více bajtů. Hex kódování přepisuje tyto bajty v základu 16, dva znaky na bajt, takže bajtový proud je čitelný bez speciálních nástrojů.

  1. Kódování textu na bajty. UTF-8 režim prohání vstup přes new TextEncoder().encode(text), který vrací Uint8Array bajtových hodnot. Latin-1 režim bere nízkých osm bitů každé kódové jednotky přes charCodeAt(0) & 0xFF, což je konverze, kterou provádějí legacy ISO-8859-1 kodeky.
  2. Vykreslení každého bajtu jako dvou hex číslic. Každý bajt se mapuje na dvě hex číslice přes byte.toString(16).padStart(2, "0"). Přepínač velikosti písmen vybírá velká (A-F) nebo malá (a-f) písmena na výstupních písmenech.
  3. Aplikace seskupení a prefixu. Seskupení vkládá oddělovač mezi bajty: jednu mezeru, pomlčku nebo mezeru každé čtyři bajty. 0x prefix může být připojen jednou k celému řetězci (žádné seskupení) nebo na bajt (seskupení mezerou), což odpovídá konvencím, které C pole a binární diff nástroje očekávají.
  4. Dekódování v opačném směru. Režim Hex → Text odstraňuje každou mezeru, pomlčku a 0x prefix ze vstupu, validuje zbývající znaky proti /^[0-9a-fA-F]+$/, odmítá řetězce liché délky a znovu sestavuje Uint8Array z po sobě jdoucích dvojic bajtů. UTF-8 režim dekóduje toto pole pomocí new TextDecoder("utf-8", { fatal: true }); Latin-1 režim mapuje každý bajt na String.fromCharCode(b).
  5. Živý režim pro rychlou iteraci. Živý režim je ve výchozím nastavení zapnutý. Každý stisk klávesy naplánuje debounced převod po 150 ms, takže můžete vkládat, upravovat a sledovat, jak se druhý panel aktualizuje bez klikání na tlačítko Převést.

Proč použít hex převodník

  • Ladění binárních protokolů. Drátové formáty jako Modbus, DNP3 a CoAP balí své hlavičky do specifických bajtových offsetů. Čtení zachyceného rámce jako hex ukazuje každé pole na první pohled a přepnutí stejných bajtů zpět na ASCII odhaluje jakýkoli plaintext payload vedle binárního rámování.
  • Práce s embedded firmware. JTAG a SWD sondy hlásí obsah paměti jako hex. Překlad oblasti paměti do ASCII odhaluje vložené řetězce (cesty k souborům, chybové zprávy, vendor podpisy), které často přesně určují, kde ve firmware se nacházíte.
  • Čtení packet capture. Wireshark a tcpdump oba dodávají bajtový panel, který tiskne každý packet jako hex nalevo a ASCII napravo. Převod úryvku zde vám umožní zkopírovat hex blob z hlášení chyby nebo chatovacího logu a přečíst, co bajty skutečně říkají, bez opětovného importu do nástroje pro zachytávání.
  • Bajtové dify. Porovnání dvou binárních souborů často spočívá ve zjištění, které bajty se změnily. Převod obou stran na hex s konzistentním seskupením způsobí, že diff zarovná v textovém editoru, kde vestavěný diff nástroj může zvýraznit změněné bajty.

Běžné aplikace

Hex ↔ ASCII převod se objevuje napříč reverzním inženýrstvím, bezpečností a embedded prací, kdykoli je bajtový proud víc než jen textový payload.

  • Reverzní inženýrství: vezměte hex dump z binary odolné vůči řetězcům, vyberte běhy, které se dekódují jako tisknutelné ASCII, a použijte tyto řetězce k ukotvení toho, kde v disassembleru jste.
  • Síťová forenzní analýza: zkopírujte payload jednoho packetu z Wiresharku jako hex, vložte jej sem a čtěte aplikační vrstvu textu bez exportu celého capture.
  • Práce s kryptografickým materiálem: klíč, IV nebo HMAC tag se často dodává jako hex řetězec. Dekódování zpět na bajty potvrzuje, že délka odpovídá algoritmu (16 bajtů pro AES-128, 32 pro AES-256) před zapojením do konfigurace.

Příklad

Zvolte Text → Hex, UTF-8, malá písmena, seskupení mezerou mezi bajty, prefix vypnutý. Napište Hi: výstup čte 48 69. Zapněte prefix a nastavte seskupení na Žádné a stejný vstup se zobrazí jako 0x4869. Vložte emoji 😀 jako vstup a UTF-8 režim zobrazí f0 9f 98 80 — čtyři bajty pro jeden kódový bod, což je důvod, proč emoji často nafukují velikost přenosu. Přepněte na Hex → Text a vložte 0x48-65-6C 6C 6F: parser odstraní prefix, pomlčky a mezery a znovu sestaví Hello.

FAQ

Co je hex kódování?

Hex kódování (nebo hexadecimální kódování) zapisuje bajtový proud v základu 16, dva ASCII znaky na bajt. Každá hex číslice pokrývá čtyři bity, takže dvě číslice pokrývají jeden osmibitový bajt. Abeceda je 0-9 a pak A-F (nebo a-f); velikost písmen je čistě prezentační volba a dekodéry akceptují obě. Hex je standardní způsob zápisu surových bajtů ve specifikacích protokolů, debugger výstupu a kryptografických klíčích, protože je dvakrát kompaktnější než binární a vyhýbá se problémům s netisknutelnými znaky surových bajtů v textu.

Proč se moje emoji stane 4 bajty v hex?

UTF-8 je proměnná délka kódování. ASCII znaky (U+0000 až U+007F) zabírají jeden bajt, Latin-1 doplňky dva, většina ostatních BMP kódových bodů tři a znaky nad U+FFFF — včetně většiny emoji — čtyři. Usmívající se obličej 😀 je U+1F600 a kóduje se jako F0 9F 98 80. Pokud potřebujete pevnou šířku bajtového pohledu, přepněte na Latin-1 — ale Latin-1 pokrývá pouze prvních 256 kódových bodů, takže jakýkoli znak mimo tento rozsah nemůže projít obousměrně.

Podporuje to Latin-1 / ISO-8859-1?

Ano. Přepněte možnost kódování textu na Latin-1 (ISO-8859-1). Kódování bere nízkých osm bitů každé JavaScriptové kódové jednotky (charCodeAt(0) & 0xFF), což odpovídá legacy jednobajtovému mapování. Dekódování používá String.fromCharCode(byte) pro každý bajt. Použijte Latin-1, když pracujete s výstupem ze starších Windows-1252 nebo předunicodeových systémů, kde každý bajt představuje přesně jeden znak.

Probíhá převod v mém prohlížeči?

Ano. Převodník spouští TextEncoder, TextDecoder a malý parser jako jedinou statickou stránku. Neexistuje žádné nahrávání, žádné API volání a žádná analytika toho, co vložíte — pouze standardní metriky načtení stránky sdílené napříč webem. Stejné hex bajty, které vidíte zde, jsou to, co by Node skript nebo Lambda funkce vytvořily proti stejnému vstupu.

Hex ↔ ASCII převod je malý úkol, který každý, kdo čte binární protokoly nebo embedded firmware, dělá několikrát denně. Dělat to v záložce prohlížeče, se stejnými nativními kodéry, které Node a V8 již dodávají, udržuje práci rychlou a bajtový proud na vašem počítači.