เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · URL ตัวเข้ารหัสและตัวถอดรหัส
encodeURI กับ encodeURIComponent: อักขระตัวไหนที่แต่ละตัวทิ้งไว้ตามลำพัง
· มันทำงานอย่างไร
การเข้ารหัส URL javascript นักพัฒนาเวิร์กโฟลว์
ฟังก์ชัน JavaScript ทั้งสองมีความแตกต่างกันด้วยอักขระ 11 ตัวพอดี และการเลือกฟังก์ชันที่ไม่ถูกต้องจะทำให้ URL แตกหรือไม่สามารถหลีกค่าได้ โพสต์นี้จะอธิบายฉากต่างๆ และให้กฎเกณฑ์ที่คุณจำได้
การค้นหาที่ส่งคืนทุกสิ่งเนื่องจากการ & ใน 'R&D' แยกการค้นหา - จุดบกพร่องที่เป็นรูปธรรมจากฟังก์ชันที่ไม่ถูกต้อง
การค้นหา R&D อาจส่งคืนผลลัพธ์สำหรับ R โดยไม่ได้ตั้งใจหากโค้ดสร้าง ?q=R&D ด้วยมือ เครื่องหมายและเป็นตัวคั่นระหว่างพารามิเตอร์การสืบค้น จะไม่ถูกรักษาไว้เป็นส่วนหนึ่งของ q เว้นแต่คุณจะเข้ารหัสค่า การเลือก encodeURI สำหรับส่วนเล็กๆ นั้นถือเป็นข้อผิดพลาด ไม่ใช่ข้อผิดพลาดของเซิร์ฟเวอร์ ตัวเลือกที่ปลอดภัยที่สุดในโค้ดของแอปพลิเคชันมักจะเป็น URLSearchParams แต่การทำความเข้าใจ JavaScript พื้นฐานทั้งสองจะทำให้โค้ดที่มีอยู่แก้ไขได้ง่ายขึ้นมาก
สิ่งที่ทั้งสองฟังก์ชันใช้ร่วมกัน - ชุดที่ไม่ได้สงวนไว้ซึ่งไม่เคยแตะต้องและใช้การเข้ารหัส UTF-8 เปอร์เซ็นต์ที่ทั้งคู่ใช้
ทั้งสองวิธีปล่อยให้ ASCII ตัวอักษร ตัวเลข และเครื่องหมายวรรคตอนแบบไม่สงวนไว้ - _ ! ~ * ' ( ) ไม่ถูกแตะต้องภายใต้กฎการเข้ารหัสของ JavaScript พวกเขาแปลงอักขระที่ไม่ใช่ ASCII เป็น UTF-8 ไบต์ก่อนที่จะเขียนเปอร์เซ็นต์ triplets: é กลายเป็น %C3%A9 ไม่ใช่ละติน-1 byte ตัวเดียว นอกจากนี้ยังเข้ารหัสช่องว่างเป็น %20 การเข้ารหัสเปอร์เซ็นต์เป็นเรื่องเกี่ยวกับการรักษาโครงสร้างของ URI; ไม่ใช่การหลบหนี HTML การตรวจสอบอินพุต หรือการป้องกันสคริปต์ที่เป็นอันตรายในหน้าการรับ
อักขระสิบเอ็ดตัวเท่านั้น encodeURI ที่เก็บรักษาไว้ — ; , / ? : @ & = + $ # และเหตุใดแต่ละคำจึงมีความหมายเชิงโครงสร้างใน URL
encodeURI ยังรักษาอักขระโครงสร้างสิบเอ็ดตัวที่ encodeURIComponent เข้ารหัส: ; , / ? : @ & = + $ # หากต้องการที่อยู่ที่สมบูรณ์ การเว้นเครื่องหมายทับและเครื่องหมายคำถามไว้เพียงอย่างเดียวจะคงเส้นทางและไวยากรณ์การสืบค้นไว้ สำหรับค่าเคียวรี การปล่อยให้ & หรือ = ผ่านจะเปลี่ยนรายการพารามิเตอร์ ในขณะที่ # ที่ไม่ใช้ Escape สามารถเริ่มต้นแฟรกเมนต์ได้ ฟังก์ชันต่างๆ แตกต่างกันอย่างชัดเจน เนื่องจากฟังก์ชันหนึ่งมีไว้สำหรับที่อยู่ทั้งหมด และอีกฟังก์ชันหนึ่งสำหรับส่วนประกอบภายในที่อยู่นั้น
กฎที่ถือ: ค่าต่างๆ รับ encodeURIComponent, URL ที่สมบูรณ์จะได้รับ encodeURI — และเหตุใด 'สมบูรณ์ URL' จึงหายากกว่าที่คิด
ค่าต่างๆ มักจะได้รับ encodeURIComponent ที่อยู่ที่ครบถ้วนและมีโครงสร้างแล้วเป็นกรณีที่พบได้น้อยกว่าสำหรับ encodeURI สำหรับ URL ที่คุณกำลังสร้างโดยทางโปรแกรม ให้ใช้ URL API เพื่อจัดการพาธและพารามิเตอร์การค้นหา แทนที่จะเชื่อมส่วนที่เข้ารหัสและดิบเข้าด้วยกัน อย่าเข้ารหัส URL ทั้งหมดด้วย encodeURIComponent จากนั้นคาดว่าเครื่องหมายทับและเครื่องหมายโคลอนจะทำงานเป็นตัวคั่นต่อไป ในทางกลับกัน อย่าป้อนคำค้นหาของผู้ใช้ผ่าน encodeURI และปล่อยให้เครื่องหมายแอมเพอร์แซนด์ทำงานอยู่
ตัวอย่างการทำงาน: สตริงเดียวกันผ่านทั้งสองฟังก์ชัน - ตารางเอาต์พุตสำหรับค่าที่มีช่องว่าง &, / และสำเนียง
นำ R&D / cafe เป็นค่าการค้นหาเดียว encodeURIComponent ส่งคืน R%26D%20%2F%20caf%C3%A9 ปกป้องเครื่องหมายแอมเพอร์แซนด์และสแลช encodeURI ส่งคืน R&D%20/%20caf%C3%A9, รักษาเครื่องหมายวรรคตอนที่มีโครงสร้าง คำนำหน้าไร้เดียงสา ?q= จะสร้างตัวคั่นที่ไม่ได้ตั้งใจ ทั้งเข้ารหัสพื้นที่และสำเนียง ดังนั้นการทดสอบโดยใช้เพียง "สวัสดีชาวโลก" จึงพลาดความแตกต่างที่สำคัญ เปรียบเทียบสตริงที่สร้างขึ้นใน ToolAcre จากนั้นวางลงในตัวแยกวิเคราะห์ URL และตรวจสอบว่ามีพารามิเตอร์การค้นหาปรากฏจำนวนเท่าใด
ข้อผิดพลาดทั่วไป — เข้ารหัส URL แบบเต็มด้วย encodeURIComponent และถอดรหัสด้วยคู่ที่ไม่ถูกต้อง
การเข้ารหัส URL แบบเต็มเนื่องจากองค์ประกอบหนึ่งสร้าง %3A%2F%2F โดยที่ผู้บริโภคคาดหวัง ://. การถอดรหัสที่อยู่ทั้งหมดก่อนที่จะตรวจสอบความถูกต้องสามารถรื้อฟื้นตัวคั่นที่สงวนไว้อีกครั้งด้วยความหมายใหม่ นอกจากนี้ หลีกเลี่ยงการเข้ารหัสซ้ำค่าที่มี %26 อยู่แล้ว: เครื่องหมายเปอร์เซ็นต์สามารถกลายเป็น %25 ได้ ดังนั้นชั้นถอดรหัสที่สองอาจเปลี่ยนความหมายอีกครั้ง จับคู่ encodeURIComponent กับ decodeURIComponent สำหรับส่วนประกอบและถือว่าเปอร์เซ็นต์ Escape ที่มีรูปแบบไม่ถูกต้องเป็นข้อผิดพลาดอินพุต
สิ่งนี้ไม่ครอบคลุมถึง — การเข้ารหัสแบบฟอร์มด้วย + และการสร้าง URL ด้วย URLSearchParams
HTML การเข้ารหัสแบบสอบถามแบบฟอร์มใช้เครื่องหมายบวกสำหรับช่องว่างใน application/x-www-form-urlencoded, ซึ่งแตกต่างจากเอาต์พุต %20 ของทั้งสองฟังก์ชันนี้ URLSearchParams จัดการกฎแบบฟอร์มเหล่านั้นให้กับคุณ บทความนี้ไม่ครอบคลุมถึงการทำให้เส้นทางเป็นมาตรฐาน การแปลงชื่อโฮสต์ Unicode หรือการตัดสินใจว่า URL ที่ถอดรหัสแล้วนั้นปลอดภัยที่จะขอหรือไม่ การเข้ารหัส URL เป็นขั้นตอนการเป็นตัวแทน ไม่ใช่นโยบายการให้สิทธิ์
ประเด็นสำคัญ: เข้ารหัสส่วนต่างๆ ไม่ใช่ทั้งหมด - วิธีที่ตัวเข้ารหัสและตัวถอดรหัส URL แสดงทั้งสองโหมดเพื่อให้คุณเห็นความแตกต่างในอินพุตของคุณเอง
ขอบเขตที่น่าจดจำคือส่วนหนึ่งเทียบกับทั้งหมด: ค่าพารามิเตอร์คือส่วนหนึ่ง ดังนั้นให้ใช้ encodeURIComponent หรือ URLSearchParams URL ตัวเข้ารหัสและตัวถอดรหัสแสดงทั้งสองฟังก์ชันของเบราว์เซอร์สำหรับสตริงเดียวกันและเก็บการทดสอบไว้ในเครื่อง ทดสอบอินพุตที่มี &, =, #, เครื่องหมายทับ และเครื่องหมายเน้นเสียง ก่อนที่จะตัดสินใจว่าตัวเข้ารหัสสองตัวสามารถใช้แทนกันได้