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ů.
- Kódování textu na bajty. UTF-8 režim prohání vstup přes
new TextEncoder().encode(text), který vracíUint8Arraybajtových hodnot. Latin-1 režim bere nízkých osm bitů každé kódové jednotky přescharCodeAt(0) & 0xFF, což je konverze, kterou provádějí legacy ISO-8859-1 kodeky. - 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. - 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í.
- Dekódování v opačném směru. Režim Hex → Text odstraňuje každou mezeru, pomlčku a
0xprefix ze vstupu, validuje zbývající znaky proti/^[0-9a-fA-F]+$/, odmítá řetězce liché délky a znovu sestavujeUint8Arrayz 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 naString.fromCharCode(b). - Ž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.