डेवलपर टूल · URL एनकोडर और डिकोडर
RFC 1738 से URL मानक तक: प्रतिशत-एन्कोडिंग नियम कैसे विकसित हुए हैं
· पेजभूमि
URL एन्कोडिंग आरएफसी-इतिहास वेब मानकों
URL में वर्णों से बचने के नियमों को 1994 के बाद से कई बार दोबारा लिखा गया है। यह पोस्ट RFC 1738, RFC 2396, RFC 3986 और WHATWG URL मानक का पालन करती है और बताती है कि हर बार क्या बदला।
RFC 1738 से URL मानक तक—प्रतिशत-एन्कोडिंग नियम कैसे विकसित हुए
टिल्डे (~) उदाहरण देता है कि मानकों की पीढ़ियों और तैनाती में एन्कोडिंग नियम कैसे बदलते हैं। RFC 1738 (1994) हर जगह %7E आवश्यक है; RFC 2396 (1998) अनएन्कोडेड की अनुमति देते हुए टिल्ड को अनारक्षित में ले जाया गया। RFC 3986 (2005) ने अनारक्षित स्थिति की पुष्टि की। %7E वाले पुराने URL वैध बने रहेंगे; नए बिल्डर्स आउटपुट ~। वेब के परिपक्व होने और बुनियादी ढांचे के मानकीकृत होने पर विकास परिनियोजन पाठों को दर्शाता है। RFC 1738 रूढ़िवादी था क्योंकि प्रारंभिक बुनियादी ढांचा विषम और विविध था।
RFC 1738 संहिताबद्ध 1994 ब्राउज़र व्यवहार। UTF-8 पर मानकीकृत तैनाती; प्रतिबंध अनावश्यक सिद्ध हुए। बाद के मानकों ने चरित्र प्रतिबंधों में ढील दी। RFC 3986 अनारक्षित वर्णों की सुरक्षित डिकोडिंग की अनुमति देता है।
RFC 1738 (1994): 'असुरक्षित' वर्ण और पहले भागने के नियम - क्या खतरनाक माना गया और क्यों
RFC 1738 ने "असुरक्षित" वर्णों को ऐसे वर्णों के रूप में परिभाषित किया है जो URI सिंटैक्स (स्पेस, स्लैश) के साथ विरोधाभासी हैं, जो ऐतिहासिक रूप से प्रोटोकॉल (नियंत्रण वर्ण) में उपयोग किए जाते हैं, या जो सिस्टम सुरक्षित रूप से संचारित नहीं कर सकते हैं। रूढ़िवादी सूची आधुनिक इंटरनेट के लिए आवश्यकता से कहीं अधिक प्रतिशत-एन्कोडेड है। कई प्रारंभिक सिस्टम RFC से पहले के थे; इसने उनके व्यवहार को संहिताबद्ध किया। प्रोटोकॉल में नियंत्रण वर्ण वास्तव में खतरनाक थे; कमांड लाइन से पढ़ने वाले HTTP क्लाइंट के लिए स्पेस ट्रांसमिशन समस्याएँ थीं। आधुनिक प्रणालियाँ स्पष्ट एन्कोडिंग के माध्यम से इन मामलों को अधिक खूबसूरती से संभालती हैं।
RFC 1738 के विरुद्ध परीक्षण से पता चलता है कि पुराने सिस्टम से क्या अपेक्षा थी। 1990 के दशक के URL विनिर्देश से एक वर्ण को एनकोड करें और आधुनिक RFC 3986 के साथ तुलना करें। मतभेद बताते हैं कि क्या आराम मिला. समय के साथ अनारक्षित सेट का विस्तार हुआ। हाइफ़न, अवधि, अंडरस्कोर हमेशा सुरक्षित थे। टिल्डे को सुरक्षित होने के लिए RFC 2396 की आवश्यकता थी। रूढ़िवादी दृष्टिकोण का अर्थ था पश्चगामी अनुकूलता। RFC 1738 नियमों के तहत बनाए गए पुराने URL आज भी वैध हैं। RFC 3986 अनुभाग 6 में सामान्यीकरण अनावश्यक रूप से प्रतिशत-एन्कोडेड अनारक्षित वर्णों को सुरक्षित रूप से डिकोड करने की अनुमति देता है।
RFC 2396 (1998) - आरक्षित बनाम अनारक्षित, सामान्य वाक्यविन्यास, और टिल्ड पुनर्वासित
RFC 2396 (1998) वर्ण सेट को RFC 1738 की तुलना में अधिक कठोरता से स्पष्ट किया गया है। इसने URI संरचना बनाम अनारक्षित को शाब्दिक डेटा के रूप में परोसने वाले आरक्षित वर्णों को औपचारिक रूप दिया। हाइफ़न, अवधि, अंडरस्कोर, टिल्ड सहित अनारक्षित विस्तारित। इसने योजना-विशिष्ट नियमों से अलग सामान्य URI सिंटैक्स को स्वीकार किया। RFC 2396 ने जेन-डिलिम्स (:, /, ?, #, [, ], @) और सब-डिलिम्स (!, $, &, ', (, ), *, +, ,, ;, =) के बीच अंतर पेश किया। नामकरण स्पष्ट करता है कि आरक्षित वर्ण अलग-अलग संरचनात्मक भूमिकाओं वाले दो समूहों में विभाजित हो जाते हैं।
RFC 2396 ने सामान्यीकरण मार्गदर्शन पेश किया, जिसमें निर्दिष्ट किया गया कि कौन से प्रतिशत-एन्कोडेड वर्ण अर्थ परिवर्तन के बिना डिकोड कर सकते हैं। अनारक्षित वर्ण डिकोडिंग सामान्य हो जाती है। आरक्षित वर्ण एन्कोडिंग छड़ें। RFC 3986 अंकन को और अधिक सरल बनाया गया। मानक पूरी तरह से पश्चगामी संगतता बनाए रखते हैं।
RFC 3986 (2005) — ! * '() उप-डेलिम्स में जाएं, जेन-डेलिम्स का नाम दिया गया है, और सामान्यीकरण मार्गदर्शन आता है
RFC 3986 (2005) प्रतिशत-एन्कोडिंग के लिए आधुनिक संदर्भ मानक है। इसने /unreserved भेद को आरक्षित रखा लेकिन अंकन को सरल बनाया और सामान्यीकरण मार्गदर्शन जोड़ा। टिल्डे स्पष्ट रूप से अनारक्षित रूप से आगे बढ़े। मानक स्पष्ट प्रतिशत-एन्कोडेड अनारक्षित वर्ण अर्थ परिवर्तन के बिना डिकोड कर सकते हैं। RFC 3986 अनुभाग 3 सटीकता के साथ URI सिंटैक्स का वर्णन करता है। अनुभाग 2 वर्ण कैटेगरी को परिभाषित करता है। अनुभाग 6 वाक्यात्मक सामान्यीकरण के लिए औपचारिक नियम समर्पित करता है। यदि सामान्यीकृत प्रपत्र मेल खाते हैं तो तुलना-आधारित सामान्यीकरण यूआरआई को समान मानता है। पथों से बिंदु-खंड हटाने से अर्थ परिवर्तन के बिना सामान्यीकरण हो जाता है।
एनालिटिक्स, कैशिंग, लिंक फॉलोइंग के लिए सामान्यीकरण मायने रखता है। 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 वर्ण के साथ - नियमों की प्रत्येक पीढ़ी इसे कैसे एन्कोड करती है
अंतर्राष्ट्रीयकृत डोमेन पुनीकोड एन्कोडिंग का उपयोग करते हैं (मुन्चेन xn--mnchen-3ya बन जाता है)। पथ और क्वेरीज़ अभी भी प्रतिशत-एन्कोडिंग का उपयोग करते हैं। डोमेन भाग पुनीकोड का उपयोग करता है; पथ और क्वेरी भाग प्रतिशत-एन्कोडिंग का उपयोग करते हैं। परतें मिश्रित या हस्तक्षेप नहीं करतीं।
IDNA (एप्लिकेशन में अंतर्राष्ट्रीयकृत डोमेन नाम) होस्टनाम समस्या का समाधान करता है। पुनीकोड DNS संगतता के लिए गैर-ASCII को ASCII में एन्कोड करता है। xn-- उपसर्ग पुनीकोड एन्कोडिंग का संकेत देता है। एल्गोरिदम नियतिवादी है: मुन्चेन हमेशा xn--mnchen-3ya बन जाता है। गैर-ASCII वर्णों को DNS रिज़ॉल्यूशन से पहले परिवर्तित करना होगा। प्रतिशत-एन्कोडिंग DNS बाधाओं और लेबल सीमाओं के कारण होस्टनाम के लिए काम नहीं करती है। प्रत्येक दृष्टिकोण अलग-अलग समस्या का सही समाधान करता है। अच्छे कारणों से मानक अलग-अलग विकसित हुए।
इसमें क्या शामिल नहीं है - आईआरआई और अंतर्राष्ट्रीय डोमेन नाम, जिनका अपना इतिहास है
मानकों का चयन संदर्भ पर निर्भर करता है। ब्राउज़रों के लिए 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 वैध बने रहेंगे। राउंड-ट्रिप का परीक्षण शुद्धता और अनुकूलता सुनिश्चित करता है।