डेवलपर टूल · URL एनकोडर और डिकोडर
प्रतिशत-एन्कोडिंग कैसे काम करती है: वर्णों से UTF-8 बाइट्स से %XX अनुक्रम तक
· यह काम किस प्रकार करता है
URL एन्कोडिंग utf-8 प्रतिशत एन्कोडिंग डेवलपर
प्रतिशत-एन्कोडिंग वर्णों को एन्कोड नहीं करती है; यह बाइट्स को एन्कोड करता है। यह पोस्ट दिखाती है कि कैसे एक अक्षर UTF-8 बाइट्स और फिर हेक्स जोड़े में बदल जाता है, और क्यों एक उच्चारण अक्षर दो %XX समूह लेता है जबकि एक इमोजी चार लेता है।
क्यों 'é' %E9 के बजाय %C3%A9 में बदल जाता है - अवलोकन जो नीचे बाइट परत को प्रकट करता है
जब कोई जूनियर डेवलपर URL में %C3%A9 देखता है, तो प्रतिशत-एन्कोडिंग बाइट्स पर काम करती है, वर्णों पर नहीं। चरित्र é एक बाइट नहीं है; UTF-8 इसे दो के रूप में एन्कोड करता है: C3 A9। RFC 3986 से प्रतिशत-एन्कोडिंग नियम सरल है: प्रत्येक बाइट को प्रतिशत चिह्न के रूप में एन्कोड करें जिसके बाद दो हेक्स अंक हों। वह भेद व्याख्या को रहस्यमय से तार्किक में बदल देता है।
प्रतिशत-एन्कोडिंग को समझने के लिए UTF-8 को समझना आवश्यक है। कैरेक्टर एन्कोडिंग का उपयोग करके टेक्स्ट को बाइट्स में परिवर्तित किया जाना चाहिए। UTF-8 URL और वेब के लिए मानक है। यह वर्णों को चर-लंबाई बाइट अनुक्रमों के रूप में व्यक्त करता है: ASCII एक बाइट का उपयोग करता है, उच्चारण अक्षर दो का उपयोग करते हैं, इमोजी चार का उपयोग करते हैं। प्रत्येक चरण अलग है: वर्ण, यूनिकोड कोड बिंदु, UTF-8 बाइट्स, फिर %XX जोड़े। बाइट्स को समझे बिना हेक्स पर जाने से बात चूक जाती है।
RFC 3986 से प्रतिशत-एन्कोडिंग नियम - एक % जिसके बाद प्रति बाइट दो हेक्स अंक, अपरकेस को प्राथमिकता दी जाती है
RFC 3986 एक नियम को परिभाषित करता है: प्रत्येक बाइट को प्रतिशत के रूप में एन्कोड करें और उसके बाद दो अपरकेस हेक्साडेसिमल अंक। अनारक्षित वर्ण जिन्हें एन्कोडिंग की आवश्यकता नहीं है वे अक्षर, अंक, हाइफ़न, अंडरस्कोर, अवधि और टिल्ड हैं। बाकी सब कुछ एन्कोड किया जाना चाहिए। रिक्त स्थान %20 बन जाते हैं, स्लैश %2F बन जाते हैं, और प्रतिशत चिह्न %25 बन जाता है। यह क्वेरी मानों में विशेष वर्णों को URL संरचना को तोड़ने से रोकता है।
एक स्पेस बाइट 0x20 के रूप में एन्कोड होता है, जो %20 बन जाता है। एक फॉरवर्ड स्लैश 0x2F है, जो %2F बन जाता है। ये ASCII वर्ण हैं जिन्हें एक बाइट की आवश्यकता है। उच्चारण अक्षर और इमोजी अलग-अलग हैं। प्रतिशत चिह्न %25 हो जाता है. कोलन जैसे आरक्षित सीमांकक संरचना को संरक्षित करने के लिए एन्कोड किए जाते हैं। यह क्वेरी पैरामीटर में एम्बेडेड एम्परसेंड या बराबर को पार्सिंग को तोड़ने से रोकता है। प्रत्येक बाइट %HH हो जाता है।
UTF-8 कल्पित वर्णसेट के रूप में - आधुनिक URL UTF-8 क्यों हैं और विरासती अपवाद कहां हैं
UTF-8 परिवर्तनीय-लंबाई एन्कोडिंग का उपयोग करता है। ASCII कोड बिंदु 0 से 127 तक एक बाइट है। 128 से 2047 तक के अक्षर, जिसमें उच्चारित लैटिन अक्षर भी शामिल हैं, दो बाइट्स हैं। 2048 से 65535 तक के अक्षर, जो पूर्वी एशियाई लिपियों में आम हैं, तीन बाइट्स हैं। 65535 से ऊपर के वर्ण, अधिकांश इमोजी सहित, चार बाइट्स हैं। प्रत्येक बाइट के पहले बिट्स लगे होते हैं जो संकेत देते हैं कि कितने बाइट्स अनुसरण करते हैं।
उच्चारण अक्षर é यूनिकोड कोड बिंदु U+00E9 है। UTF-8 इसे दो बाइट्स के रूप में एन्कोड करता है: 0xC3 और 0xA9। प्रतिशत-एन्कोडिंग %C3%A9 उत्पन्न करती है। जर्मन ü (U+00FC) 0xC3 0xBC के रूप में एन्कोड करता है, जो %C3%BC बन जाता है। स्पैनिश ñ (U+00F1) 0xC3 0xB1 के रूप में एन्कोड करता है, जो %C3%B1 बन जाता है। पैटर्न सुसंगत है: पहला बाइट दो-बाइट अनुक्रम का संकेत देता है। एन्कोडिंग में एक उच्चारण अक्षर छह अक्षरों तक विस्तारित होता है।
कार्यान्वित उदाहरण: 'कैफ़े 😀' बाइट को बाइट द्वारा एन्कोड करना - कोड बिंदु, UTF-8 बाइट्स और परिणामी स्ट्रिंग
इमोजी बाइट परत को स्पष्ट बनाता है। थम्स-अप इमोजी 👍 कोड पॉइंट U+1F44D है। UTF-8 इसे चार बाइट्स के रूप में एन्कोड करता है: F0 9F 91 8D। प्रतिशत-एन्कोडिंग %F0%9F%918D उत्पन्न करती है: एक प्रतीक के लिए बारह अक्षर। स्माइली 😀 (U+1F600) F0 9F 98 80 के रूप में एन्कोड होता है, जो %F0%9F%9880 बन जाता है। चार-बाइट अनुक्रम बारह प्रतिशत-एन्कोडेड वर्ण बन जाते हैं।
मिश्रित पाठ से पता चलता है कि बाइट्स को समझना क्यों मायने रखता है। वाक्यांश "कैफ़े 😀" में सादा ASCII, एक उच्चारण और एक इमोजी शामिल है। अक्षर c, a, f को 63, 61, 66 के रूप में कूटबद्ध किया जाता है। é C3 A9 के रूप में एन्कोड करता है। स्पेस 20 के रूप में एन्कोड करता है। इमोजी को F0 9F 98 80 के रूप में एन्कोड किया गया है। परिणाम "caf%C3%A9%20%F0%9F%9880" है। यह समझना कि किन बाइट्स को एन्कोडिंग की आवश्यकता है, आउटपुट को पूर्वानुमानित बनाता है।
रिवर्स में डिकोडिंग - %XX समूहों को बाइट्स में एकत्रित करना और उसके बाद ही उन्हें UTF-8 के रूप में व्याख्या करना
डिकोडिंग प्रक्रिया को उलट देती है। एक डिकोडर %XX जोड़ियों को स्कैन करता है और उन्हें बाइट मानों में एकत्र करता है। %C3%A9 देखकर यह बाइट्स C3 और A9 निकालता है। UTF-8 डिकोडिंग उन्हें चरित्र é के रूप में व्याख्या करती है। यदि कोई अनुक्रम अधूरा है, जैसे अकेले %C3, तो परिणाम एक त्रुटि है। डिकोडर UTF-8 उपसर्ग बिट्स से जानता है कि C3 को दूसरे बाइट की आवश्यकता है।
हेक्स अंकों में केस का कोई महत्व नहीं है; %C3%A9 और %c3%a9 समान रूप से डिकोड करते हैं। RFC अपरकेस या लोअरकेस की अनुमति देता है, हालांकि अपरकेस को प्राथमिकता दी जाती है। लेकिन पात्रों के लिए मामला मायने रखता है: é (%C3%A9 के रूप में) É (%C3%89 के रूप में) के समान नहीं है। URL तुलना को प्रतिशत-एन्कोडिंग को सामान्य बनाना चाहिए या समान संसाधनों को अलग मानने का जोखिम उठाना चाहिए। कैशिंग से पहले फ्रेमवर्क सामान्य हो जाता है।
क्यों मामला हेक्स अंकों में मायने नहीं रखता है लेकिन अन्यत्र करता है - सामान्यीकरण नियम और URL तुलना
RFC 3986 अलग-अलग नियमों के रूप में डोमेन नामों के लिए पुनीकोड और सबमिशन के लिए फॉर्म एन्कोडिंग का उल्लेख करता है। पुनीकोड DNS संगतता के लिए प्रतिशत चिह्नों के बिना गैर-ASCII डोमेन नामों को एन्कोड करता है। डोमेन 😀.उदाहरण "xn--js8h.example" बन जाता है। फॉर्म एन्कोडिंग एक अपवाद के साथ प्रतिशत-एन्कोडिंग को संशोधित करती है: रिक्त स्थान %20 के बजाय प्लस चिह्न बन जाते हैं। एप्लिकेशन के रूप में सबमिट किए गए फॉर्म/x-www-form-urlencoded रिक्त स्थान के लिए प्लस का उपयोग करें।
URL एनकोडर टूल सभी तीन मोड दिखाता है: घटक एन्कोडिंग, संपूर्ण-URL एन्कोडिंग, और फॉर्म एन्कोडिंग। EncodeURIComponent के साथ घटक एन्कोडिंग, क्वेरी मानों के लिए उपयुक्त डिलीमीटर सहित प्रत्येक विशेष वर्ण को एन्कोड करता है। एन्कोडयूआरआई के साथ संपूर्ण-URL एन्कोडिंग संपूर्ण URL के लिए संरचनात्मक वर्णों को संरक्षित करती है। फॉर्म एन्कोडिंग POST निकायों के लिए है। प्रत्येक UTF-8 का उपयोग करता है; वे केवल इस बात में भिन्न होते हैं कि कौन से बाइट्स अनएन्कोडेड रह जाते हैं।
पुनीकोड और फॉर्म एन्कोडिंग: सहोदर मानक, प्रतिशत-एन्कोडिंग एक्सटेंशन नहीं
बाइट परिप्रेक्ष्य URL रहस्यों को हल करता है। एक इमोजी को बारह अक्षरों की आवश्यकता क्यों है? क्योंकि UTF-8 चार बाइट्स का उपयोग करता है, प्रत्येक %HH बन जाता है। कुछ URL में स्लैश के लिए %2F क्यों हैं जबकि अन्य में सादे स्लैश हैं? क्योंकि एन्कोडिंग मोड निर्णय लेता है: पथ खंड में एक स्लैश अनएन्कोडेड रहता है, लेकिन गलत पढ़ने से बचने के लिए क्वेरी मान के अंदर यह %2F होना चाहिए।
पूर्वानुमानित प्रतिशत-एन्कोडिंग के लिए बाइट्स में सोचें। एक अक्षर एक यूनिकोड कोड बिंदु है। UTF-8 इसका बाइट प्रतिनिधित्व है। प्रतिशत-एन्कोडिंग ट्रांसमिशन प्रारूप है। वर्ण विस्तार UTF-8 परत पर होता है। हेक्स केस डिकोडिंग को प्रभावित नहीं करता है लेकिन कैरेक्टर केस प्रभावित करता है। सख्त उपसर्ग नियमों के कारण अमान्य बाइट अनुक्रम UTF-8 पर विफल हो जाते हैं। URL एनकोडर टूल इस प्रगति को दिखाता है।
टेकअवे: बाइट्स में सोचें - कैसे URL एनकोडर और डिकोडर ब्राउज़र में आपके द्वारा पेस्ट किए गए किसी भी टेक्स्ट के लिए सटीक %XX आउटपुट दिखाता है
कार्यान्वित उदाहरण: एन्कोडिंग "कैफ़े 😀"। कैफ़े शब्द में c, a, f अक्षर ASCII एकल बाइट्स हैं: 63, 61, 66। é UTF-8 दो बाइट्स है: C3 A9। अंतरिक्ष 20 है। इमोजी 😀 चार बाइट्स है: F0 9F 98 80। अनारक्षित ASCII अक्षर दृश्यमान रहते हैं। परिणाम: "caf%C3%A9%20%F0%9F%9880"। इससे पता चलता है कि क्यों एक इमोजी बारह अक्षरों तक फैल जाता है।
टेकअवे: बाइट्स में सोचें, अक्षरों में नहीं। प्रतिशत-एन्कोडिंग UTF-8 एन्कोडिंग के बाद लागू की जाती है। प्रत्येक बाइट %HH हो जाता है। चर-लंबाई UTF-8 का अर्थ है कि वर्ण अलग-अलग विस्तारित होते हैं: ASCII %XX (दो अक्षर) बन जाते हैं, दो-बाइट उच्चारण %XX%XX (छह अक्षर) बन जाते हैं, चार-बाइट इमोजी बन जाते हैं %XX%XX%XX%XX (बारह अक्षर)। टेक्स्ट को URL एनकोडर टूल में पेस्ट करें और प्रगति का निरीक्षण करें।