เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · URL ตัวเข้ารหัสและตัวถอดรหัส
จาก RFC 1738 สู่ URL มาตรฐาน: กฎการเข้ารหัสเปอร์เซ็นต์มีการพัฒนาอย่างไร
· พื้นหลัง
การเข้ารหัส URL rfc-ประวัติ มาตรฐานเว็บ
กฎสำหรับการหลีกอักขระใน URL ได้รับการเขียนใหม่หลายครั้งตั้งแต่ 1994 โพสต์นี้เป็นไปตาม RFC 1738, RFC 2396, RFC 3986 และ WHATWG URL มาตรฐาน และอธิบายสิ่งที่เปลี่ยนแปลงในแต่ละครั้ง
จาก RFC 1738 สู่ URL มาตรฐาน—กฎการเข้ารหัสเปอร์เซ็นต์มีการพัฒนาอย่างไร
Tilde (~) เป็นตัวอย่างว่ากฎการเข้ารหัสเปลี่ยนแปลงไปอย่างไรในการสร้างและการปรับใช้มาตรฐาน RFC 1738 (1994) ต้องใช้ %7E ทุกที่; RFC 2396 (1998) ย้ายเครื่องหมายทิลเดอไปที่ไม่สงวนไว้ ทำให้ไม่มีการเข้ารหัส RFC 3986 (2005) ยืนยันสถานะที่ไม่ได้สงวนไว้ URL เก่าที่มี %7E ยังคงใช้ได้ ผลผลิตผู้สร้างใหม่ ~ . วิวัฒนาการสะท้อนถึงบทเรียนการปรับใช้เมื่อเว็บเติบโตเต็มที่และมีโครงสร้างพื้นฐานที่ได้มาตรฐาน RFC 1738 เป็นแบบอนุรักษ์นิยมเนื่องจากโครงสร้างพื้นฐานในยุคแรกมีความหลากหลายและหลากหลาย
RFC 1738 เข้ารหัส 1994 ลักษณะการทำงานของเบราว์เซอร์ การปรับใช้ที่เป็นมาตรฐานบน UTF-8; ข้อจำกัดได้รับการพิสูจน์แล้วว่าไม่จำเป็น มาตรฐานต่อมาได้ผ่อนคลายข้อจำกัดของอักขระ RFC 3986 อนุญาตให้ถอดรหัสอักขระที่ไม่ได้สงวนไว้ได้อย่างปลอดภัย
RFC 1738 (1994): อักขระที่ 'ไม่ปลอดภัย' และกฎการหลบหนีข้อแรก — สิ่งที่ถือว่าเป็นอันตรายและเพราะเหตุใด
RFC 1738 กำหนดอักขระ "ไม่ปลอดภัย" ว่าเป็นอักขระที่ขัดแย้งกับไวยากรณ์ URI (เว้นวรรค เครื่องหมายทับ) ที่เคยใช้ในโปรโตคอล (อักขระควบคุม) หรือระบบไม่สามารถส่งข้อมูลได้อย่างปลอดภัย รายการเข้ารหัสเปอร์เซ็นต์แบบอนุรักษ์นิยมมากเกินความจำเป็นสำหรับอินเทอร์เน็ตสมัยใหม่ ระบบในยุคแรกๆ มากมายเกิดขึ้นก่อน RFC; มันประมวลพฤติกรรมของพวกเขา อักขระควบคุมเป็นอันตรายอย่างแท้จริงในโปรโตคอล ช่องว่างเป็นปัญหาในการส่งข้อมูลสำหรับไคลเอนต์ HTTP ที่อ่านจากบรรทัดคำสั่ง ระบบสมัยใหม่จัดการกับกรณีเหล่านี้ได้อย่างสวยงามยิ่งขึ้นผ่านการเข้ารหัสที่ชัดเจน
การทดสอบกับ RFC 1738 เผยให้เห็นสิ่งที่ระบบเก่าคาดหวัง เข้ารหัสอักขระจากข้อกำหนด URL ปี 1990 และเปรียบเทียบกับ RFC 3986 สมัยใหม่ ความแตกต่างแสดงให้เห็นสิ่งที่ผ่อนคลาย ชุดที่ไม่ได้สงวนไว้ขยายออกไปตามกาลเวลา ยัติภังค์ จุด ขีดเส้นใต้จะปลอดภัยเสมอ ทิลเดต้องการ RFC 2396 เพื่อให้ปลอดภัย วิธีการแบบอนุรักษ์นิยมหมายถึงความเข้ากันได้แบบย้อนหลัง URL เก่าที่สร้างภายใต้กฎ RFC 1738 ยังคงใช้ได้ในปัจจุบัน การทำให้เป็นมาตรฐานใน RFC 3986 ส่วน 6 อนุญาตให้ถอดรหัสอักขระที่ไม่ได้สงวนไว้ซึ่งเข้ารหัสด้วยเปอร์เซ็นต์โดยไม่จำเป็นได้อย่างปลอดภัย
RFC 2396 (1998) — สงวนไว้กับไม่ได้สงวนไว้ ไวยากรณ์ทั่วไป และตัวหนอนได้รับการฟื้นฟู
RFC 2396 (1998) ชุดอักขระที่ชัดเจนยิ่งขึ้นเข้มงวดกว่า RFC 1738 มันทำให้อักขระที่สงวนไว้อย่างเป็นทางการซึ่งให้บริการโครงสร้าง URI เทียบกับข้อมูลที่ไม่สงวนไว้เป็นตัวอักษร ขยายแบบไม่สงวนไว้ รวมถึงยัติภังค์ จุด ขีดล่าง ตัวหนอน ยอมรับไวยากรณ์ URI ทั่วไปแยกจากกฎเฉพาะโครงการ RFC 2396 แนะนำความแตกต่างระหว่าง gen-delims (:, /, ?, #, [, ], @) และ sub-delims ( !, $, &, ', (, ), *, +, ,, ;, =) การตั้งชื่อทำให้อักขระที่สงวนไว้ชัดเจนแบ่งออกเป็นสองกลุ่มโดยมีบทบาททางโครงสร้างที่แตกต่างกัน
RFC 2396 แนะนำคำแนะนำการทำให้เป็นมาตรฐานโดยระบุว่าอักขระที่เข้ารหัสเป็นเปอร์เซ็นต์ตัวใดที่สามารถถอดรหัสได้โดยไม่มีความหมายเปลี่ยนแปลง การถอดรหัสอักขระที่ไม่ได้สงวนไว้จะทำให้เป็นมาตรฐาน แท่งเข้ารหัสอักขระที่สงวนไว้ RFC 3986 รูปแบบย่อเพิ่มเติม มาตรฐานรักษาความเข้ากันได้แบบย้อนหลังอย่างดุเดือด
RFC 3986 (2005) — ! * ' ( ) ย้ายไปที่ sub-delims, gen-delims ถูกตั้งชื่อ และคำแนะนำการทำให้เป็นมาตรฐานมาถึง
RFC 3986 (2005) เป็นมาตรฐานอ้างอิงสมัยใหม่สำหรับการเข้ารหัสเปอร์เซ็นต์ มันยังคงรักษาความแตกต่างที่สงวนไว้/unreserved แต่ใช้สัญลักษณ์ที่เรียบง่ายและเพิ่มคำแนะนำในการทำให้เป็นมาตรฐาน ทิลเดขยับตัวอย่างไม่คลุมเครือ อักขระที่ไม่ได้สงวนไว้ซึ่งเข้ารหัสด้วยเปอร์เซ็นต์ที่ชี้แจงมาตรฐานสามารถถอดรหัสได้โดยไม่มีความหมายเปลี่ยนแปลง RFC 3986 ส่วน 3 อธิบายไวยากรณ์ URI อย่างแม่นยำ ส่วน 2 กำหนดหมวดหมู่อักขระ ส่วน 6 กำหนดกฎอย่างเป็นทางการให้กับการทำให้เป็นมาตรฐานทางวากยสัมพันธ์ การทำให้เป็นมาตรฐานโดยอิงการเปรียบเทียบจะถือว่า URI เหมือนกันหากรูปแบบที่ทำให้เป็นมาตรฐานตรงกัน การลบจุดส่วนออกจากเส้นทางจะทำให้เป็นมาตรฐานโดยไม่มีการเปลี่ยนแปลงความหมาย
การทำให้เป็นมาตรฐานมีความสำคัญสำหรับการวิเคราะห์ การแคช การติดตามลิงก์ URL ที่แตกต่างกันเฉพาะตัวพิมพ์ฐานสิบหก (RFC 3986 ต้องการตัวพิมพ์ใหญ่) ควรเหมือนกันในทางปฏิบัติ การทำให้เป็นมาตรฐานจะป้องกันรายการบันทึกที่ซ้ำกันและการพลาดแคช แคชที่คีย์บน URL ที่เป็นมาตรฐานจะให้บริการเนื้อหาโดยไม่คำนึงถึงการตั้งค่าการเข้ารหัสของผู้ร้องขอ RFC 3986 คำแนะนำการทำให้เป็นมาตรฐานช่วยให้ระบบสามารถตัดสินใจได้อย่างสม่ำเสมอ แต่การบังคับใช้ที่เข้มงวดทำให้ URL ทำงานได้ดีในอินเทอร์เน็ตปัจจุบัน
WHATWG URL มาตรฐาน: แยกวิเคราะห์สิ่งที่เบราว์เซอร์ได้รับจริง - ชุดเข้ารหัส รูปแบบพิเศษ และความทนทานต่อข้อผิดพลาด
WHATWG URL มาตรฐาน (2016–ปัจจุบัน) เกิดขึ้นจากประสบการณ์การใช้เบราว์เซอร์โดยมี URL ที่ไม่ติดตาม RFC 3986 อย่างสมบูรณ์แบบ เบราว์เซอร์ต้องเผชิญกับช่องว่างที่ไม่ได้เข้ารหัส การเข้ารหัสแบบผสม และนิสัยแปลกๆ WHATWG อธิบายการแยกวิเคราะห์เบราว์เซอร์จริง ไม่ใช่ไวยากรณ์ทางทฤษฎี เบราว์เซอร์ในโลกแห่งความเป็นจริงได้พัฒนากฎการปฏิบัติสำหรับการยอมรับช่องว่าง การจัดการอักขระที่หลบหนี การกู้คืนจากการป้อนข้อมูลที่มีรูปแบบไม่ถูกต้อง RFC 3986 มาถึงใน 2005 และกำหนดไวยากรณ์อย่างเป็นทางการ แต่เบราว์เซอร์ในทางปฏิบัติได้แยกออกไปเล็กน้อยแล้ว
WHATWG กำหนดชุดการเข้ารหัสเก้าชุดด้วยกฎเฉพาะบริบท ช่องว่างในเส้นทางกลายเป็น %20; เครื่องหมายทับในข้อมูลผู้ใช้กลายเป็น %2F เบราว์เซอร์ใช้มาตรฐานที่แคบกว่าสำหรับเว็บ RFC 3986 ให้พื้นฐาน; WHATWG ต่อยอด
ตัวอย่างการทำงาน: URL หนึ่งตัวที่มีเครื่องหมายทิลเดอ ช่องว่าง และอักขระที่ไม่ใช่ ASCII — วิธีการเข้ารหัสของกฎแต่ละรุ่น
โดเมนสากลใช้การเข้ารหัส punycode (München กลายเป็น xn--mnchen-3ya) เส้นทางและแบบสอบถามยังคงใช้การเข้ารหัสเปอร์เซ็นต์ ส่วนโดเมนใช้ punycode ส่วนเส้นทางและแบบสอบถามใช้การเข้ารหัสเปอร์เซ็นต์ เลเยอร์ไม่ปะปนหรือรบกวน
IDNA (ชื่อโดเมนสากลในแอปพลิเคชัน) แก้ปัญหาชื่อโฮสต์ Punycode เข้ารหัส non-ASCII เป็น ASCII เพื่อความเข้ากันได้ของ DNS คำนำหน้า xn-- ส่งสัญญาณการเข้ารหัส punycode อัลกอริทึมเป็นสิ่งที่กำหนดได้: มิวนิคจะกลายเป็น xn--mnchen-3ya เสมอ อักขระที่ไม่ใช่ ASCII ต้องแปลงก่อนที่จะมีความละเอียด DNS การเข้ารหัสเปอร์เซ็นต์ใช้ไม่ได้กับชื่อโฮสต์เนื่องจากข้อจำกัด DNS และขีดจำกัดของป้ายกำกับ แต่ละวิธีแก้ไขปัญหาที่แตกต่างกันได้อย่างถูกต้อง มาตรฐานพัฒนาแยกจากกันด้วยเหตุผลที่ดี
สิ่งนี้ไม่ครอบคลุมถึง — IRI และชื่อโดเมนสากลซึ่งมีประวัติเป็นของตัวเอง
การเลือกมาตรฐานขึ้นอยู่กับบริบท สร้าง URL สำหรับเบราว์เซอร์? ติดตาม RFC 3986; เบราว์เซอร์ใช้ WHATWG ระบบเก่า? ทดสอบการใช้งาน การเข้าใจวิวัฒนาการป้องกันความสับสน
ผู้สร้างยุคใหม่ควรปฏิบัติตาม RFC 3986 หรือ WHATWG ตามบริบท URL เก่าและใหม่อยู่ร่วมกันโดยต้องคำนึงถึงความเข้ากันได้อย่างรอบคอบ URL ตัวเข้ารหัสและตัวถอดรหัสจะติดตาม RFC 3986 ตลอด โดยให้การอ้างอิงคงที่แยกจากพฤติกรรมของเบราว์เซอร์ WHATWG เพิ่มชุดการเข้ารหัสเฉพาะส่วนประกอบที่นอกเหนือจาก RFC พื้นฐาน การรู้ว่าอะไรเปลี่ยนแปลงไปเมื่อไรช่วยให้เข้าใจว่าทำไมระบบถึงไม่เห็นด้วย การทดสอบ URL ของคุณด้วยทั้งสองมาตรฐานจะเผยให้เห็นการควบคุมมาตรฐานใดในสภาพแวดล้อมของคุณ ถูกต้องทั้งสองมาตรฐาน
ประเด็นสำคัญ: รู้ว่ากฎใดที่โค้ดของคุณปฏิบัติตาม — ตัวเข้ารหัสและตัวถอดรหัส URL ให้พฤติกรรม RFC 3986 เป็นจุดอ้างอิงคงที่แก่คุณอย่างไร
RFC 3986 การทำให้เป็นมาตรฐานอนุญาตให้ถอดรหัสอักขระที่ไม่ได้สงวนไว้ซึ่งเข้ารหัสด้วยเปอร์เซ็นต์โดยไม่จำเป็นได้อย่างปลอดภัย %41 ทำให้เป็นมาตรฐาน A. อักขระสงวนที่เข้ารหัสเช่น %2F ไม่เคยถอดรหัส; การเปลี่ยนแปลงความหมายทำให้โครงสร้างแตกสลาย หน่วยงานมาตรฐานรักษาความเข้ากันได้แบบย้อนหลังอย่างเข้มงวด การแก้ไขจะต้องอาศัยการประสานงานทั่วโลกซึ่งเป็นไปไม่ได้หลังจากผ่านไปหลายทศวรรษ หนังสือมาตรฐานจะไม่ทำลายเว็บย้อนหลัง การเปลี่ยนแปลงการตัดสินใจในการเข้ารหัสจะทำลายระบบที่มีอยู่หลายพันล้านระบบพร้อมกัน
การเข้ารหัสเปอร์เซ็นต์ครอบคลุมระยะเวลาสามทศวรรษของการพัฒนาอย่างระมัดระวัง: จาก RFC 1738 ถึง RFC 2396 และ RFC 3986 ไปจนถึงมาตรฐาน WHATWG URL สมัยใหม่ โค้ดสมัยใหม่ควรเป็นไปตาม RFC 3986 พื้นฐาน URL เก่าที่มีการเข้ารหัสก่อนหน้านี้ยังคงใช้ได้ การทดสอบแบบไปกลับช่วยให้มั่นใจถึงความถูกต้องและความเข้ากันได้