เข้ารหัส/ถอดรหัส URL

รองรับการเข้ารหัสและถอดรหัสเปอร์เซ็นต์ URL การจัดการอักขระพิเศษ ช่องว่าง และข้อความหลายภาษา ตรวจจับรูปแบบการเข้ารหัสโดยอัตโนมัติ รองรับการประมวลผลพารามิเตอร์คิวรี เหมาะสำหรับการเรียก API การส่งแบบฟอร์ม และการแชร์ลิงก์

วิธีใช้งาน

🚀 เริ่มต้นอย่างรวดเร็ว

กรอกเนื้อหาด้านบน
คลิก เข้ารหัส หรือ ถอดรหัส เพื่อสลับโหมด
คลิกปุ่มเพื่อเริ่มประมวลผล ผลลัพธ์จะแสดงในกล่องข้อความเดียวกัน
ใช้ปุ่มคัดลอกด้านล่างเพื่อคัดลอกผลลัพธ์

📌 สถานการณ์การใช้งานทั่วไป

พารามิเตอร์ API: เข้ารหัสพารามิเตอร์ query และเนื้อหา request เพื่อให้ส่งอักขระพิเศษได้ถูกต้อง
ฟอร์ม: รองรับข้อมูล GET/POST รวมถึงตัวอักษร CJK และสัญลักษณ์พิเศษ
ลิงก์แบ่งปัน: สร้าง URL ที่มีตัวอักษร CJK/อักขระพิเศษได้โดยไม่เพี้ยน
คำค้นหา: เข้ารหัสคำค้นโดยเฉพาะเมื่อมี & = # ? ปะปน

🧭 คำแนะนำการใช้งาน

ควรหลีกเลี่ยงการเข้ารหัสซ้ำ: ตรวจสอบก่อนว่ามีลำดับ %XX อยู่แล้วหรือไม่
เข้ารหัสเฉพาะบางส่วน: เข้ารหัสเฉพาะค่าพารามิเตอร์ โดยคงโครงสร้าง URL เดิม
การดีบัก: ถอดรหัสพารามิเตอร์ในคำขอเครือข่ายเพื่อตรวจหาปัญหาได้เร็วขึ้น
อักขระสงวน: : / ? # [ ] @ ! $ & ' ( ) * + , ; = มีความหมายพิเศษ เมื่อใช้เป็นข้อมูลมักต้องเข้ารหัส (ขึ้นอยู่กับบริบท โดยเฉพาะ : / ? # & = +)
การเข้ารหัสอักขระ: อักขระที่ไม่ใช่ ASCII จะถูกเข้ารหัสเป็นไบต์ UTF‑8 1–4 ไบต์ แล้วเขียนเป็น %HH ต่อไบต์

⚠️ ข้อจำกัดและความเข้ากันได้

การเข้ารหัส URL ≠ การเข้ารหัสลับ: เป็นเพียงการแปลงรูปแบบที่ย้อนกลับได้ ไม่ได้ปกป้องข้อมูลลับ
ความยาว URL: โดยทั่วไปควรไม่เกิน 2048 ตัวอักษร (ขึ้นกับเบราว์เซอร์/เซิร์ฟเวอร์)
ช่องว่าง: ใน query string อาจใช้ + (ในฟอร์ม) หรือ %20 (ทั่วไป); เครื่องมือนี้ใช้ %20 เป็นค่าเริ่มต้น
ข้อความยาวมากอาจทำให้เบราว์เซอร์หน่วงหรือค้าง ควรแบ่งประมวลผลเป็นส่วน ๆ

🔒 ความเป็นส่วนตัวและความปลอดภัย

การประมวลผลทั้งหมดเกิดขึ้นในเบราว์เซอร์ของคุณ ข้อมูลจะไม่ออกจากอุปกรณ์
ข้อมูลสำคัญ (รหัสผ่าน คีย์ โทเคน) ควรถูกเข้ารหัส ไม่ใช่แค่เข้ารหัส URL

❓ คำถามที่พบบ่อย

URL คืออะไร และทำไมต้อง “เข้ารหัส”?

URL ถูกเสนอโดย Tim Berners‑Lee ในช่วงต้นยุคเว็บ เพื่อใช้สตริงที่มนุษย์อ่านได้อธิบาย scheme/host/path/query/fragment เพื่อหลีกเลี่ยงไม่ให้ตัวอักษรข้อมูลถูกตีความเป็นตัวแบ่ง (เช่น ? & # = /) และเพื่อรองรับช่องว่าง ข้อความที่ไม่ใช่ ASCII และอีโมจิ จึงต้องแปลงอักขระเหล่านั้นเป็น percent-encoding รูปแบบ %HH ในบริบท application/x‑www‑form‑urlencoded ช่องว่างอาจเขียนเป็น “+” ได้ (นอกฟอร์มทั่วไปแนะนำให้ใช้ %20) การเข้ารหัส URL เป็นเพียงการแปลงรูปแบบแบบย้อนกลับได้เพื่อให้ลิงก์คงทน ไม่ใช่กลไกการเข้ารหัสเพื่อความลับ

การเข้ารหัส URL ปกป้องข้อมูลสำคัญได้หรือไม่?

ไม่ได้ การเข้ารหัส URL เป็นการแปลงรูปแบบที่ย้อนกลับได้ รหัสผ่าน คีย์ API และความลับอื่น ๆ ต้องถูกเข้ารหัสด้วยวิธีที่ปลอดภัยกว่า

ทำไมบางครั้งช่องว่างเป็น + และบางครั้งเป็น %20?

สำหรับฟอร์ม จะใช้ + ในขณะที่ตาม RFC 3986 ทั่วไปใช้ %20 เครื่องมือนี้ใช้ %20 เป็นค่าเริ่มต้นเพื่อความเข้ากันได้ หากต้องใช้ + ให้ใช้ในบริบทฟอร์มหรือแปลงเองภายหลัง

จะรู้ได้อย่างไรว่าเนื้อหาถูกเข้ารหัสมาแล้ว?

เนื้อหาที่เข้ารหัสแล้วมักมีลำดับ %XX หากเห็นลักษณะนี้จำนวนมากแสดงว่าเข้ารหัสแล้ว ควรหลีกเลี่ยงการเข้ารหัสซ้ำ

ทำไมต้องเข้ารหัสอักขระที่ไม่ใช่ ASCII?

มาตรฐาน URL อนุญาตเฉพาะ ASCII เท่านั้น ข้อความที่ไม่ใช่ ASCII (เช่น ตัวมีวรรณยุกต์ อีโมจิ) ต้องถูกแปลงเป็น percent-encoding เพื่อส่งผ่านได้อย่างปลอดภัย

สแลช / จำเป็นต้องเข้ารหัสหรือไม่?

ขึ้นอยู่กับตำแหน่ง: หากเป็นตัวแบ่ง path ไม่ควรเข้ารหัส แต่หากอยู่ในค่าพารามิเตอร์ควรเข้ารหัสเป็น %2F