डेवलपर टूल · URL एनकोडर और डिकोडर
पुनीकोड बनाम प्रतिशत-एन्कोडिंग: गैर-ASCII डोमेन और पथ कैसे प्रबंधित किए जाते हैं
· पेजभूमि
अंतर्राष्ट्रीयकरण पनीकोड URL एन्कोडिंग
एक URL एक गैर-ASCII होस्टनाम और एक गैर-ASCII पथ के साथ दो पूरी तरह से अलग एन्कोडिंग का उपयोग करता है। यह पोस्ट होस्ट के लिए IDNA और पुनीकोड, बाकी सभी चीजों के लिए प्रतिशत-एन्कोडिंग और विभाजन क्यों मौजूद है, इसकी व्याख्या करती है।
वह पता जो एक ब्राउज़र में 'münchen.example' और दूसरे में 'xn--mnchen-3ya.example' दिखाता है - एक होस्ट, दो वर्तनी
म्यूनचेन शहर एक जर्मन डोमेन नाम में दिखाई देता है। आपके ब्राउज़र के एड्रेस बार में, आप सामान्य रूप से münchen.example प्रदर्शित देख सकते हैं। किसी भिन्न एप्लिकेशन से पता कॉपी करें, और यह xn--mnchen-3ya.example के रूप में दिखाई देता है, एक ASCII-केवल स्ट्रिंग जो जर्मन पाठ की तरह कुछ भी नहीं दिखती है। एक URL, दो वर्तनी, दोनों बिल्कुल मान्य। न तो गलत है; वे पूरी तरह से भिन्न वर्ण सेटों का उपयोग करके एक ही डोमेन का प्रतिनिधित्व करते हैं। यह अंतर एक मूलभूत बाधा को दर्शाता है कि DNS कैसे काम करता है और इंटरनेट इंफ्रास्ट्रक्चर होस्टनामों को कैसे प्रसारित करने की अपेक्षा करता है।
/café/ जैसे पथ खंडों को एन्कोडिंग की आवश्यकता है लेकिन एक अलग सिस्टम का उपयोग करें। गैर-ASCII é पथों में %C3%A9 बन जाता है। अंतर क्यों? DNS बाधाओं के लिए होस्टनामों के लिए पुनीकोड की आवश्यकता होती है।
होस्टनाम प्रतिशत-एन्कोडिंग का उपयोग क्यों नहीं कर सकते - DNS लेबल, अनुमत वर्ण और लंबाई सीमाएँ
DNS लेबल, डॉट्स द्वारा अलग किए गए होस्टनाम के अलग-अलग खंड, के बहुत सख्त नियम हैं। उनमें केवल ASCII अक्षर, अंक, हाइफ़न और अंडरस्कोर हो सकते हैं। उनकी लंबाई सीमाएँ हैं: प्रत्येक लेबल अधिकतम 63 ऑक्टेट हो सकता है, और पूर्ण होस्टनाम 255 ऑक्टेट से अधिक नहीं हो सकता। ये DNS प्रोटोकॉल से ही कठिन बाधाएं हैं, जिसे दशकों पहले अंतरराष्ट्रीय डोमेन नामों की अवधारणा से भी पहले परिभाषित किया गया था। प्रतिशत-एन्कोडिंग होस्टनामों के लिए काम नहीं कर सकती क्योंकि परिणामी स्ट्रिंग संभवतः लंबे शब्दों पर लेबल सीमा को पार कर जाएगी।
इससे भी महत्वपूर्ण बात यह है कि DNS दुनिया भर में राउटर और सर्वर द्वारा संचालित एक वैश्विक प्रणाली है। उनमें से सभी UTF-8 या यूनिकोड को नहीं समझते हैं। %C3%A9 जैसा प्रतिशत-एन्कोडेड वर्ण अभी भी तीन ASCII वर्ण है, इसलिए यह DNS बाधाओं में फिट बैठता है। लेकिन उस दृष्टिकोण का मतलब है कि प्रत्येक लुकअप को अंदर जाते समय प्रतिशत-एनकोड करना होगा और बाहर जाते समय डिकोड करना होगा, जिससे प्रोटोकॉल परत में जटिलता जुड़ जाएगी। विशेष रूप से होस्टनामों के लिए एक बेहतर समाधान की आवश्यकता थी।
IDNA और रूपरेखा में पुनीकोड - xn-- उपसर्ग और बूटस्ट्रिंग एल्गोरिदम, गुणात्मक रूप से वर्णित
IDNA, एप्लिकेशन विनिर्देश में अंतर्राष्ट्रीयकृत डोमेन नाम, गैर-ASCII डोमेन नामों को ASCII में एन्कोड करके होस्टनाम समस्या का समाधान करता है जिसे DNS संभाल सकता है। उपयोग की जाने वाली एन्कोडिंग को पुनीकोड कहा जाता है, एक संपीड़न एल्गोरिदम जो यूनिकोड टेक्स्ट को उपसर्ग xn-- का उपयोग करके बूटस्ट्रिंग-एन्कोडेड प्रतिनिधित्व के बाद ASCII में बदल देता है। एल्गोरिथ्म नियतात्मक है: मुन्चेन हमेशा हर बार xn--mnchen-3ya बन जाता है। DNS रिज़ॉल्यूशन होने से पहले किसी भी गैर-ASCII होस्टनाम को इस तरह से परिवर्तित किया जाना चाहिए।
xn-- उपसर्ग DNS और IDNA-जागरूक सॉफ़्टवेयर को संकेत देता है कि निम्नलिखित वर्ण पुनीकोड हैं, शाब्दिक ASCII अक्षर नहीं। example.xn--mnchen-3ya.com जैसे डोमेन को IDNA-जागरूक सॉफ़्टवेयर द्वारा example.münchen.com समझा जाता है। पुनीकोड केवल ASCII अक्षरों, अंकों और हाइफ़न का उपयोग करता है, इसलिए यह बिना किसी समस्या के DNS लेबल में स्पष्ट रूप से फिट हो जाता है। एल्गोरिदम गैर-ASCII जानकारी को इस ASCII प्रतिनिधित्व में संपीड़ित करता है।
पथ, प्रश्न और टुकड़े प्रतिशत-एन्कोडेड रहते हैं - UTF-8 बाइट्स से %XX, अन्यत्र की तरह
URL में बाकी सब कुछ - पथ, क्वेरी स्ट्रिंग, टुकड़ा - इसके बजाय प्रतिशत-एन्कोडिंग का उपयोग करता है। एक गैर-ASCII वर्ण को पहले UTF-8 बाइट्स में परिवर्तित किया जाता है, फिर प्रत्येक बाइट को %HH के रूप में लिखा जाता है जहां HH हेक्साडेसिमल है। पथ /café/ /caf%C3%A9/. बन जाता है क्वेरी स्ट्रिंग ?name=josé ?name=jos%C3%A9 बन जाती है। प्रतिशत-एन्कोडिंग वेब पर हर जगह मानक है: HTTP अनुरोध URL में, HTML फ़ॉर्म में, API में। इसे DNS या राउटर्स द्वारा विशेष हैंडलिंग की आवश्यकता नहीं है।
प्रतिशत-एन्कोडिंग अन्य विशेष वर्णों को भी सुरक्षित रूप से प्रस्तुत करने की अनुमति देती है। एक स्पेस %20 बन जाता है, एक स्लैश (यदि इसे किसी मान के अंदर दिखना चाहिए) %2F बन जाता है, और इसी तरह। यह योजना सुसंगत एवं सार्वभौमिक है। इसका उपयोग होस्टनामों के लिए नहीं किया जाता क्योंकि DNS URL या प्रतिशत-एन्कोडिंग को नहीं समझता है; यह केवल ASCII लेबल को समझता है।
कार्यान्वित उदाहरण: दोनों के साथ एक URL - होस्ट को पुनीकोड में परिवर्तित किया गया, पथ प्रतिशत-एन्कोडेड, साथ-साथ
URL लें "https://münchen.example/café?city=münchen". होस्टनाम म्यूनचेन को DNS लुकअप से पहले पुनीकोड में परिवर्तित किया जाना चाहिए: https://xn--mnchen-3ya.example/café?city=münchen. लेकिन प्रतीक्षा करें - पथ और क्वेरी में भी गैर-ASCII हैं। उन्हें भी कन्वर्ट करें: https://xn--mnchen-3ya.example/caf%C3%A9?city=m%C3%BCnchen. अब होस्टनाम पुनीकोड है, पथ और क्वेरी प्रतिशत-एनकोडेड हैं। एक ब्राउज़र पठनीयता के लिए मूल यूनिकोड संस्करण प्रदर्शित करता है; HTTP अनुरोध में एन्कोडेड संस्करण होता है।
URL एनकोडर और डिकोडर टूल में, गैर-ASCII टेक्स्ट वाला पथ पेस्ट करें और एकल-मूल्य मोड (सिर्फ पथ) की तुलना संपूर्ण-पता मोड (पूर्ण URL) से करें। टूल आपको पथ के लिए प्रतिशत-एन्कोडेड परिणाम दिखाता है। हालाँकि, होस्टनाम को अलग से पुनीकोड रूपांतरण की आवश्यकता होती है; अधिकांश एन्कोडिंग टूल उस इनलाइन को संभाल नहीं पाते हैं, इसलिए इसे टूल दस्तावेज़ से पढ़ें।
होमोग्राफ हमले और क्यों ब्राउज़र कभी-कभी पुनीकोड दिखाते हैं - प्रदर्शन नियमों के पीछे सुरक्षा तर्क
एक दुर्भावनापूर्ण अभिनेता सिरिलिक अक्षरों का उपयोग करके एक डोमेन पंजीकृत कर सकता है जो देखने में लैटिन अक्षरों के समान दिखता है, जैसे "https://xn--80akhbyknj4f.example" (पुनीकोड में "example.example" का एक सिरिलिक संस्करण)। यदि कोई ब्राउज़र इसे सिरिलिक पाठ के रूप में डिकोड करके प्रदर्शित करता है, तो उपयोगकर्ता अंतर नहीं देख सकते हैं। होमोग्राफ हमलों को रोकने के लिए, ब्राउज़र कभी-कभी इसे डिकोड करने के बजाय पुनीकोड संस्करण दिखाते हैं। एक चेतावनी दिखाई देती है: यह डोमेन सभी या अधिकतर है गैर-ASCII, और आप वर्णों को नहीं पहचान सकते।
URL एनकोडर और डिकोडर एन्कोडिंग और डिकोडिंग के लिए एक टूल है, सुरक्षा मूल्यांकन के लिए नहीं। यदि आप अंतर्राष्ट्रीय डोमेन नामों के साथ काम कर रहे हैं, तो ध्यान रखें कि पुनीकोड प्रतिनिधित्व वही है जो नेटवर्क देखता है।
इसमें क्या शामिल नहीं है - पुनीकोड एल्गोरिदम को हाथ से चलाना या IDNA 2003 बनाम 2008 अंतर
IDNA समय के साथ कई संस्करणों से गुज़रा है: IDNA 2003 और IDNA 2008 कुछ किनारे के मामलों को अलग ढंग से संभालते हैं, विशेष रूप से सामान्यीकरण के आसपास और कौन से यूनिकोड वर्ण विनिर्देश द्वारा अनुमत हैं। कुछ पुराने सिस्टम अभी भी IDNA 2003 का उपयोग करते हैं जबकि अन्य बेहतर अनुपालन के लिए IDNA 2008 पर स्थानांतरित हो गए हैं। यदि आप ऐसे सिस्टम का निर्माण कर रहे हैं जो कई संस्करणों में संगत होना चाहिए तो अंतर महत्वपूर्ण रूप से मायने रखते हैं। अपनी सिस्टम आवश्यकताओं की हमेशा सावधानीपूर्वक जाँच करें।
पुनीकोड बूटस्ट्रिंग कम्प्रेशन का उपयोग करता है। कार्यान्वयन आम भाषाओं में मौजूद हैं, लेकिन अपने होस्टनाम सिस्टम के साथ IDNA नीति को सत्यापित करें। अनुमान लगाने के बजाय संकल्प का परीक्षण करें और व्यवहार प्रदर्शित करें।
टेकअवे: दो कार्यों के लिए दो एनकोडिंग - URL एनकोडर और डिकोडर प्रतिशत-एनकोडेड भागों को कैसे संभालते हैं, और होस्टनाम के लिए प्रतिशत-एनकोडर गलत टूल क्यों है
होस्टनामों को पुनीकोड की आवश्यकता होती है क्योंकि DNS एक पुराना प्रोटोकॉल है जो केवल ASCII लेबल को समझता है और इसमें सख्त लंबाई और वर्ण प्रतिबंध हैं। पथ, क्वेरीज़ और टुकड़े प्रतिशत-एन्कोडिंग का उपयोग करते हैं क्योंकि यह वेब पर सार्वभौमिक है और इसमें वे बाधाएँ नहीं हैं। वे दो पूरी तरह से अलग समस्याओं के लिए दो अलग-अलग समाधान हैं। जब आप एक गैर-ASCII URL का सामना करते हैं, तो होस्टनाम को पहले पुनीकोड रूपांतरण मिलता है, फिर बाकी प्रतिशत-एन्कोडिंग का उपयोग करता है।
अधिकांश विकास कार्यों के लिए, आपका ढांचा या लाइब्रेरी पर्दे के पीछे इस रूपांतरण को स्वचालित रूप से संभालती है। लेकिन यह समझना कि दो अलग-अलग एन्कोडिंग क्यों मौजूद हैं, अंतरराष्ट्रीय URL को डीबग करते समय या अपने स्वयं के URL हैंडलिंग कोड को सफलतापूर्वक लागू करते समय भ्रम को रोकता है।