เข้ารหัส / ถอดรหัส URL
เข้ารหัสแบบเปอร์เซ็นต์หรือถอดรหัสส่วนประกอบของ URL และ query string
เกี่ยวกับเครื่องมือนี้
อักขระอย่างช่องว่าง เครื่องหมาย & และตัวอักษรที่ไม่ใช่ ASCII ปรากฏดิบ ๆ ใน URL ไม่ได้ จึงต้องเข้ารหัสแบบเปอร์เซ็นต์: ช่องว่างกลายเป็น %20 และ 你 กลายเป็น %E4%BD%A0 เครื่องมือนี้เข้ารหัสข้อความให้ใส่ใน URL ได้อย่างปลอดภัย และถอดรหัสสตริงที่ถูก escape ด้วยเปอร์เซ็นต์กลับเป็นข้อความที่อ่านได้ รวมถึงธรรมเนียมการใช้ + แทนช่องว่างในสตริงคิวรี
มีโหมดเข้ารหัสสองแบบเพราะ JavaScript เองก็มีสองแบบ: โหมดคอมโพเนนต์ (encodeURIComponent) เข้ารหัสทุกอย่างที่อาจตัดแบ่ง URL ซึ่งเป็นสิ่งที่คุณต้องการสำหรับค่าเดี่ยวในสตริงคิวรี ส่วนโหมด URI เต็ม (encodeURI) รักษาอักขระเชิงโครงสร้างอย่าง /, ? และ & ไว้ สำหรับตอนที่คุณเข้ารหัส URL ทั้งชุดที่ยังต้องใช้เดินทางได้
การถอดรหัสเข้มงวดกับลำดับ % ที่ผิดรูป — % โดด ๆ หรือ %ZZ จะถูกรายงานเป็นข้อผิดพลาดแทนที่จะปล่อยผ่านเงียบ ๆ ซึ่งตรงกับที่เบราว์เซอร์และเซิร์ฟเวอร์จะปฏิบัติต่อมัน
คำถามที่พบบ่อย
- ควรใช้โหมดคอมโพเนนต์กับโหมด URI เต็มเมื่อใด?
- ถ้าเข้ารหัสค่าที่จะไปอยู่ภายใน URL (คำค้น ปลายทางของการเปลี่ยนเส้นทาง อีเมลในพารามิเตอร์) → ใช้โหมดคอมโพเนนต์ เพื่อไม่ให้ & และ = ในค่านั้นทำสตริงคิวรีพัง ส่วนถ้าเข้ารหัส URL ทั้งชุดเพื่อแสดงหรือส่งต่อ → ใช้โหมด URI เต็ม เพื่อให้โครงสร้าง URL รอด
- ทำไมบางครั้ง + จึงหมายถึงช่องว่าง?
- รูปแบบ application/x-www-form-urlencoded — ที่ใช้ในการส่งฟอร์ม HTML และสตริงคิวรี — เข้ารหัสช่องว่างเป็น + มาแต่ไหนแต่ไร ส่วนในเส้นทางของ URL นั้น + ก็คือเครื่องหมายบวกธรรมดา ตัวถอดรหัสที่นี่ถือว่า + คือช่องว่าง ตามความหมายของสตริงคิวรี ขณะที่ %20 ใช้ได้ทุกที่เสมอ
- ทำไมสตริงของฉันถูกเข้ารหัสซ้อน (%2520)?
- %25 คือรหัสของ % เอง ดังนั้น %2520 หมายความว่าข้อความ %20 ถูกเข้ารหัสอีกครั้ง เหตุนี้เกิดเมื่อระบบสองชั้นต่างก็เข้ารหัส ให้กดถอดรหัสสองครั้งที่นี่เพื่อคลี่ออก แล้วไปแก้ชั้นที่ไม่ควรเข้ารหัส
- อักขระยูนิโค้ดถูกจัดการอย่างถูกต้องหรือไม่?
- ถูกต้อง — ข้อความถูกเข้ารหัสเป็น UTF-8 ก่อน แล้วแต่ละไบต์จึงถูก escape แบบเปอร์เซ็นต์ ตามมาตรฐาน URL ของ WHATWG นั่นคือเหตุผลที่อักษรจีน-ญี่ปุ่น-เกาหลีหนึ่งตัวกลายเป็นกลุ่ม %XX สามกลุ่ม