डेवलपर टूल · URL एनकोडर और डिकोडर
URL की शारीरिक रचना: योजना, प्राधिकरण, पथ, क्वेरी और खंड की व्याख्या
· पेजभूमि
URL-संरचना वेब मानकों डेवलपर टूल
प्रत्येक प्रतिशत-एन्कोडिंग निर्णय इस बात पर निर्भर करता है कि कोई वर्ण URL के किस भाग में बैठता है। यह पोस्ट RFC 3986 से पांच घटकों का नाम देता है, दिखाता है कि प्रत्येक सीमांकक का क्या अर्थ है और क्यों टुकड़ा सर्वर तक कभी नहीं पहुंचता है।
क्यों वही # एक स्थान पर ठीक है और दूसरे स्थान पर एक लिंक को नष्ट कर देता है - एक घटक प्रश्न, चरित्र प्रश्न नहीं
URL में एक हैश वर्ण (#) का मतलब पूरी तरह से अलग चीजें हैं, यह इस पर निर्भर करता है कि यह कहां दिखाई देता है। ?search=C%23sharp जैसे क्वेरी स्ट्रिंग मान के अंदर, इसे सुरक्षित रहने के लिए %23 पर एन्कोड किया जाना चाहिए। https://example.com/page#section, जैसे URL के अंत में यह खंड परिसीमनक और उसके बाद की हर चीज़ को एक खंड के रूप में चिह्नित करता है। एक चरित्र, दो संदर्भ, दो अलग-अलग अर्थ। यही कारण है कि एन्कोडिंग निर्णय यह जानने पर निर्भर करते हैं कि आप URL के किस भाग के साथ काम कर रहे हैं।
प्रश्नचिह्न (?) भी द्विस्वभाव वाला है। पथ या क्वेरी मान के अंदर, इसे डेटा के रूप में प्रदर्शित होने के लिए %3F के रूप में एन्कोड किया जाना चाहिए। पथ और क्वेरी स्ट्रिंग के बीच एक शाब्दिक वर्ण के रूप में, यह संरचनात्मक वाक्यविन्यास है। इन पांच घटकों-स्कीम, प्राधिकरण, पथ, क्वेरी और खंड को समझना सही URL हैंडलिंग की नींव है।
पांच घटक: योजना, प्राधिकरण, पथ, क्वेरी, खंड - और सीमांकक जो उन्हें अलग करते हैं
RFC 3986 औपचारिक रूप से URL को पांच घटकों के रूप में परिभाषित करता है: योजना, प्राधिकरण, पथ, क्वेरी और टुकड़ा, विशिष्ट सीमांकक द्वारा अलग किया गया। योजना पहले आती है, उसके बाद ://, फिर प्राधिकरण, फिर /, फिर पथ, फिर ?, फिर क्वेरी, फिर #, फिर टुकड़ा। सभी घटक प्रत्येक URL में दिखाई नहीं देते हैं। न्यूनतम URL में केवल योजना और पथ हो सकता है, जैसे "mailto:user@example.com"। पूर्ण URL में सभी पाँच शामिल हैं।
प्रत्येक घटक के अपने स्वयं के वाक्यविन्यास नियम होते हैं। स्कीम में एक कोलन आरक्षित है, पथ में स्लैश, क्वेरी में एम्परसेंड। आरक्षित वर्णों को डेटा के रूप में प्रकट होने पर एन्कोडिंग की आवश्यकता होती है: पथ मानों में स्लैश %2F हो जाता है।
प्राधिकरण के अंदर - उपयोगकर्ता जानकारी, होस्ट और पोर्ट, और क्यों @ और : वहां आरक्षित हैं
प्राधिकरण घटक में संसाधन का नेटवर्क पता शामिल होता है: उपयोगकर्ता नाम, पासवर्ड, होस्टनाम और पोर्ट। प्रारूप [userinfo@]होस्ट[:पोर्ट] है। उपयोगकर्ता जानकारी और होस्ट को @ द्वारा अलग किया जाता है; होस्ट और पोर्ट को : द्वारा अलग किया जाता है। ये @ और : वर्ण इन उपघटकों को परिसीमित करने के लिए प्राधिकरण के भीतर आरक्षित हैं। यदि आपके पास एक उपयोगकर्ता नाम है जिसमें @ प्रतीक है, तो इसे संयोजित करने से पहले इसे प्रतिशत-एन्कोडेड होना चाहिए। उदाहरण के लिए, उपयोगकर्ता नाम के रूप में "user@email.com:password" अंतिम @ से पहले "user%40email.com:password" बन जाएगा।
होस्टनाम example.com जैसा एक पंजीकृत डोमेन, 192.0.2.1 जैसे बिंदीदार दशमलव में एक IP पता, या [::1] जैसे कोष्ठक में लिपटा IPv6 पता हो सकता है। पोर्ट वैकल्पिक है; यदि छोड़ दिया जाए, तो योजना डिफ़ॉल्ट निर्धारित करती है (http के लिए 80, https के लिए 443, आदि)। आधुनिक URL में यूजरइन्फो भाग का उपयोग शायद ही कभी किया जाता है लेकिन यह सिंटैक्स का हिस्सा बना रहता है।
पथ खंड और /-पदानुक्रमित संरचना और बिंदु-खंड रिज़ॉल्यूशन का अर्थ
पथ आगे की स्लैश द्वारा अलग किए गए खंडों का एक क्रम है। पथ /a/b/c में तीन खंड हैं: ए, बी और सी। प्रत्येक खंड में अनारक्षित वर्ण, प्रतिशत-एन्कोडेड वर्ण, या कुछ आरक्षित वर्ण शामिल हो सकते हैं जो इस संदर्भ में सुरक्षित हैं। खंड विभाजकों के साथ भ्रम से बचने के लिए खंड के भीतर एक स्लैश को %2F के रूप में एन्कोड किया जाना चाहिए। पथ कैटेगरीबद्ध है; इसका तात्पर्य यह है कि a एक स्थान है, तो a/b अधिक विशिष्ट है।
पथ विशेष बिंदु खंडों का भी समर्थन करते हैं: एक बिंदु (.) का अर्थ है "वर्तमान निर्देशिका" और दो बिंदु (..) का अर्थ है "मूल निर्देशिका"। ../../etc/passwd जैसा पथ ऊपर की ओर हल होता है। आधुनिक URL और HTTP इनका उपयोग करने से बचें, लेकिन वे वाक्यविन्यास में मौजूद हैं। यदि शाब्दिक बिंदु-अर्थ का इरादा नहीं है, तो शाब्दिक बिंदु या डबल-बिंदु वाले पथ खंड को प्रतिशत-एन्कोडेड होना चाहिए।
क्वेरी और फ़्रैगमेंट - कुंजी-मूल्य परंपराएँ, और फ़्रैगमेंट ब्राउज़र में क्यों रहता है
क्वेरी स्ट्रिंग पथ का अनुसरण करती है और ? से प्रारंभ होती है। यह परंपरागत रूप से & द्वारा अलग किए गए कुंजी = मान जोड़े की एक श्रृंखला है, हालांकि वाक्यविन्यास वास्तव में असंरचित है - कुछ भी एक क्वेरी में जा सकता है। यदि आपके पास & या = वाला कोई मान है, तो उन वर्णों को प्रतिशत-एन्कोडेड होना चाहिए ताकि उन्हें गलती से सीमांकक न समझ लिया जाए। क्वेरी सर्वर को भेजी जाती है; सर्वर निर्णय लेता है कि इसके साथ क्या करना है।
खंड क्वेरी का अनुसरण करता है और # से शुरू होता है। # के बाद सब कुछ एक टुकड़ा है, और यह सर्वर तक कभी नहीं पहुंचता है। ब्राउज़र स्थानीय रूप से टुकड़े को संभालता है, आमतौर पर नामित एंकर पर जाने के लिए या एकल-पेज एप्लिकेशन के भीतर स्थिति को इंगित करने के लिए। क्योंकि टुकड़ा कभी भी सर्वर तक नहीं पहुंचता है, एक अलग टुकड़े वाले URL को एक ही संसाधन की ओर इंगित करने वाला माना जाता है।
व्यावहारिक उदाहरण: एक लंबी वास्तविक दुनिया को विच्छेदित करना URL - प्रत्येक घटक और प्रत्येक सीमांकक को लेबल करना
URL "https://user:pass@example.com:8080/path/to/page?search=hello&sort=date#results". लें। योजना https है। प्राधिकरण उपयोगकर्ता है: pass@example.com:8080, उपयोगकर्ता जानकारी (उपयोगकर्ता: पास), होस्ट (example.com) और पोर्ट (8080) में विभाजित है। पथ /path/to/page, है, जिसमें खंड पथ, पेज और पेज शामिल हैं। क्वेरी search=hello&sort=date है, जिसमें दो पैरामीटर हैं। यह URL को URL एनकोडर और डिकोडर में दर्ज करें, यह देखने के लिए कि टूल प्रत्येक घटक को कैसे लेबल और एनकोड करता है।
यदि खोज में &, जैसे ?search=R&D शामिल है, तो ठीक से एन्कोड करने पर यह ?search=R%26D बन जाता है। प्रतिशत-एन्कोडेड वर्ण पाठ में दृश्य सीमाएँ नहीं बनाते हैं, इसलिए सही पार्सिंग के लिए सावधानीपूर्वक एन्कोडिंग और डिकोडिंग बिल्कुल आवश्यक है।
इसमें क्या शामिल नहीं है - सापेक्ष संदर्भ रिज़ॉल्यूशन और विशेष योजनाएं जैसे कि मेल्टो: और डेटा:
"../page" या "?query=value" जैसे सापेक्ष संदर्भ HTML के अंदर मान्य हैं और वर्तमान दस्तावेज़ के सापेक्ष व्याख्या किए गए हैं, लेकिन उनके अपने अलग रिज़ॉल्यूशन नियम हैं। विशेष योजनाएं जैसे mailto:, data:, और file: पूरी तरह से अलग नियमों का पालन करती हैं और मानक पूर्ण URL नहीं हैं।
यह पोस्ट केवल निरीक्षक द्वारा प्रदर्शित मानक निरपेक्ष URL संरचना पर केंद्रित है। सापेक्ष संदर्भों को उनके घटकों की व्याख्या करने से पहले एक आधार URL की आवश्यकता होती है, जबकि मेल्टो और डेटा जैसी योजनाएं समान प्राधिकरण-और-पथ आकार साझा नहीं करती हैं। उन मामलों को अलग रखने से HTTPS पते से सीखे गए नियम को अलग-अलग सीमांकक, रिज़ॉल्यूशन चरणों या परिवहन व्यवहार के साथ सिंटैक्स पर आँख बंद करके लागू होने से रोका जाता है।
टेकअवे: एनकोड करने से पहले घटक को जानें - URL एनकोडर और डिकोडर के एकल-मूल्य और संपूर्ण-पता मोड इस संरचना पर कैसे मैप होते हैं
आप जिस घटक को एन्कोड कर रहे हैं वह यह निर्धारित करता है कि किन पात्रों को भागने की आवश्यकता है और कौन से सुरक्षित हैं। स्लैश पथ में शाब्दिक वाक्यविन्यास है, इसलिए मान में स्लैश %2F होना चाहिए। प्रश्नों में, & और = को एन्कोड किया जाना चाहिए यदि वे मानों में दिखाई देते हैं। URL एनकोडर और डिकोडर के दो मोड हैं: एकल मान को एन्कोड करने के लिए "घटक", और संपूर्ण URL के लिए "संपूर्ण पता"। भागों को जोड़कर URL बनाते समय घटक मोड का उपयोग करें; मौजूदा URL को सत्यापित करने के लिए संपूर्ण-पता मोड का उपयोग करें।
पांच घटकों और उनके सीमांककों को जानने से आप हर बार एन्कोडिंग कार्य का सामना करने पर सही ढंग से चयन कर सकते हैं।