เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · URL ตัวเข้ารหัสและตัวถอดรหัส
RFC 3986 อักขระที่สงวนและไม่สงวน: สิ่งที่มาตรฐาน URI กล่าว
· พื้นหลัง
การเข้ารหัส URL rfc3986 การเข้ารหัสเปอร์เซ็นต์
RFC 3986 แบ่งอักขระออกเป็นแบบสงวน ไม่สงวน และอย่างอื่นทั้งหมด และการแยกดังกล่าวจะอธิบายกฎการเข้ารหัสเปอร์เซ็นต์ทุกข้อที่คุณพบ โพสต์นี้อ่านส่วนที่เกี่ยวข้องอย่างชัดเจน
RFC 3986 อักขระที่สงวนและไม่สงวน—สิ่งสำคัญเมื่อคุณสร้าง URL
RFC 3986 แบ่งอักขระออกเป็นสามประเภท: ไม่สงวน สงวนไว้ และสิ่งอื่นๆ ที่ต้องเข้ารหัส อักขระที่ไม่ได้สงวนไว้ไม่จำเป็นต้องเข้ารหัส ได้แก่ ตัวอักษร ตัวเลข ขีดกลาง จุด ขีดล่าง และเครื่องหมายทิลเดอ RFC แสดงรายการเหล่านี้อย่างชัดเจนในส่วน 2.3 โดยระบุว่าปลอดภัยที่จะปล่อยให้ไม่มีการเข้ารหัสในบริบท URI ใดๆ การทดสอบใน URL ตัวเข้ารหัสและตัวถอดรหัสด้วยอักขระเหล่านี้แสดงว่าอักขระเหล่านี้ผ่านโดยไม่มีการเปลี่ยนแปลง อักขระที่สงวนไว้แบ่งย่อยเป็น gen-delims (: / ? # [ ] @) และ sub-delims (! $ & ' ( ) * + , ; =) แต่ละตัวมีความหมายเชิงโครงสร้างในส่วนประกอบ URL ที่แตกต่างกัน
อักขระจำเป็นต้องเข้ารหัสเมื่อใด อักขระที่สงวนไว้จะต้องเข้ารหัสเป็นเปอร์เซ็นต์เฉพาะในกรณีที่สร้างความคลุมเครือเท่านั้น เครื่องหมายทับแบ่งส่วนของเส้นทาง ในค่าแบบสอบถามจะต้องเป็น %2F เครื่องหมายและแยกพารามิเตอร์ & ในค่าที่ต้องการ %26 อักขระที่ไม่ได้สงวนไว้ไม่จำเป็นต้องเข้ารหัส เครื่องหมายยัติภังค์ยังคงเป็นยัติภังค์ มาตรฐาน URL ช่วยให้มั่นใจได้ว่าการแยกวิเคราะห์ถูกต้อง การทดสอบด้วยตัวเข้ารหัสและตัวถอดรหัส URL: การป้อน "hello/world" ด้วย encodeURIComponent จะสร้าง "hello%2Fworld"; ด้วย encodeURI จะรักษาเครื่องหมายสแลชไว้
ไม่ได้สงวนไว้: ตัวอักษร ตัวเลข ยัติภังค์ จุด ขีดล่าง และเครื่องหมายทิลเด — อักขระที่ไม่ต้องเข้ารหัสและไม่ควรเข้ารหัส
การเข้ารหัสเปอร์เซ็นต์ใช้ %HH โดยที่ HH เป็นรูปแบบเลขฐานสิบหก ASCII ตัวอักษร A (รหัส 65) กลายเป็น %41 Non-ASCII é ต้องการการเข้ารหัส UTF-8: é (U+00E9) กลายเป็น %C3%A9 มาตรฐานสมัยใหม่ระบุ UTF-8 เหมือนกันในเบราว์เซอร์ต่างๆ
URL ที่สมบูรณ์ต้องมีไวยากรณ์โครงสร้างครบถ้วน ค่าการสืบค้นจำเป็นต้องมีอักขระที่สงวนไว้ภายในซึ่งไม่เป็นอันตราย พารามิเตอร์การค้นหา ?q=R&D ควรเข้ารหัส & เป็น %26 หากเป็นแบบแมนนวล ไม่เช่นนั้นเครื่องหมายและจะกลายเป็นตัวคั่น ค่าที่มีเครื่องหมายทับจะกลายเป็น %2F ในโหมดคอมโพเนนต์ การเข้ารหัสส่วนประกอบ (encodeURIComponent) จัดการสิ่งนี้โดยการเข้ารหัสทุกอย่าง ยกเว้นตัวอักษรที่ไม่ได้สงวนไว้ ตัวเลข และ - _ ! ~ * ' ( ) การทดสอบแสดงให้เห็นความแตกต่างระหว่างวิธีการต่างๆ อย่างชัดเจน
สงวนไว้: gen-delims และ sub-delims - ทั้งสองกลุ่ม สมาชิกและบทบาทเชิงโครงสร้างของพวกเขา
สตริงการสืบค้นแสดงให้เห็นว่าเหตุใดอักขระที่สงวนไว้จึงมีความสำคัญ เครื่องหมายและแยกคู่คีย์=ค่า: ?utm_source=email&utm_campaign=sale หมายถึงพารามิเตอร์ 2 ตัว ภายในค่า เครื่องหมายแอมเปอร์แซนด์ที่ไม่ใช้ Escape จะสิ้นสุดคู่ เท่ากับแยกคีย์ออกจากค่า การแยกวิเคราะห์เกิดขึ้นที่หลายเลเยอร์ แต่ละคนใช้กฎเดียวกัน
อักขระที่ต้องเข้ารหัสในค่าการสืบค้น ได้แก่ เครื่องหมายและ เท่ากับ แฮช เครื่องหมายคำถาม ช่องว่าง และตัวอักษรที่ไม่ใช่ ASCII แฮชนั้นเป็นความลับที่สุด: #anything จะกลายเป็นตัวระบุส่วน และไม่เคยส่งไปยังเซิร์ฟเวอร์ ชื่อแคมเปญที่ลงท้ายด้วยแฮชจะสูญเสียทุกอย่างหลังจากนั้นก่อนที่คำขอจะออกจากเบราว์เซอร์ ช่องว่างจะต้องกลายเป็น %20 การทดสอบด้วยตัวเข้ารหัสและตัวถอดรหัส URL แสดงโหมดส่วนประกอบและรูปแบบ การทำความเข้าใจตำแหน่งจะกำหนดความจำเป็นในการเข้ารหัส
เมื่อต้องเข้ารหัสอักขระที่สงวนไว้ — เฉพาะในกรณีที่อักขระเหล่านั้นถูกเข้าใจผิดว่าเป็นตัวคั่น ส่วนประกอบต่อส่วนประกอบ
เปอร์เซ็นต์การเข้ารหัสยังคงอยู่ใน RFC 3986 ชุดที่ไม่ได้สงวนไว้มีขนาดเล็กเพื่อให้พกพาได้ อักขระที่ไม่ได้เข้ารหัสที่เข้ารหัสเป็นเปอร์เซ็นต์สามารถถอดรหัสได้โดยไม่มีการเปลี่ยนแปลงความหมาย การถอดรหัส %41 เป็น A นั้นถูกต้อง เนื่องจาก A ไม่ได้ถูกสงวนไว้ การถอดรหัส %2F เป็น / เปลี่ยนความหมายเมื่อเครื่องหมายสแลชเป็นข้อมูล ไม่ใช่ตัวคั่น RFC 3986 ส่วนการทำให้เป็นมาตรฐาน 6 ครอบคลุมแนวทางทางวากยสัมพันธ์
ตัวละครที่สงวนไว้ในตำแหน่งที่แตกต่างกันจะมีบทบาทที่แตกต่างกัน เครื่องหมายทวิภาคในเครื่องหมายโครงการ:ขอบเขตอำนาจ; โคลอนใน userinfo คือข้อมูล เครื่องหมายคำถามเปิดส่วนแบบสอบถาม เครื่องหมายทับในค่าการค้นหาเป็นตัวอักษร แฮชทำเครื่องหมายการเริ่มต้นส่วน ตำแหน่งกำหนดความต้องการการเข้ารหัส สตริงการสืบค้นมีค่าที่เป็น URI ของตัวเอง การเข้ารหัสการเปลี่ยนเส้นทาง URL เช่น https://example.com/page?param=value เนื่องจากพารามิเตอร์จำเป็นต้องมีการเข้ารหัสเครื่องหมายทับและโคลอนเป็น %2F และ %3A บริบทจะกำหนดอักขระที่ปลอดภัยเสมอ
ตัวอย่างการทำงาน: การจัดประเภทอักขระทุกตัวของ URL จริงทุกตัว — ไม่สงวน, สงวนไว้เป็นตัวคั่น, สงวนไว้เป็นข้อมูล
RFC 1738 (1994) ถือว่าอักขระหลายตัวไม่ปลอดภัย เนื่องจากการปรับใช้เป็นมาตรฐานบน UTF-8 มาตรฐานต่อมาจึงผ่อนคลายข้อจำกัด ตัวหนอน (~) เป็นแบบอย่างของการวิวัฒนาการ: RFC 1738 จำเป็น %7E, RFC 2396 (1998) ย้ายตัวหนอนไปที่ไม่ได้สงวนไว้, RFC 3986 ยืนยันสถานะที่ไม่ได้สงวนไว้ วิวัฒนาการสะท้อนถึงบทเรียนการใช้งาน มาตรฐานรักษาความเข้ากันได้แบบย้อนหลัง
RFC การทำให้เป็นมาตรฐานอนุญาตให้ถอดรหัสอักขระที่ไม่ได้เข้ารหัสที่เข้ารหัสเปอร์เซ็นต์โดยไม่จำเป็น %41 ปรับมาตรฐานอย่างปลอดภัยเป็น A. อักขระสงวนที่เข้ารหัสเช่น %2F ไม่เคยถอดรหัส; การเปลี่ยนแปลงความหมายทำให้โครงสร้างแตกสลาย ฉันทามติสมัยใหม่ใช้ RFC 3986 เป็นข้อมูลพื้นฐานในการอ้างอิง URL ตัวเข้ารหัสและตัวถอดรหัสจะติดตาม RFC 3986 ตลอด โดยเสนอการอ้างอิงคงที่แยกจากพฤติกรรมของเบราว์เซอร์ WHATWG URL มาตรฐานเพิ่มชุดการเข้ารหัสเฉพาะส่วนประกอบนอกเหนือจาก RFC มาตรฐานอยู่ร่วมกัน: RFC 3986 สำหรับการแยกวิเคราะห์ URL ทั่วไป WHATWG สำหรับเว็บเบราว์เซอร์ ห้องสมุดแตกต่างกัน ตรวจสอบเอกสาร
คำแนะนำการทำให้เป็นมาตรฐานในส่วน 6 — ตัวพิมพ์ฐานสิบหก, การถอดรหัสที่ไม่ได้สงวนไว้ และกฎส่วนของเส้นทาง
การทดสอบกับ RFC 3986 ช่วยให้มั่นใจได้ว่า URL จะทำงานกับซอฟต์แวร์ที่ครอบคลุมหลายทศวรรษ URL ตัวเข้ารหัสและตัวถอดรหัสให้ RFC 3986 พื้นฐานการเข้ารหัสเพื่อนำไปใช้กับส่วนประกอบที่สร้างขึ้น อ่านเอกสารมาตรฐานที่อธิบายการตัดสินใจเข้ารหัสทุกครั้งในไลบรารี URL WHATWG URL สร้างจาก RFC 3986 แทนที่จะแทนที่ทั้งหมด กำลังสร้าง URL สำหรับเบราว์เซอร์ทั่วไปใช่ไหม ติดตาม RFC 3986; เบราว์เซอร์ใช้กฎ WHATWG ด้านบน ระบบเก่า? ทดสอบการใช้งานจริง กำลังทำให้การจัดเก็บเป็นมาตรฐาน? ใช้ RFC 3986 อย่างสม่ำเสมอ การทำความเข้าใจความแตกต่างที่สงวนไว้/unreservedจะบอกคุณถึงอักขระที่ปลอดภัย
การเข้ารหัส URL ไม่ใช่การรักษาความปลอดภัย แต่ละบริบท—SQL, HTML, JavaScript, URI—จำเป็นต้องมีการเข้ารหัสเอาต์พุตของตัวเอง การเข้ารหัสเปอร์เซ็นต์ปกป้องโครงสร้าง URL เท่านั้น ใช้การป้องกันที่ถูกต้องที่ชั้นด้านขวา
สิ่งนี้ไม่ครอบคลุม — ชุดการเข้ารหัสที่แตกต่างกันของ WHATWG URL มาตรฐานและการจัดการ IRI
RFC 2396 (1998) ชุดอักขระที่ชัดเจนยิ่งขึ้นเข้มงวดกว่า RFC 1738 มันทำให้อักขระที่สงวนไว้อย่างเป็นทางการซึ่งให้บริการโครงสร้าง URI และไม่สงวนไว้เป็นข้อมูลตามตัวอักษร ขยายแบบไม่สงวนไว้ รวมถึงยัติภังค์ จุด ขีดล่าง เครื่องหมายตัวหนอนเหนือคำจำกัดความดั้งเดิม RFC 2396 แนะนำความแตกต่างระหว่าง gen-delims (:, /, ?, #, [, ], @) และ sub-delims ( !, $, &, ', (, ), *, +, ,, ;, =) แต่ละกลุ่มมีบทบาทเชิงโครงสร้างที่แตกต่างกันใน URL การตั้งชื่อชี้แจงอักขระที่สงวนไว้แบ่งออกเป็นสองกลุ่ม การรู้ชื่อจะช่วยในการอภิปรายทางเทคนิค
RFC 3986 (2005) เป็นข้อมูลอ้างอิงสมัยใหม่ มันยังคงรักษาความแตกต่างที่สงวนไว้/unreservedแต่ใช้สัญลักษณ์ที่เรียบง่าย หน่วยงานมาตรฐานจะไม่ทำลายเว็บย้อนหลัง เข้ารหัสโดยเจตนารู้มาตรฐานของคุณ URL ตัวเข้ารหัสและตัวถอดรหัสให้การอ้างอิง RFC 3986
ประเด็นสำคัญ: มาตรฐานนั้นสั้นและแม่นยำ — โหมดทั้งสองโหมดของตัวเข้ารหัสและตัวถอดรหัส URL สอดคล้องกับการเข้ารหัสข้อมูลเทียบกับตัวคั่นที่เก็บรักษาไว้อย่างไร
การเลือกมาตรฐานขึ้นอยู่กับบริบท กำลังสร้าง URL สำหรับเบราว์เซอร์ทั่วไปใช่ไหม ติดตาม RFC 3986; เบราว์เซอร์ใช้กฎ WHATWG ระบบเก่า? ทดสอบการใช้งานจริง กำลังทำให้การจัดเก็บเป็นมาตรฐาน? ใช้ RFC 3986 อย่างสม่ำเสมอ กฎการเข้ารหัสเปอร์เซ็นต์พัฒนาจากแบบอนุรักษ์นิยม RFC 1738 ผ่านการชี้แจง RFC 2396 และ RFC 3986 ไปจนถึงแบบเลเยอร์ WHATWG URL มาตรฐาน แต่ละรุ่นสะท้อนประสบการณ์ ผู้สร้างสมัยใหม่ปฏิบัติตาม RFC 3986 หรือ WHATWG ตามบริบท URL เก่าและใหม่อยู่ร่วมกันโดยต้องมีการพิจารณาความเข้ากันได้ การทำความเข้าใจหมวดหมู่จะช่วยป้องกันข้อผิดพลาดในการเข้ารหัส
ตรวจสอบการเข้ารหัส URL อย่างถูกต้องก่อนปรับใช้ URL ตัวเข้ารหัสและตัวถอดรหัสสาธิตกฎ RFC 3986 จากต้นทางถึงปลายทาง ดูค่าเลขฐานสิบหกที่แน่นอนและทำความเข้าใจว่าอักขระตัวใดเข้ารหัส ใช้เครื่องมือนี้เมื่อสร้าง URL โดยการต่อส่วนต่างๆ RFC 3986 สงวนและไม่ได้สงวนหมวดหมู่พาร์ติชันชุดอักขระสำหรับการแยกวิเคราะห์ URI ที่สอดคล้องกัน