แปลงข้อความและ hex _

การเข้ารหัส hex ทำงานอย่างไร

ทุกอักขระในหน้าเว็บถูกเก็บเป็นหนึ่งหรือหลายไบต์ การเข้ารหัส hex แปลงไบต์เหล่านั้นเป็นฐาน 16 สองอักขระต่อไบต์ ทำให้ byte stream อ่านได้โดยไม่ต้องใช้เครื่องมือพิเศษ

1. เข้ารหัสข้อความเป็นไบต์. โหมด UTF-8 ประมวลผลข้อมูลนำเข้าผ่าน new TextEncoder().encode(text) ซึ่งคืนค่า Uint8Array ของค่าไบต์ โหมด Latin-1 ใช้แปดบิตล่างของแต่ละ code unit ผ่าน charCodeAt(0) & 0xFF ซึ่งเป็นการแปลงที่ codec ISO-8859-1 รุ่นเก่าใช้
2. แสดงแต่ละไบต์เป็นสองหลัก hex. แต่ละไบต์แมปเป็นสองหลัก hex ผ่าน byte.toString(16).padStart(2, "0") ตัวสลับตัวพิมพ์เลือกตัวพิมพ์ใหญ่ (A-F) หรือเล็ก (a-f) สำหรับตัวอักษรในผลลัพธ์
3. ใช้การจัดกลุ่มและคำนำหน้า. การจัดกลุ่มแทรกตัวคั่นระหว่างไบต์: ช่องว่างเดียว ขีดกลาง หรือช่องว่างทุกสี่ไบต์ คำนำหน้า 0x สามารถเพิ่มครั้งเดียวต่อสตริงทั้งหมด (ไม่มีการจัดกลุ่ม) หรือต่อไบต์ (การจัดกลุ่มแบบช่องว่าง) ตรงกับรูปแบบที่ C arrays และ binary diff tools ต้องการ
4. ถอดรหัสในทิศทางกลับ. โหมด Hex → ข้อความ ลบช่องว่าง ขีดกลาง และคำนำหน้า 0x ทั้งหมดออกจากข้อมูลนำเข้า ตรวจสอบอักขระที่เหลือกับ /^[0-9a-fA-F]+$/ ปฏิเสธสตริงที่มีหลักจำนวนคี่ และสร้าง Uint8Array จากคู่ไบต์ที่ต่อเนื่องกัน โหมด UTF-8 ถอดรหัสอาร์เรย์นั้นด้วย new TextDecoder("utf-8", { fatal: true }); โหมด Latin-1 แมปแต่ละไบต์เป็น String.fromCharCode(b)
5. โหมดสดสำหรับการทำงานที่รวดเร็ว. โหมดสดเปิดอยู่โดยค่าเริ่มต้น ทุกการกดแป้นพิมพ์กำหนดเวลาการแปลงใหม่แบบ debounced 150 มิลลิวินาที ทำให้คุณสามารถวาง แก้ไข และดูแผงอีกแผงอัปเดตโดยไม่ต้องกดปุ่มแปลง

ทำไมจึงใช้ตัวแปลง hex

• ดีบัก binary protocol. รูปแบบสาย เช่น Modbus, DNP3 และ CoAP บรรจุ header ไว้ใน byte offset เฉพาะ การอ่าน frame ที่ดักจับไว้ในรูป hex แสดงแต่ละฟิลด์ได้ทันที และการแปลงไบต์เหล่านั้นกลับเป็น ASCII จะแสดง payload ข้อความธรรมดาที่อยู่ร่วมกับ binary framing
• ทำงานกับ embedded firmware. โพรบ JTAG และ SWD รายงานเนื้อหาหน่วยความจำเป็น hex การแปลงพื้นที่หน่วยความจำเป็น ASCII จะแสดงสตริงที่ฝังไว้ (เส้นทางไฟล์ ข้อความแสดงข้อผิดพลาด ลายเซ็นผู้ขาย) ที่มักระบุตำแหน่งใน firmware ที่คุณกำลังดูอยู่
• อ่าน packet capture. Wireshark และ tcpdump มี byte pane ที่พิมพ์แต่ละ packet เป็น hex ทางซ้ายและ ASCII ทางขวา การแปลงชิ้นส่วนที่นี่ให้คุณคัดลอก hex blob จาก bug report หรือ chat log และอ่านว่าไบต์นั้นบอกอะไรโดยไม่ต้องนำเข้าใหม่ใน capture tool
• Diff ระดับไบต์. การเปรียบเทียบไฟล์ไบนารีสองไฟล์มักเป็นการค้นหาว่าไบต์ไหนเปลี่ยนแปลง การแปลงทั้งสองฝั่งเป็น hex ด้วยการจัดกลุ่มที่สอดคล้องกันทำให้ diff เรียงกันในโปรแกรมแก้ไขข้อความ ซึ่ง diff tool ในตัวสามารถไฮไลต์ไบต์ที่เปลี่ยนแปลงได้

การประยุกต์ใช้ทั่วไป

การแปลง Hex ↔ ASCII ปรากฏในงาน reverse engineering ความปลอดภัย และ embedded ทุกครั้งที่ byte stream มากกว่าแค่ payload ข้อความ

