डेवलपर टूल · URL एनकोडर और डिकोडर
RFC 3986 आरक्षित और अनारक्षित वर्ण: URI मानक क्या कहता है
· पेजभूमि
URL एन्कोडिंग आरएफसी3986 प्रतिशत एन्कोडिंग
RFC 3986 वर्णों को आरक्षित, अनारक्षित और अन्य सभी में विभाजित करता है, और वह विभाजन आपके द्वारा प्राप्त किए गए प्रत्येक प्रतिशत-एन्कोडिंग नियम की व्याख्या करता है। यह पोस्ट प्रासंगिक अनुभागों को स्पष्ट रूप से पढ़ता है।
RFC 3986 आरक्षित और अनारक्षित वर्ण—जब आप URL बनाते हैं तो क्या मायने रखता है
RFC 3986 वर्णों को तीन कैटेगरी में विभाजित करता है: अनारक्षित, आरक्षित, और बाकी सब कुछ जिसे एन्कोड किया जाना चाहिए। अनारक्षित वर्णों को कभी भी एन्कोडिंग की आवश्यकता नहीं होती है - ये अक्षर, अंक, हाइफ़न, अवधि, अंडरस्कोर और टिल्ड हैं। RFC इन्हें अनुभाग 2.3 में स्पष्ट रूप से सूचीबद्ध करता है, यह बताते हुए कि इन्हें किसी भी URI संदर्भ में अनएन्कोडेड छोड़ना सुरक्षित है। इन वर्णों के साथ URL एनकोडर और डिकोडर में परीक्षण से पता चलता है कि वे अपरिवर्तित होकर गुजरते हैं। आरक्षित वर्णों को जेन-डेलिम्स (: / ? # [ ] @) और सब-डेलिम्स (! $ & '() * + , ; =) में विभाजित किया जाता है, प्रत्येक का अलग-अलग URL घटकों में संरचनात्मक अर्थ होता है।
किसी पात्र को एन्कोडिंग की आवश्यकता कब होती है? आरक्षित वर्णों को केवल वहीं प्रतिशत-एन्कोड किया जाना चाहिए जहां वे अस्पष्टता पैदा करते हैं। एक स्लैश पथ खंडों को चिह्नित करता है; क्वेरी मान में यह %2F होना चाहिए। एक एम्परसेंड पैरामीटर्स को अलग करता है; & एक मान में %26 की आवश्यकता होती है। अनारक्षित वर्णों को कभी भी एन्कोडिंग की आवश्यकता नहीं होती - एक हाइफ़न हाइफ़न ही रहता है। URL मानक सही पार्सिंग सुनिश्चित करता है। URL एनकोडर और डिकोडर के साथ परीक्षण: encodeURIComponent के साथ "hello/world" दर्ज करने से "hello%2Fworld" उत्पन्न होता है; एनकोडयूआरआई के साथ यह स्लैश को सुरक्षित रखता है।
अनारक्षित: अक्षर, अंक, हाइफ़न, अवधि, अंडरस्कोर और टिल्ड - वे वर्ण जिन्हें कभी भी एन्कोडिंग की आवश्यकता नहीं होती है और उन्हें कभी भी एन्कोड नहीं किया जाना चाहिए
प्रतिशत-एन्कोडिंग %HH का उपयोग करती है जहां HH हेक्साडेसिमल नोटेशन है। ASCII अक्षर A (कोड 65) %41 बन जाता है। गैर-ASCII é को UTF-8 एन्कोडिंग की आवश्यकता होती है: é (U+00E9) %C3%A9 बन जाता है। आधुनिक मानक सभी ब्राउज़रों में समान रूप से UTF-8 निर्दिष्ट करते हैं।
संपूर्ण URL के लिए संरचनात्मक वाक्यविन्यास बरकरार रहना आवश्यक है; क्वेरी मानों को हानिरहित आंतरिक आरक्षित वर्णों की आवश्यकता होती है। क्वेरी पैरामीटर ?q=R&D को मैन्युअल होने पर & को %26 के रूप में एन्कोड करना चाहिए, अन्यथा एम्परसेंड विभाजक बन जाता है। फॉरवर्ड स्लैश वाले मान घटक मोड में %2F बन जाते हैं। घटक एन्कोडिंग (encodeURIComponent) अनारक्षित अक्षरों, अंकों और - _ को छोड़कर सब कुछ एन्कोडिंग करके इसे संभालता है। ! ~ * ' ( ). परीक्षण से तरीकों के बीच अंतर स्पष्ट रूप से पता चलता है।
आरक्षित: जेन-डेलिम्स और सब-डेलिम्स - दो समूह, उनके सदस्य और उनकी संरचनात्मक भूमिकाएँ
क्वेरी स्ट्रिंग्स प्रदर्शित करती हैं कि आरक्षित वर्ण क्यों मायने रखते हैं। एम्परसेंड कुंजी=मान जोड़े को अलग करता है: ?utm_source=email&utm_campaign=sale का अर्थ है दो पैरामीटर। एक मान के अंदर, अनएस्केप्ड एम्परसेंड जोड़ी को समाप्त करता है। बराबर कुंजी को मान से अलग करता है। पार्सिंग कई परतों पर होती है; प्रत्येक समान नियम लागू करता है।
क्वेरी मानों में एन्कोडिंग की आवश्यकता वाले वर्णों में एम्परसेंड, बराबर, हैश, प्रश्न चिह्न, रिक्त स्थान और गैर-ASCII अक्षर शामिल हैं। हैश सबसे गुप्त है: #कुछ भी खंड पहचानकर्ता बन जाता है, सर्वर पर कभी नहीं भेजा जाता है। अनुरोध ब्राउज़र छोड़ने से पहले हैश के साथ समाप्त होने वाले अभियान नाम सब कुछ खो देते हैं। रिक्त स्थान %20 बनना चाहिए. URL एनकोडर और डिकोडर के साथ परीक्षण घटक और फॉर्म मोड दिखाता है। स्थिति को समझने से एन्कोडिंग की आवश्यकता निर्धारित होती है।
जब आरक्षित वर्णों को एन्कोड किया जाना चाहिए - केवल वहीं जहां उन्हें एक सीमांकक, घटक द्वारा घटक के लिए गलत समझा जाएगा
प्रतिशत-एन्कोडिंग RFC 3986 में बनी रहती है। पोर्टेबिलिटी सुनिश्चित करते हुए अनारक्षित सेट छोटा रहता है। प्रतिशत-एन्कोडेड अनारक्षित वर्ण अर्थ परिवर्तन के बिना डिकोड कर सकते हैं। %41 को A से डिकोड करना सही है क्योंकि A अनारक्षित है। %2F को डिकोड करने से / का अर्थ बदल जाता है जब स्लैश डेटा होता है, विभाजक नहीं। RFC 3986 सामान्यीकरण अनुभाग 6 वाक्यविन्यास दृष्टिकोण को शामिल करता है।
अलग-अलग पदों पर आरक्षित पात्रों की अलग-अलग भूमिकाएँ होती हैं। योजना में कोलन अंक योजना:प्राधिकरण सीमा; यूजरइन्फो में कोलन डेटा है। प्रश्न चिह्न क्वेरी अनुभाग खोलता है; क्वेरी मान में स्लैश शाब्दिक है। हैश चिह्न खंड प्रारंभ. स्थिति एन्कोडिंग आवश्यकता निर्धारित करती है। क्वेरी स्ट्रिंग में ऐसे मान होते हैं जो स्वयं यूआरआई होते हैं। एक रीडायरेक्ट 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 से परे घटक-विशिष्ट एन्कोडिंग सेट जोड़ता है। मानक सह-अस्तित्व में हैं: सामान्य URL पार्सिंग के लिए RFC 3986, वेब ब्राउज़र के लिए 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 ने जेन-डिलिम्स (:, /, ?, #, [, ], @) और सब-डिलिम्स (!, $, &, ', (, ), *, +, ,, ;, =) के बीच अंतर पेश किया। प्रत्येक समूह की 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 पार्सिंग के लिए आरक्षित और अनारक्षित श्रेणियां विभाजन वर्ण सेट।