डेवलपर टूल · URL एनकोडर और डिकोडर
फ़ाइल डाउनलोड लिंक में रिक्त स्थान: %20, + और कच्चा स्थान समान क्यों नहीं हैं
· यह क्यों मायने रखती है
URL एन्कोडिंग http डेवलपर-वर्कफ़्लो
'Q3 रिपोर्ट (अंतिम).pdf' नामक फ़ाइल को तीन अलग-अलग तरीकों से जोड़ा जा सकता है, और केवल एक ही विश्वसनीय रूप से सही है। यह पोस्ट बताती है कि फ़ाइल नाम डाउनलोड लिंक को क्यों तोड़ते हैं और उन्हें कैसे एन्कोड किया जाए ताकि हर ग्राहक सहमत हो।
डाउनलोड जो कुछ उपयोगकर्ताओं के लिए विफल रहता है और दूसरों के लिए काम करता है - रिक्त स्थान और प्लस चिह्न के साथ एक फ़ाइल नाम
"Q3 report.pdf" जैसी फ़ाइलें स्थानीय रूप से संग्रहीत होने पर ठीक काम करती हैं लेकिन कुछ उपयोगकर्ताओं के लिए डाउनलोड लिंक के माध्यम से विफल हो जाती हैं जबकि अन्य बिना किसी समस्या के सफल हो जाती हैं। RFC 3986 विनिर्देशन के अनुसार URL में कच्चे स्थान अमान्य हैं। ब्राउज़र इन्हें एड्रेस बार में सहन कर लेते हैं लेकिन HTTP क्लाइंट इन्हें सख्ती से अस्वीकार कर देते हैं। विश्वसनीय वितरण के लिए %20, प्लस चिह्न और कच्चे रिक्त स्थान को समझना नितांत आवश्यक है। एन्कोडिंग विधियों के बीच अंतर दुनिया भर में विभिन्न प्लेटफार्मों, विभिन्न स्वचालन टूलींग और HTTP क्लाइंट कार्यान्वयन पर डाउनलोड सफलता दर को सीधे प्रभावित करता है। डाउनलोड सिस्टम बनाते समय डेवलपर्स को इस अंतर को समझना चाहिए। एन्कोडिंग विकल्पों और सिस्टम अनुकूलता के लिए संदर्भ मायने रखता है।
डाउनलोड लिंक बनाते समय डेवलपर्स को रॉ स्पेस, %20, या प्लस चिह्नों के बीच चयन करना होगा। कर्ल, विगेट और पायथन के साथ परीक्षण से पता चलता है कि कौन से ग्राहक RFC अनुपालन लागू करते हैं। त्रुटि पुनर्प्राप्ति के कारण ब्राउज़र डाउनलोड सफल हो जाते हैं, लेकिन अनएन्कोडेड रिक्त स्थान का सामना करने पर API एकीकरण विफल हो जाते हैं।
URL में रॉ स्पेस अमान्य क्यों है - और ब्राउज़र इसे एड्रेस बार में क्यों सहन करते हैं लेकिन HTTP क्लाइंट नहीं करते
URL में कच्चे स्थानों की प्रोटोकॉल डिज़ाइन में ऐतिहासिक जड़ें हैं। URL टोकन के बीच रिक्त स्थान को सीमांकक के रूप में मानते हुए सिस्टम को पार करते हैं। URL में एक स्थान को इसके टर्मिनेटर के रूप में गलत समझा जा सकता है। HTTP कमांड लाइन से पढ़ने वाले क्लाइंट पहले स्थानों पर काट-छांट करते हैं। यह मूलभूत डिज़ाइन प्रोटोकॉल कार्यान्वयन में बना हुआ है और इसमें बदलाव की संभावना नहीं है।
ब्राउज़र HTTP अनुरोध भेजने से पहले %20 में मौन रूपांतरण के माध्यम से कच्चे स्थान को सहन करते हैं। यह उपयोगकर्ता-अनुकूल व्यवहार URL को एड्रेस बार में चिपकाने वाले अंतिम उपयोगकर्ताओं से प्रोटोकॉल आवश्यकताओं को छुपाता है। स्वचालित सिस्टम में इस पुनर्प्राप्ति परत का अभाव होता है। अपरिष्कृत रिक्त स्थान वाले URL पर स्क्रिप्ट विफल हो जाती हैं। ईमेल क्लाइंट को ऐसे लिंक खोलने में विफलता का सामना करना पड़ता है।
पथ खंड में %20 बनाम + - फॉर्म-एन्कोडिंग कन्वेंशन जो पथों पर लागू नहीं होता है
%20 बनाम प्लस चिह्न URL एन्कोडिंग संदर्भों में एक बुनियादी अंतर दर्शाता है। पथ खंडों में, रिक्त स्थान को %20 प्रति RFC 3986 के रूप में एन्कोड किया जाना चाहिए। प्लस चिन्ह पथों में स्पेस एन्कोडिंग नहीं है। यह कन्वेंशन HTML फॉर्म एन्कोडिंग में उत्पन्न हुआ जहां यह क्वेरी स्ट्रिंग्स में स्पेस एन्कोडिंग के रूप में कार्य करता है। डेवलपर्स अक्सर पथों पर फ़ॉर्म नियमों को गलत तरीके से लागू करते हैं।
प्लस चिन्हों की अनुमति देने वाली फॉर्म-एन्कोडिंग परंपराएँ विभिन्न संरचनात्मक आवश्यकताओं वाले पथों पर लागू नहीं होती हैं। क्वेरी स्ट्रिंग्स में, एम्परसेंड और बराबर सीमांकित पैरामीटर। क्वेरी मानों में रिक्त स्थान के लिए प्लस का उपयोग करने से कोई अस्पष्टता नहीं पैदा होती क्योंकि प्लस एक सीमांकक नहीं है। पथों में प्लस का कोई विशेष अर्थ नहीं है। परंपराओं को मिलाने से टूटे हुए डाउनलोड लिंक बनते हैं।
गैर-ASCII फ़ाइल नाम - UTF-8 प्रतिशत-एन्कोडिंग और ऑब्जेक्ट स्टोरेज कुंजियाँ जो कच्चे नाम को संग्रहीत करती हैं
गैर-ASCII फ़ाइलनामों को URL में सुरक्षित ट्रांसमिशन से पहले UTF-8 प्रतिशत-एन्कोडिंग की आवश्यकता होती है। "Über report.pdf" जैसे फ़ाइल नाम में ASCII कैटेगरी के बाहर "Ü" (U+00DC) होता है। UTF-8 एन्कोडिंग इसे बाइट्स C3 9C में परिवर्तित करती है। ये बाइट्स URL में %C3%9C के रूप में प्रतिशत-एनकोड करते हैं। प्रत्येक UTF-8 बाइट को अपना स्वयं का ट्रिपलेट मिलता है, जो लंबे एन्कोडेड फ़ाइल नाम उत्पन्न करता है।
Amazon S3 जैसी ऑब्जेक्ट स्टोरेज सेवाएँ गैर-ASCII फ़ाइल नामों के लिए दिलचस्प मामले प्रस्तुत करती हैं। कुछ सिस्टम कुंजियों में कच्चे UTF-8 बाइट्स की अनुमति देते हैं जबकि अन्य को प्रतिशत-एन्कोडिंग की आवश्यकता होती है। एन्कोडिंग रणनीति भंडारण प्रदाताओं और URL उपयोग पर निर्भर करती है। URL-आधारित पहुंच के लिए प्रतिशत-एन्कोडेड UTF-8 की आवश्यकता होती है। डेवलपर्स को भंडारण और URL पीढ़ी परतों का समन्वय करना होगा।
कार्यान्वित उदाहरण: एक पथ के लिए 'Über Q3 रिपोर्ट (अंतिम)+notes.pdf' एन्कोडिंग - सटीक आउटपुट और क्यों + को %2B बनना चाहिए
कार्यान्वित उदाहरण: एन्कोडिंग "Über रिपोर्ट (अंतिम)+notes.pdf" पूर्ण एन्कोडिंग को प्रदर्शित करता है। फ़ाइल नाम में रिक्त स्थान, गैर-ASCII वर्ण और एक शाब्दिक प्लस शामिल है। "Ü" की UTF-8 एन्कोडिंग %C3%9C उत्पन्न करती है। पथ एन्कोडिंग में, रिक्त स्थान %20 बन जाते हैं (प्लस का उपयोग करके फॉर्म एन्कोडिंग के विपरीत)। शाब्दिक प्लस %2B हो जाता है। कोष्ठक %28 और %29 के रूप में एन्कोड करते हैं। परिणाम: %C3%9CberQ3%20रिपोर्ट%20%28अंतिम%29%2Bnotes.pdf।
URL एनकोडर और डिकोडर के साथ परीक्षण सटीक परिवर्तन दिखाता है। फ़ाइल नाम को एकल-मान मोड में चिपकाने से पथ नियमों का उपयोग करके सही प्रतिशत-एन्कोडेड सेगमेंट उत्पन्न होते हैं। टूल केवल फ़ाइल नाम घटकों को एन्कोड करते समय पथ सीमांकक को संरक्षित करता है। इनपुट और आउटपुट की दृश्य तुलना उत्पादन से पहले नियमों को स्पष्ट और सत्यापन योग्य बनाती है। संदर्भ अंतर देखने के लिए इसकी तुलना फॉर्म मोड से करें।
सामग्री-विस्थापन और फ़ाइल नाम* पैरामीटर - डाउनलोड प्रॉम्प्ट के लिए एक अलग एन्कोडिंग, पूर्णता के लिए उल्लिखित
सामग्री-विस्थापन और फ़ाइल नाम* पैरामीटर डाउनलोड संकेतों के लिए वैकल्पिक एन्कोडिंग परतों का प्रतिनिधित्व करते हैं। सर्वर में डाउनलोड संवादों के लिए फ़ाइल नाम निर्दिष्ट करने वाले सामग्री-विस्थापन शीर्षलेख शामिल हैं। फ़ाइल नाम पैरामीटर RFC 2183 एन्कोडिंग का उपयोग करता है जबकि फ़ाइल नाम* प्रतिशत-एन्कोडिंग के साथ RFC 5987 का उपयोग करता है। सेव-फ़ाइल नाम तय करने के लिए ब्राउज़र इन हेडर की व्याख्या करते हैं। एक ही फ़ाइल नाम अलग-अलग योजनाओं के साथ दो बार एन्कोड होता है।
दो एन्कोडिंग परतें ट्रांसकोडिंग त्रुटियों के अवसर पैदा करती हैं। यदि सर्वर और क्लाइंट असहमत हैं तो URL-एन्कोडेड और हेडर-एनकोडेड फ़ाइल नाम सही ढंग से राउंड-ट्रिप नहीं हो सकते हैं। अधिकतम अनुकूलता के लिए, डेवलपर्स को %20 और UTF-8 प्रतिशत-एन्कोडिंग का उपयोग करके URL पथों में फ़ाइल नामों को एन्कोड करना चाहिए, और डिकोड किए गए फ़ाइल नामों के साथ सामग्री-डिस्पोज़िशन हेडर सेट करना चाहिए। यह सुनिश्चित करता है कि सभी HTTP क्लाइंट और ब्राउज़र सही ढंग से काम करें।
इसमें क्या शामिल नहीं है - विशिष्ट ऑपरेटिंग सिस्टम और स्टोरेज-प्रदाता विचित्रताओं पर आरक्षित फ़ाइल नाम
विशिष्ट ऑपरेटिंग सिस्टम पर आरक्षित फ़ाइल नाम URL एन्कोडिंग में जटिलता जोड़ते हैं। विंडोज़ टूलों के लिए CON, PRN, और AUX जैसे नाम सुरक्षित रखता है। शाब्दिक रूप से "CON.pdf" नाम की फ़ाइलें NTFS पर मौजूद नहीं हो सकतीं। macOS में नामकरण परंपराएँ और विस्तारित विशेषता नियम हैं। लिनक्स केस-संवेदी है. मान्य URL-एन्कोडेड फ़ाइल नाम कुछ सिस्टम पर भंडारण के लिए मान्य नहीं हो सकते हैं।
भंडारण-प्रदाता की विचित्रताएं क्रॉस-प्लेटफ़ॉर्म वितरण में जटिलता जोड़ती हैं। Amazon S3 UTF-8 कुंजी स्वीकार करता है और केस-संवेदी है। Google क्लाउड स्टोरेज अतिरिक्त प्रतिबंधों के साथ समान व्यवहार करता है। Azure ब्लॉब स्टोरेज के अलग-अलग वर्ण नियम हैं। S3 पर काम करने वाले फ़ाइल नाम Azure पर विफल हो सकते हैं। आर्किटेक्ट्स को प्रदाता दस्तावेज़ की जांच करनी चाहिए और वास्तविक गैर-ASCII फ़ाइल नामों के साथ परीक्षण करना चाहिए।
टेकअवे: सेगमेंट को एनकोड करें, URL को नहीं - कैसे URL एनकोडर और डिकोडर का सिंगल-वैल्यू मोड एक पथ-सुरक्षित फ़ाइल नाम उत्पन्न करता है
टेकअवे: सेगमेंट को एनकोड करें, URL को नहीं—URL एनकोडर और डिकोडर सिंगल-वैल्यू मोड पथ-सुरक्षित फ़ाइल नाम उत्पन्न करता है। टूल कच्चे फ़ाइल नामों को स्वीकार करता है और प्रतिशत-एन्कोडेड सेगमेंट तैयार करता है। यह डबल-एन्कोडिंग और संदर्भों के मिश्रण को रोकता है। एकल-मूल्य मोड का उपयोग करने से पथ, क्वेरी और खंड एन्कोडिंग नियमों को संतुलित करने से बचा जाता है। जेनरेट किए गए सेगमेंट URL में डालने के लिए सुरक्षित हैं।
सर्वोत्तम अभ्यास फ़ाइल नामों को एन्कोड करता है जहां वे URL निर्माण दर्ज करते हैं। यह न मानें कि ब्राउज़र एन्कोडिंग समस्याओं को ठीक कर देते हैं। लक्षित उपयोगकर्ताओं द्वारा उपयोग किए जाने वाले वास्तविक HTTP क्लाइंट के साथ परीक्षण करें: कर्ल, wget, पायथन, जावा httplib, और ब्राउज़र फ़ेच APआई। सत्यापित करें कि फ़ाइल नाम पूरे सिस्टम में राउंड-ट्रिपिंग से बचे रहते हैं। URL एनकोडर और डिकोडर शुद्धता सुनिश्चित करने वाला प्रारंभिक बिंदु है।