• Reverse engineering: นำ hex dump จาก binary ที่ต้านทาน strings ออกมา เลือกช่วงที่ถอดรหัสเป็น ASCII ที่พิมพ์ได้ และใช้สตริงเหล่านั้นเป็นจุดยึดใน disassembly
• Network forensics: คัดลอก payload ของ packet เดียวออกจาก Wireshark เป็น hex วางที่นี่ และอ่านข้อความชั้น application โดยไม่ต้อง export การดักจับทั้งหมด
• การจัดการวัสดุ crypto: key, IV หรือ HMAC tag มักส่งมาเป็นสตริง hex การถอดรหัสกลับเป็นไบต์ยืนยันว่าความยาวตรงกับอัลกอริทึม (16 ไบต์สำหรับ AES-128, 32 สำหรับ AES-256) ก่อนนำไปใส่ใน config

ตัวอย่างที่ทำงานได้จริง

เลือก ข้อความ → Hex, UTF-8, ตัวพิมพ์เล็ก, การจัดกลุ่มเว้นวรรคทุกไบต์, คำนำหน้าปิด พิมพ์ Hi: ผลลัพธ์แสดง 48 69 เปิดคำนำหน้าและเปลี่ยนการจัดกลุ่มเป็นไม่มี ข้อมูลนำเข้าเดิมแสดงเป็น 0x4869 วางอีโมจิ 😀 เป็นข้อมูลนำเข้าและโหมด UTF-8 แสดง f0 9f 98 80 — สี่ไบต์สำหรับหนึ่ง code point ซึ่งเป็นเหตุที่อีโมจิมักเพิ่มขนาดการส่งข้อมูล เปลี่ยนเป็น Hex → ข้อความ และวาง 0x48-65-6C 6C 6F: parser ลบคำนำหน้า ขีดกลาง และช่องว่างออก และสร้าง Hello ขึ้นใหม่

FAQ

การเข้ารหัส hex คืออะไร?

การเข้ารหัส hex (หรือ hexadecimal encoding) เขียน byte stream ในฐาน 16 สองอักขระ ASCII ต่อไบต์ แต่ละหลัก hex ครอบคลุมสี่บิต ดังนั้นสองหลักครอบคลุมหนึ่งไบต์แปดบิต ตัวอักษรวิ่งจาก 0-9 จากนั้น A-F (หรือ a-f); ตัวพิมพ์เป็นเพียงตัวเลือกการแสดงผลและ decoder ยอมรับทั้งคู่ Hex เป็นวิธีมาตรฐานในการเขียนไบต์ดิบในสเปกโปรโตคอล เอาต์พุต debugger และ crypto key เพราะกะทัดรัดกว่าไบนารีสองเท่าและหลีกเลี่ยงปัญหาอักขระที่ไม่สามารถพิมพ์ได้ของไบต์ดิบในข้อความ

ทำไมอีโมจิของฉันจึงกลายเป็น 4 ไบต์ใน hex?

UTF-8 เป็นการเข้ารหัสแบบความยาวผันแปร อักขระ ASCII (U+0000 ถึง U+007F) ใช้หนึ่งไบต์ Latin-1 supplement ใช้สอง code point BMP ส่วนใหญ่ใช้สาม และอักขระที่สูงกว่า U+FFFF — รวมถึงอีโมจิส่วนใหญ่ — ใช้สี่ไบต์ หน้าหัวเราะ 😀 คือ U+1F600 และเข้ารหัสเป็น F0 9F 98 80 หากต้องการมุมมองไบต์ความกว้างคงที่ ให้เปลี่ยนเป็น Latin-1 — แต่ Latin-1 ครอบคลุมเฉพาะ 256 code point แรก ดังนั้นอักขระใด ๆ นอกช่วงนั้นไม่สามารถ round-trip ได้

รองรับ Latin-1 / ISO-8859-1 หรือไม่?

ใช่ เปลี่ยนตัวเลือกการเข้ารหัสข้อความเป็น Latin-1 (ISO-8859-1) การเข้ารหัสใช้แปดบิตล่างของแต่ละ JavaScript code unit (charCodeAt(0) & 0xFF) ซึ่งตรงกับการแมปแบบ single-byte เดิม การถอดรหัสใช้ String.fromCharCode(byte) สำหรับแต่ละไบต์ ใช้ Latin-1 เมื่อทำงานกับเอาต์พุตจากระบบ Windows-1252 รุ่นเก่าหรือระบบก่อน Unicode ที่แต่ละไบต์หมายถึงอักขระหนึ่งตัว

การแปลงทำในเบราว์เซอร์ของฉันหรือไม่?

ใช่ ตัวแปลงรัน TextEncoder, TextDecoder และ parser ขนาดเล็กเป็นหน้าแบบ static ไม่มีการอัปโหลด ไม่มีการเรียก API และไม่มีการวิเคราะห์ข้อมูลที่คุณวาง — เพียงแค่ metrics การโหลดหน้ามาตรฐานที่แชร์ทั่วไซต์ hex bytes เดียวกันที่คุณเห็นที่นี่คือสิ่งที่ Node script หรือ Lambda function จะสร้างขึ้นกับข้อมูลนำเข้าเดียวกัน

การแปลง Hex ↔ ASCII เป็นงานเล็ก ๆ ที่ผู้อ่าน binary protocol หรือ embedded firmware ทำหลายครั้งต่อวัน การทำในแท็บเบราว์เซอร์ด้วย native encoder เดียวกับที่ Node และ V8 มีอยู่แล้ว ทำให้งานรวดเร็วและ byte stream อยู่บนเครื่องของคุณ