ตัวแปลงข้อความ ↔ ฐานสิบหก / ฐานสอง
เปลี่ยนข้อความเป็นไบต์ฐานสิบหก ฐานสอง หรือฐานสิบ และถอดกลับจากไบต์ดัมป์
เกี่ยวกับเครื่องมือนี้
ดูให้ชัดว่าข้อความของคุณประกอบด้วยไบต์อะไรบ้าง: เครื่องมือนี้เข้ารหัสข้อความเป็น UTF-8 แล้วแสดงเป็นค่าไบต์แบบฐานสิบหก ฐานสอง หรือฐานสิบ — พร้อมตัวคั่น ตัวพิมพ์ และคำนำหน้า 0x ตามที่คุณเลือก ส่วนตัวถอดรหัสทำทางกลับกันและผ่อนปรนโดยตั้งใจ: มันรับทั้งชุดที่ต่อกันยาว (48656c6c6f) คู่ที่เว้นวรรค สัญกรณ์คั่นด้วยทวิภาคแบบ MAC และลำดับ escape แบบ \x
เพราะการเข้ารหัสเป็น UTF-8 ระดับไบต์ อักขระหลายไบต์จึงถูกแสดงอย่างที่มันมีอยู่จริงในหน่วยความจำและบนสาย: é คือ c3 a9, 世 คือ e4 b8 96 และอิโมจิใช้สี่ไบต์ นั่นทำให้ที่นี่เป็นทางที่เร็วที่สุดในการดีบักการเข้ารหัสที่ไม่ตรงกัน ปริศนา BOM และปัญหา “ทำไมสตริงนี้ยาวกว่าที่ตาเห็น”
หากไบต์ที่ถอดออกมาไม่ใช่ UTF-8 ที่ถูกต้อง เครื่องมือจะบอกตรง ๆ แทนที่จะพิมพ์อักขระเละ — เป็นสัญญาณชัดเจนว่าคุณกำลังดูข้อมูลไบนารี ไม่ใช่ข้อความ
คำถามที่พบบ่อย
- ทำไมอักขระตัวเดียวกลายเป็นหลายไบต์?
- UTF-8 มีความกว้างไม่คงที่: ASCII ยังคงเป็นหนึ่งไบต์ ตัวอักษรยุโรปส่วนใหญ่ใช้สอง อักษรจีน-ญี่ปุ่น-เกาหลีใช้สาม อิโมจิใช้สี่ สิ่งที่คุณเห็นที่นี่คือลำดับไบต์ที่แน่นอนซึ่งระบบ UTF-8 ใด ๆ — ไฟล์ HTTP ฐานข้อมูล — จะเก็บไว้แทนข้อความของคุณ
- ตัวถอดรหัสรับรูปแบบข้อมูลเข้าแบบใดบ้าง?
- ฐานสิบหกทั้งแบบต่อกันยาว แบบคู่ที่เว้นวรรค แบบมีคำนำหน้า 0x หรือ \x หรือคั่นด้วยทวิภาค/ลูกน้ำ ฐานสองเป็นกลุ่มละ 8 บิตจะเว้นวรรคหรือไม่ก็ได้ และฐานสิบเป็นค่าไบต์ที่คั่นไว้ ตัวคั่นที่ปนกันและช่องว่างที่หลงมาจะถูกจัดการให้อัตโนมัติ
- ทำไมการถอดรหัสบอกว่าไบต์เหล่านี้ไม่ใช่ UTF-8 ที่ถูกต้อง?
- ลำดับไบต์ละเมิดกฎของ UTF-8 — เช่นมี ff โดด ๆ หรือมีไบต์ต่อเนื่องโดยไม่มีไบต์นำ ข้อมูลนั้นอาจเป็นไบนารี อาจอยู่ในการเข้ารหัสรุ่นเก่าอย่าง Latin-1 หรืออาจถูกตัดกลางอักขระ
- เหมือนกับ hex dump จาก xxd ไหม?
- ค่าไบต์เหมือนกันทุกประการ ส่วน xxd เพิ่มคอลัมน์ออฟเซตและคอลัมน์ ASCII เข้ามา ให้วางเฉพาะคอลัมน์ฐานสิบหกจาก dump ของ xxd ที่นี่ (โดยไม่ต้องเอาคอลัมน์ออฟเซตมา) แล้วมันจะถอดรหัสได้ปกติ