Mag-convert ng teksto at hex _

Paano gumagana ang hex encoding

Ang bawat character sa isang page ay nakaimbak bilang isa o higit pang byte. Ang hex encoding ay nagsusulat muli ng mga byte na iyon sa base 16, dalawang character bawat byte, para ang byte stream ay nababasa nang walang espesyal na tool.

1. I-encode ang teksto sa mga byte. Ang UTF-8 mode ay nagpapatakbo ng input sa pamamagitan ng new TextEncoder().encode(text), na nagbabalik ng Uint8Array ng mga byte value. Ang Latin-1 mode ay kumukuha ng mababang walong bit ng bawat code unit sa pamamagitan ng charCodeAt(0) & 0xFF, na siyang conversion na ginagawa ng mga legacy na ISO-8859-1 codec.
2. I-render ang bawat byte bilang dalawang hex digit. Ang bawat byte ay nami-map sa dalawang hex digit sa pamamagitan ng byte.toString(16).padStart(2, "0"). Pinipili ng case toggle ang uppercase (A-F) o lowercase (a-f) sa mga output letter.
3. Mag-apply ng grouping at prefix. Ang grouping ay naglalagay ng separator sa pagitan ng mga byte: isang espasyo, isang gitling, o espasyo tuwing apat na byte. Ang 0x prefix ay maaaring idagdag nang minsan sa buong string (None grouping) o bawat byte (Space grouping), na tumutugma sa mga convention na inaasahan ng mga C array at binary diff tool.
4. Mag-decode nang pabaligtad. Ang Hex → Text mode ay nagta-strip ng bawat espasyo, gitling, at 0x prefix mula sa input, nagva-validate ng mga natitirang character laban sa /^[0-9a-fA-F]+$/, tumutanggi sa mga odd-length na string, at muling nagtatayo ng Uint8Array mula sa magkakasunod na byte pair. Ang UTF-8 mode ay nagdi-decode ng array na iyon gamit ang new TextDecoder("utf-8", { fatal: true }); ang Latin-1 mode ay nami-map ang bawat byte sa String.fromCharCode(b).
5. Live mode para sa mabilis na pag-ulit. Naka-on ang live mode bilang default. Ang bawat keystroke ay nag-i-schedule ng 150 ms debounced na re-convert para maaari kang mag-paste, mag-edit, at manood ng update ng kabilang pane nang hindi nagpi-pindutin ng button na I-convert.

Bakit gamitin ang isang hex converter

• Pag-debug ng binary na protocol. Ang mga wire format tulad ng Modbus, DNP3, at CoAP ay nagba-pack ng kanilang mga header sa mga tiyak na byte offset. Ang pagbabasa ng isang captured na frame bilang hex ay nagpapakita ng bawat field sa isang tingin, at ang pag-flip ng parehong mga byte pabalik sa ASCII ay nagbubunyag ng anumang plaintext na payload na nakaupo kasabay ng binary framing.
• Pagtatrabaho sa embedded firmware. Ang mga JTAG at SWD probe ay nagre-report ng mga nilalaman ng memorya bilang hex. Ang pag-translate ng isang rehiyon ng memorya sa ASCII ay nagsasabi ng mga embedded na string (mga file path, error message, vendor signature) na madalas na nagtaturo kung saan ka naghahanap sa firmware.
• Pagbabasa ng mga packet capture. Ang Wireshark at tcpdump ay parehong nagsi-ship ng byte pane na nagpi-print ng bawat packet bilang hex sa kaliwa at ASCII sa kanan. Ang pag-convert ng isang snippet dito ay nagpapahintulot sa iyo na kopyahin ang isang hex blob mula sa isang bug report o chat log at basahin kung ano talaga ang sinasabi ng mga byte nang hindi muling ini-import ang mga ito sa isang capture tool.
• Mga byte-level na diff. Ang pagkukumpara ng dalawang binary file ay madalas na nagbabalik sa pag-spot kung aling mga byte ang nagbago. Ang pag-convert ng parehong panig sa hex na may konsistenteng grouping ay nagpapaayon ng diff sa isang text editor, kung saan ang isang built-in na diff tool ay maaaring mag-highlight ng mga nabagong byte.

Mga karaniwang paggamit

Ang Hex ↔ ASCII conversion ay lumalabas sa buong reverse engineering, seguridad, at embedded na trabaho sa tuwing ang isang byte stream ay higit pa sa isang text payload.

