डेवलपर टूल · URL एनकोडर और डिकोडर
WHATWG URL मानक बनाम RFC 3986: ब्राउज़र और लाइब्रेरी असहमत क्यों हैं
· पेजभूमि
URL एन्कोडिंग मानकों डेवलपर टूल
URL की दो जीवंत परिभाषाएँ हैं, और वे जानबूझकर असहमत हैं। यह पोस्ट बताती है कि WHATWG ने अपना स्वयं का मानक क्यों लिखा, जहां दोनों एन्कोडिंग और पार्सिंग में भिन्न हैं, और आपका कोड किसका अनुसरण करता है।
URL जिसे एक सख्त लाइब्रेरी अस्वीकार कर देती है और ब्राउज़र ख़ुशी से लोड करता है - एक स्ट्रिंग, दो फैसले
JavaScript में बैकस्लैश वाली एक स्ट्रिंग को आपके ब्राउज़र द्वारा URL पथ के हिस्से के रूप में आसानी से समझा जा सकता है। वही स्ट्रिंग पायथन लाइब्रेरी बैकएंड तक पहुंचती है, और यह इसे पार्स करने से इंकार कर देती है क्योंकि बैकस्लैश की अनुमति नहीं है। एक URL, दो अलग-अलग परिणाम। कोई भी ग़लत नहीं है—वे विभिन्न मानकों का पालन करते हैं। WHATWG मानक वर्णन करता है कि ब्राउज़र वास्तव में वास्तविक दुनिया के URL के साथ क्या करते हैं, जिसमें वे विकृत इनपुट को कैसे संभालते हैं। RFC 3986 एक औपचारिक व्याकरण को परिभाषित करता है जिसके अनुरूप URL को आदर्श रूप से अनुरूप होना चाहिए। RFC 3986 पर निर्मित कई बैकएंड लाइब्रेरी उस व्याकरण को सख्ती से लागू करती हैं और उसके बाहर की किसी भी चीज़ को अस्वीकार कर देती हैं।
जब आप परिवेशों के बीच डेटा स्थानांतरित करते हैं तो यह विचलन मायने रखता है। URL ब्राउज़र स्वीकार करने से बैकएंड टूल में सत्यापन विफल हो सकता है। यह समझना कि आपका कोड कौन सा मानक लागू करता है, डिबगिंग प्रेत समस्याओं को रोकता है - URL एक स्थान पर ठीक से काम कर रहे हैं लेकिन बिना किसी स्पष्ट कारण के रहस्यमय तरीके से कहीं और विफल हो रहे हैं।
WHATWG की शुरुआत क्यों हुई - यह वर्णन करना कि वैध इनपुट के बजाय ब्राउज़र वास्तव में विकृत इनपुट के साथ क्या करते हैं
WHATWG वर्किंग ग्रुप का गठन 2004 में यह मानकीकृत करने के लिए किया गया था कि ब्राउज़र वास्तव में व्यवहार में URL को कैसे संभालते हैं, बजाय इसके कि कठोर औपचारिक नियमों को परिभाषित किया जाए जिनका ब्राउज़र पालन नहीं करेंगे। RFC 2396 ने एक औपचारिक व्याकरण विनिर्देश का वर्णन किया, लेकिन व्यवहार में ब्राउज़रों ने कभी भी इसका सही ढंग से पालन नहीं किया। वास्तविक दुनिया के ब्राउज़रों ने रिक्त स्थान को सहन करने, बच गए पात्रों को संभालने और विकृत इनपुट से उबरने के लिए व्यावहारिक नियम विकसित किए हैं जिनकी RFC ने आशा या अपेक्षा नहीं की थी।
RFC 3986 सुव्यवस्थित URL और सख्त आवश्यकताओं के लिए औपचारिक व्याकरण के साथ 2005 में आया। ब्राउज़र WHATWG लागू करते हैं; बैकएंड लाइब्रेरीज़ अक्सर RFC 3986 लागू करती हैं।
एनकोड सेट बनाम आरक्षित वर्ण - URL मानक की प्रति-घटक सूचियाँ RFC 3986 की कैटेगरी से कैसे संबंधित हैं
RFC 3986 वर्णों को तीन कैटेगरी में विभाजित करता है: आरक्षित, अनारक्षित, और बाकी सब कुछ जिसे एन्कोड किया जाना चाहिए। कोलन, स्लैश, प्रश्न चिह्न और हैश जैसे आरक्षित वर्णों का URL में संरचनात्मक अर्थ होता है। अनारक्षित वर्ण अक्षर, अंक, हाइफ़न, अंडरस्कोर, अवधि और टिल्ड हैं; ये हमेशा सुरक्षित रहते हैं. बाकी सब कुछ बाइट्स के रूप में प्रतिशत-एनकोडेड हो जाता है। मानक एक स्पष्ट नियम प्रदान करता है: जानें कि आपका चरित्र किस कैटेगरी का है।
WHATWG URL मानक एक घटक-आधारित दृष्टिकोण अपनाता है। यह वैश्विक कैटेगरी का उपयोग करने के बजाय योजना, प्राधिकरण, पथ, क्वेरी और टुकड़े के लिए अलग-अलग एन्कोडिंग नियम निर्दिष्ट करता है। एक एम्परसेंड को पथ में एन्कोड किया जा सकता है लेकिन क्वेरी स्ट्रिंग में अकेला छोड़ दिया जा सकता है। एक स्थान हमेशा एन्कोड किया जाता है, लेकिन सटीक प्रतिनिधित्व संदर्भ के अनुसार भिन्न होता है। यह प्रति-घटक डिज़ाइन ब्राउज़र के व्यवहार से बहुत बेहतर मेल खाता है, लेकिन यह जानने की आवश्यकता है कि आप URL के किस भाग को एन्कोड कर रहे हैं।
त्रुटि सहनशीलता: रिक्त स्थान, बैकस्लैश और टैब - इनपुट एक मानक अस्वीकार करता है और दूसरा मरम्मत करता है
दोनों मानकों के तहत रिक्त स्थान को %20 बनना चाहिए, लेकिन ब्राउज़र चुपचाप शाब्दिक रिक्त स्थान को परिवर्तित कर देते हैं। बैकस्लैश दोनों मानकों द्वारा निषिद्ध हैं, फिर भी कुछ ब्राउज़र उन्हें पथ विभाजक के रूप में मानते हैं। टैब, न्यूलाइन और नियंत्रण वर्ण निषिद्ध हैं। WHATWG उदार पार्सर व्यवहार निर्दिष्ट करता है: उन्हें परिवर्तित करें या अनदेखा करें।
é या 中 जैसे गैर-ASCII वर्णों को UTF-8 एन्कोडिंग का उपयोग करके प्रतिशत-एन्कोड किया जाना चाहिए। RFC 3986 वास्तव में वर्ण एन्कोडिंग चरण को निर्दिष्ट नहीं करता है; यह मानता है कि बाइट्स मौजूद हैं लेकिन यह नहीं बताता कि उन्हें टेक्स्ट से कैसे प्राप्त किया जाए। WHATWG मानक को स्पष्ट रूप से UTF-8 की आवश्यकता होती है: पहले स्ट्रिंग को UTF-8 बाइट्स में बदलें, फिर उन्हें प्रतिशत-एन्कोड करें। दोनों मानक एक ही एन्कोडिंग परिणाम तक पहुंचते हैं, लेकिन वे विभिन्न अंतर्निहित धारणाओं से शुरू होते हैं और समान चीजों के बारे में स्पष्ट नहीं होते हैं।
कार्यान्वित उदाहरण: URL को बैकस्लैश और दोनों मॉडलों में एक स्थान के साथ पार्स करना - आउटपुट की तुलना
उदाहरण स्ट्रिंग "https://example.com/café\ खोज" लें। एक ब्राउज़र बैकस्लैश का सामना करता है और इसे पथ वर्ण के रूप में देखता है; यह स्थान देखता है और इसे %20 पर एन्कोड करता है, जिससे https://example.com/café%5C%20search. जैसा कुछ उत्पन्न होता है। एक RFC 3986 पार्सर संपूर्ण URL को तुरंत अस्वीकार कर देता है क्योंकि बैकस्लैश निषिद्ध हैं और रिक्त स्थान निषिद्ध हैं। ब्राउज़र पार्स करना जारी रखता है; सख्त पार्सर पूरी तरह से रुक जाता है। एक और उदाहरण आज़माएं: "https://user@example.com:80/path?q=a&b=c". दोनों मानक उपयोगकर्ता जानकारी, होस्ट, पोर्ट, पथ और क्वेरी को स्पष्ट रूप से पहचानते हैं। वे इस संरचित URL पर पूरी तरह सहमत हैं। असहमति केवल असामान्य या विकृत इनपुट पर होती है।
URL एनकोडर और डिकोडर खोलें और ब्राउज़र व्यवहार के साथ RFC 3986 मोड की तुलना करें। रिक्त स्थान, बैकस्लैश या अन्य किनारे के मामलों के साथ एक स्ट्रिंग चिपकाएँ। टूल आपको सटीक रूप से दिखाता है कि प्रत्येक मानक एक ही इनपुट को अलग-अलग तरीके से कैसे बदलता है। आप तुरंत देख लें कि कौन अधिक सख्त है और प्रत्येक क्या करता है।
आपका वातावरण किसका उपयोग करता है - ब्राउज़र और नोड URL मानक का पालन करते हैं; कई सर्वर लाइब्रेरी आम तौर पर वर्णित RFC का पालन करती हैं
ब्राउज़र में, JavaScript डिफ़ॉल्ट रूप से WHATWG URL मानक का उपयोग करता है। URL API इसे बिल्कुल लागू करता है। Node.js WHATWG का भी उपयोग करता है। पायथन लाइब्रेरीज़ RFC 3986 को लागू करती हैं; urllib इसका बारीकी से अनुसरण करता है। जावा लाइब्रेरी भिन्न-भिन्न होती हैं; java.net.URL का झुकाव RFC 3986 की ओर होता है। रस्ट का URL क्रेट WHATWG का अनुसरण करता है। गो का नेट/url WHATWG से प्रभावित है। यह एक सामान्य पैटर्न है, कोई पूर्ण नियम नहीं।
जब आप प्रोग्रामेटिक रूप से URL बनाते हैं और वे ब्राउज़र और बैकएंड के बीच चलते हैं, तो एक मानक चुनें और उस पर टिके रहें। WHATWG के लिए ब्राउज़र के URL API का उपयोग करें। यदि आपकी बैकएंड लाइब्रेरी सख्त है, तो यह कोई विरोधाभास नहीं है बल्कि एक डिज़ाइन विकल्प है।
इसमें क्या शामिल नहीं है - होस्टनाम पार्सिंग, IPv6 अक्षर और IDNA प्रोसेसिंग
होस्टनाम पार्सिंग में IDNA, पुनीकोड और रजिस्ट्रार नियम शामिल होते हैं जो URL से आगे जाकर खुद को पूरी तरह से पार्स करते हैं। IPv6 पते, मेल्टो: या डेटा: जैसी विशेष योजनाएं, और खाली घटक पूरी तरह से प्रतिशत-एन्कोडिंग से अलग अलग विषय हैं। डोमेन की लंबाई सीमा और होस्टनाम वैधता रजिस्ट्रार के अनुसार अलग-अलग होती है और इस चर्चा के लिए प्रासंगिक नहीं है। इन्हें भी बाहर रखा गया है: सापेक्ष संदर्भ और योजना-विशिष्ट पार्सिंग नियम। यह पोस्ट केवल एन्कोडिंग और अंतर पार्सिंग पर केंद्रित है।
यह चर्चा उन एन्कोडिंग और पार्सिंग अंतरों पर केंद्रित है जो इन मानकों को अलग करते हैं। होस्टनाम नियमों को छोड़कर, DNS नियम और योजना-विशिष्ट व्यवहार प्रतिशत-एन्कोडिंग नियमों के बारे में भ्रम को रोकता है।
टेकअवे: वही URL एक दुनिया में मान्य है और दूसरी दुनिया में एक त्रुटि - कैसे URL एनकोडर और डिकोडर आपको सादा RFC 3986 एन्कोडिंग देता है ताकि आप देख सकें कि ब्राउज़र ने क्या सामान्य किया है
वही URL स्ट्रिंग एक मानक के अंतर्गत मान्य और दूसरे के अंतर्गत अमान्य हो सकती है। दोनों अपने-अपने डिज़ाइन लक्ष्यों में सही हैं। URL घटकों को प्रोग्रामेटिक रूप से एन्कोड करते समय, अपने परिवेश के लिए सही टूल का उपयोग करें। WHATWG वर्णन करता है कि ब्राउज़र वास्तव में क्या करते हैं; RFC 3986 औपचारिक व्याकरण को परिभाषित करता है। URL एनकोडर और डिकोडर ब्राउज़र व्यवहार के साथ-साथ RFC 3986 नियम दिखाता है ताकि आप सटीक अंतर देख सकें और चुन सकें कि कौन सा आपकी स्थिति के लिए उपयुक्त है।
समस्याएँ अक्सर तब सामने आती हैं जब URL ब्राउज़र-टू-बैकएंड सीमाओं को पार कर जाते हैं। इस अंतर को समझने का अर्थ है गलती से या गलती से नहीं बल्कि जानबूझकर उस क्रॉसिंग को संभालना।