เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · URL ตัวเข้ารหัสและตัวถอดรหัส
สิ่งที่ URL Constructor เข้ารหัสสำหรับคุณ: ชุดการเข้ารหัสเปอร์เซ็นต์ของเบราว์เซอร์
· มันทำงานอย่างไร
การเข้ารหัส URL javascript อะไรนะ เว็บ API
URL API เข้ารหัสเปอร์เซ็นต์อักขระบางตัวอย่างเงียบๆ และปล่อยให้อักขระอื่นๆ อยู่ตามลำพัง ขึ้นอยู่กับว่าส่วนใดของ URL อักขระเหล่านั้นเข้ามา โพสต์นี้จะอธิบายชุดการเข้ารหัส WHATWG และวิธีการคาดการณ์ผลลัพธ์
ช่องว่างที่กลายเป็น %20 และ | ที่ยังคงอยู่ - กรณีที่เป็นรูปธรรมซึ่ง new URL() เข้ารหัสเส้นทางบางส่วน
เมื่อ URL("https://example.com/hello world") ใหม่ทำงาน พื้นที่จะกลายเป็น %20 แบบเงียบๆ แต่ URL("https://example.com/hello|world") ใหม่ ปล่อยให้ไปป์ไม่ถูกแตะต้อง ความแตกต่างนี้ไม่ใช่แบบสุ่ม WHATWG URL มาตรฐานกำหนดชุดอักขระแยกกันเพื่อเข้ารหัสสำหรับแต่ละองค์ประกอบ URL: เส้นทาง แบบสอบถาม ส่วนย่อย และข้อมูลผู้ใช้ ต่างก็มีกฎของตัวเอง การทำความเข้าใจชุดเหล่านี้หมายถึงการทำนายว่าตัวสร้างจะทำอะไร
พื้นที่จำเป็นต้องมีการเข้ารหัสเปอร์เซ็นต์เนื่องจากไม่ปลอดภัยเหนือ HTTP และทำให้ความสามารถในการอ่านพัง ไปป์แตกต่างออกไป: ไม่ใช่อักขระสงวนที่แยกโครงสร้าง ดังนั้นเบราว์เซอร์จึงปล่อยไว้ตามลำพัง เส้นแบ่งระหว่างความปลอดภัยและความสามารถในการอ่านถูกกำหนดโดย WHATWG ไม่ใช่การคาดเดา การทดสอบ "hello world" แสดงการเข้ารหัส การทดสอบ "hello|world" เผยให้เห็นขอบเขตของแต่ละ URL ส่วน
URL หนึ่งชุด ชุดเข้ารหัสหลายชุด - เส้นทาง การสืบค้น ส่วนย่อย และข้อมูลผู้ใช้ แต่ละชุดมีรายการอักขระของตัวเองที่จะหลีก
URL หนึ่งรายการประกอบด้วยหลายภูมิภาค โดยแต่ละภูมิภาคมีกฎการเข้ารหัสของตัวเอง เส้นทางเป็นไปตามชุดหนึ่ง สอบถามอีกชุด ส่วนที่สาม ข้อมูลผู้ใช้ที่สี่ ช่องว่างจะกลายเป็น %20 ในเส้นทางและการสืบค้น เครื่องหมายเท่ากับยังคงอยู่ในแบบสอบถาม โดยจะแยกคีย์และค่า แต่ encodeURIComponent จะเปลี่ยนเป็น %3D ตัวสร้าง URL รู้บริบทและใช้กฎที่ถูกต้องสำหรับแต่ละส่วน
ชุดการเข้ารหัสมีความแม่นยำและมีขนาดเล็ก Path มีรายชื่อตัวละครเป็นของตัวเอง แบบสอบถามมีรายการที่คล้ายกันแต่แตกต่างกัน สิ่งนี้สะท้อนให้เห็นว่าตัวละครตัวใดมีความหมายเชิงโครงสร้าง เครื่องหมายทับแยกส่วนของเส้นทาง ดังนั้น encodeURIComponent จึงเข้ารหัสเป็น %2F ในส่วนนั้น เครื่องหมายทับสามารถมีอยู่ได้โดยไม่ทำให้สิ่งใดเสียหาย การทำความเข้าใจกฎ WHATWG หมายถึงการคาดการณ์เอาต์พุตโดยไม่ต้องรันโค้ด
เหตุใดการเข้ารหัสเปอร์เซ็นต์จึงเป็นแบบทางเดียว: สิ่งที่ยังคงเข้ารหัสอยู่ก็ยังคงเป็นเช่นนั้น
ตัวสร้าง URL ดำเนินการทำให้เป็นมาตรฐานทางเดียว ส่ง "%20" ไปยัง URL ใหม่ และจะสร้าง %20 ไม่เปลี่ยนแปลง ตัวสร้างรับรู้ว่ามีการเข้ารหัสแล้วและปล่อยไว้ตามลำพัง นี่คือเหตุผลว่าทำไมการเข้ารหัสสองครั้งจึงมีความสำคัญ: เข้ารหัสครั้งเดียว ส่งผ่าน Constructor และแท่งเข้ารหัส ตัวสร้างไม่ถอดรหัส ตีความใหม่ และเข้ารหัสใหม่ มันอ่านไปข้างหน้า
คุณสมบัติทางเดียวนี้ส่งผลต่อแอปพลิเคชันที่เชื่อถือ URL.href เป็นแบบบัญญัติ หากคุณเชื่อมอินพุตของผู้ใช้เข้ากับพาธของคุณ อินพุตจะถูกทำให้เป็นมาตรฐานแต่ไม่ได้ถอดรหัส ค่าเช่น "my+file" จะยังคงเหมือนเดิม หรือกลายเป็น "my%2Bfile" ในบางบริบท โค้ดภายหลังที่ใช้ decodeURIComponent อาจอ่านเครื่องหมายบวกเป็นช่องว่างหากมาจากข้อมูลในแบบฟอร์ม ตัวสร้างจะทำให้เป็นมาตรฐานหนึ่งครั้ง หลังจากนั้นค่าของคุณจะถูกคงที่
ตัวอย่างการทำงาน: ส่งสตริงที่ยุ่งวุ่นวายเดียวกันผ่าน new URL() และการอ่าน href ชื่อพาธ และ searchParams - มุมมองที่แตกต่างกันสามมุมมอง
ใช้ "hello world&foo=bar|test#anchor" แล้วใส่ลงใน URL ใหม่ที่มีส่วนประกอบต่างกัน พื้นที่กลายเป็น %20 ทุกที่ เครื่องหมายแอมเปอร์แซนด์ในเส้นทางยังคงอยู่ (ไม่มีความหมายเชิงโครงสร้าง) แต่ในการสืบค้นก็จะยังคงอยู่เช่นกัน (แยกพารามิเตอร์ ดังนั้นการทำให้เป็นมาตรฐานจะสูญเสียขอบเขตระหว่าง "q=" และ "foo=bar") ไปป์และแฮชมีพฤติกรรมแตกต่างกันตามตำแหน่ง
การอ่าน href ชื่อพาธ และ searchParams จะแสดงมุมมองที่แตกต่างกันสามมุมมอง ชื่อพาธแสดงพาธที่เข้ารหัสโดยไม่มีรูปแบบ โฮสต์ หรือคิวรี searchParams ให้พารามิเตอร์ที่ถอดรหัส ดังนั้น "hello+world" จากข้อมูลแบบฟอร์มจึงกลายเป็นช่องว่าง คุณสมบัติการค้นหาจะรักษาสตริงตามตัวอักษร href แสดง URL ที่ทำให้เป็นมาตรฐานโดยสมบูรณ์ สิ่งเหล่านี้อยู่ร่วมกันบนวัตถุเดียว ที่จะใช้ขึ้นอยู่กับขั้นตอนต่อไปของคุณ
URLSearchParams และกฎการเข้ารหัสแบบฟอร์ม — เหตุใดจึงสร้าง + สำหรับช่องว่างในขณะที่ชื่อพาธสร้าง %20
URLSearchParams ใช้การเข้ารหัสแบบฟอร์ม: ช่องว่างจะกลายเป็นเครื่องหมายบวก ไม่ใช่ %20 URLSearchParams ใหม่ ({q: "hello world"}) สร้าง "q=hello+world" ไม่ใช่ "q=hello%20world" นี่คือกฎ application/x-www-form-urlencoded ในอดีต แต่ถ้าคุณส่งสตริงนี้เป็นแบบสอบถามดิบไปยัง URL ใหม่ เครื่องหมายบวกจะยังคงเป็นเครื่องหมายบวก มีเพียง URLSearchParams เท่านั้นที่ถอดรหัสเป็นช่องว่าง คอนสตรัคเตอร์มีความซื่อสัตย์ต่อสิ่งที่เห็น
ความแตกต่างของเครื่องหมายบวกนี้ทำให้เกิดข้อบกพร่องทั่วไป URL จากแถบที่อยู่ใช้ %20 สำหรับการเว้นวรรค ข้อมูลแบบฟอร์มใช้เครื่องหมายบวก หากคุณถอดรหัสด้วย decodeURIComponent (ซึ่งอ่านว่าบวกตามตัวอักษร) แทนที่จะเป็น URLSearchParams.get การเว้นวรรคจะกลายเป็นอักขระบวก ตัวเข้ารหัสและตัวถอดรหัส URL แสดงทั้งสองอย่าง: วาง "hello+world" และเปรียบเทียบโหมดส่วนประกอบและรูปแบบเพื่อดูว่ามีช่องว่างปรากฏที่ใด
เปรียบเทียบกับ encodeURI — ทั้งสองตกลงกันและต่างกันตรงไหน
ตัวสร้าง URL และ encodeURIComponent เป็นเครื่องมือที่แตกต่างกัน encodeURIComponent เข้ารหัสเกือบทุกอย่าง ยกเว้นตัวอักษร ตัวเลข และ - _ ที่ไม่ได้สงวนไว้ ! ~ * ' ( ) มันถือว่าไม่มีบริบท ตัวสร้าง URL แยกวิเคราะห์ URL จริง และใช้กฎ WHATWG ต่อส่วนประกอบ encodeURIComponent เปลี่ยน "hello/world" เป็น "hello%2Fworld"; ใหม่ URL เห็นเครื่องหมายทับเป็นตัวแยกเส้นทาง อินพุตเดียวกัน เอาต์พุตต่างกัน
ใช้ encodeURIComponent เมื่อสร้าง URL โดยการต่อชิ้นส่วนต่างๆ ใช้ URLSearchParams หรือตัวสร้าง URL สำหรับ URL ที่สมบูรณ์หรือบางส่วน อย่าใช้ encodeURIComponent กับ URL ทั้งหมด; คุณจะทำลายโครงการนี้ เปรียบเทียบผลลัพธ์ด้วยความตั้งใจ เบราว์เซอร์บังคับใช้ความคิดเห็นเกี่ยวกับโครงสร้าง URL และ URL ใหม่นำไปใช้ ตัวเข้ารหัสและตัวถอดรหัส URL แสดงมุมมองทั้งสองแบบเคียงข้างกัน
สิ่งนี้ไม่ครอบคลุมถึง - การแยกวิเคราะห์โฮสต์, IDNA และรูปแบบพิเศษและแบบไม่พิเศษ
WHATWG URL มาตรฐานคือที่มาของความจริง แม้ว่าการอ่านจะต้องใช้ความอดทนก็ตาม ชุดการเข้ารหัสถูกกำหนดไว้ในส่วนของอัลกอริทึม ไม่ใช่รายการธรรมดา ในทางปฏิบัติ การทำความเข้าใจหลักการมีความสำคัญมากกว่าการท่องจำชุด เส้นทางอนุญาตให้มีอักขระมากขึ้น (เครื่องหมายสแลชมีโครงสร้าง) แบบสอบถามมีกฎของตัวเอง แฟรกเมนต์มีข้อ จำกัด น้อยที่สุด (จัดการฝั่งไคลเอ็นต์ ไม่เคยส่งไปยังเซิร์ฟเวอร์) แต่ละองค์ประกอบมีกฎของตัวเอง การรู้สิ่งนี้จะบอกคุณว่าจะดูที่ไหน
การทำให้เป็นมาตรฐานและการตรวจสอบเป็นขอบเขตที่แตกต่างกัน ตัวสร้างทำให้เป็นมาตรฐาน: ทำความสะอาดการเข้ารหัสเปอร์เซ็นต์ ใช้กฎส่วนประกอบ ให้รูปแบบมาตรฐาน ไม่ตรวจสอบความถูกต้อง: การโยนอักขระที่ไม่ถูกต้อง แต่ยอมรับโฮสต์ที่ว่างเปล่า ตัวสร้างเข้มงวดเกี่ยวกับรูปแบบแต่ผ่อนปรนในการตีความ เพื่อให้เป็นไปตามข้อกำหนดเฉพาะ โปรดอ่านส่วนไบต์ที่เข้ารหัสเป็นเปอร์เซ็นต์ของ WHATWG สำหรับการสร้างในแต่ละวัน ให้ใช้ URLSearchParams, URL API และตัวอย่างจริง
ประเด็นสำคัญ: parser มีความคิดเห็น — วิธีที่ตัวเข้ารหัสและตัวถอดรหัส URL แสดงให้คุณเห็นการเข้ารหัสเปอร์เซ็นต์แบบธรรมดาของค่าหรือที่อยู่ เพื่อให้คุณสามารถเปรียบเทียบกับสิ่งที่เบราว์เซอร์สร้างขึ้น
คุณลักษณะ WHATWG ที่ไม่สนับสนุนที่นี่รวมการแยกวิเคราะห์โฮสต์ด้วยการแปลง IDNA (ชื่อโดเมนระหว่างประเทศเป็น ASCII) และการจัดการรูปแบบพิเศษและไม่ใช่พิเศษ ไฟล์: URL ใช้สิทธิ์แบบ double-slash; ข้อมูล: URL ไม่ได้ ตัวสร้างบังคับใช้กฎเหล่านี้ การแปลงชื่อโฮสต์และการกำหนดสถานะพิเศษเป็นของการอ่านข้อมูลจำเพาะ ไม่ใช่การเข้ารหัสเปอร์เซ็นต์ สิ่งนี้สำคัญเมื่อสร้าง URL ในรูปแบบต่างๆ
ทดสอบโครงสร้าง URL ของคุณโดยเปรียบเทียบการตีความของเบราว์เซอร์กับความคาดหวัง สร้างด้วย URL ใหม่ อ่านคุณสมบัติที่สำคัญ: href สำหรับแบบฟอร์มที่สมบูรณ์ ชื่อพาธสำหรับพาธ ค้นหาคำค้นหาดิบ ค้นหาพารามิเตอร์สำหรับการถอดรหัส หากเอาต์พุตทำให้คุณประหลาดใจ ให้วางลงใน URL encoder & decoder และปฏิบัติตามการเปลี่ยนแปลงทีละขั้นตอน เครื่องมือจะแสดงเอาต์พุตที่ทำให้เป็นมาตรฐานควบคู่ไปกับการเข้ารหัสแบบ Raw ซึ่งเผยให้เห็นถึงความแตกต่าง การทำความเข้าใจชุด WHATWG หมายถึงการทำความเข้าใจตัวเลือกเบราว์เซอร์และวิธีการใช้งาน