• Reverse engineering: kumuha ng hex dump mula sa isang strings-resistant na binary, pumili ng mga run na nag-de-decode bilang printable ASCII, at gamitin ang mga string na iyon para ma-anchor kung nasaan ka sa disassembly.
• Network forensics: kopyahin ang isang packet payload mula sa Wireshark bilang hex, i-paste dito, at basahin ang application-layer na teksto nang hindi ini-export ang buong capture.
• Paghawak ng crypto material: ang isang key, IV, o HMAC tag ay madalas na nagsi-ship bilang isang hex string. Ang pag-decode pabalik sa mga byte ay nagkukumpirma na ang haba ay tumutugma sa algorithm (16 byte para sa AES-128, 32 para sa AES-256) bago mo i-wire ito sa isang config.

Isang halimbawang trabaho

Pumili ng Text → Hex, UTF-8, lowercase, Space-every-byte grouping, prefix off. Mag-type ng Hi: ang output ay nagbabasa ng 48 69. I-switch ang prefix sa on at ang grouping sa None at ang parehong input ay nagre-render bilang 0x4869. Mag-paste ng emoji na 😀 bilang input at ang UTF-8 mode ay nagre-render ng f0 9f 98 80 — apat na byte para sa isang code point, kaya ang mga emoji ay madalas na nagpapalaki ng transmission size. Lumipat sa Hex → Text at i-paste ang 0x48-65-6C 6C 6F: tinatanggal ng parser ang prefix, ang mga gitling, at ang mga espasyo at muling tinatayo ang Hello.

FAQ

Ano ang hex encoding?

Ang hex encoding (o hexadecimal encoding) ay nagsusulat ng isang byte stream sa base 16, dalawang ASCII character bawat byte. Ang bawat hex digit ay sumasaklaw ng apat na bit, kaya ang dalawang digit ay sumasaklaw ng isang walong-bit na byte. Ang alpabeto ay nagtatakbo ng 0-9 pagkatapos ay A-F (o a-f); ang case ay purong presentasyon at tinatanggap ng mga decoder ang alinman. Ang hex ang pamantayang paraan ng pagsulat ng raw na byte sa mga protocol spec, debugger output, at crypto key dahil ito ay dalawang beses na mas compact kaysa sa binary at iniiwasan ang mga problema ng unprintable character ng raw na byte sa teksto.

Bakit nagiging 4 byte ang aking emoji sa hex?

Ang UTF-8 ay isang variable-length encoding. Ang mga ASCII character (U+0000 hanggang U+007F) ay isang byte, ang mga Latin-1 supplement ay dalawa, karamihan sa ibang BMP code point ay tatlo, at ang mga character na nasa itaas ng U+FFFF — kasama na ang karamihang emoji — ay apat. Ang nakangiting mukha na 😀 ay U+1F600 at nag-e-encode sa F0 9F 98 80. Kung kailangan mo ng fixed-width na byte view, lumipat sa Latin-1 — ngunit ang Latin-1 ay sumasaklaw lamang sa unang 256 code point, kaya ang anumang character na wala sa saklaw na iyon ay hindi maaaring mag-round-trip.

Sinusuportahan ba nito ang Latin-1 / ISO-8859-1?

Oo. I-switch ang Text encoding na opsyon sa Latin-1 (ISO-8859-1). Ang pag-encode ay kumukuha ng mababang walong bit ng bawat JavaScript code unit (charCodeAt(0) & 0xFF), na tumutugma sa legacy single-byte na mapping. Ang pag-decode ay gumagamit ng String.fromCharCode(byte) para sa bawat byte. Gumamit ng Latin-1 kapag nagtatrabaho ka sa output mula sa mas lumang Windows-1252 o pre-Unicode na system kung saan ang bawat byte ay kumakatawan sa eksaktong isang character.

Ginagawa ba ang conversion sa iyong browser?

Oo. Nagpapatakbo ang converter ng TextEncoder, TextDecoder, at isang maliit na parser bilang isang single static na page. Walang upload, walang API call, at walang analytics sa kung ano ang ini-paste mo — ang mga karaniwang page-load metric lamang na ibinabahagi sa buong site. Ang parehong hex byte na nakikita mo dito ay ang gagawin ng isang Node script o Lambda function laban sa parehong input.

Ang Hex ↔ ASCII conversion ay isang maliit na trabaho na ginagawa ng sinumang nagbabasa ng binary na protocol o embedded firmware nang ilang beses sa isang araw. Ang paggawa nito sa isang browser tab, gamit ang parehong native encoder na isinasama na ng Node at V8, ay nagpapanatiling mabilis ang trabaho at nasa iyong machine ang byte stream.