डेवलपर टूल · URL एनकोडर और डिकोडर
प्लस बनाम %20: एप्लिकेशन का इतिहास/x-www-form-urlencoded
· पेजभूमि
URL एन्कोडिंग HTML रूपों http-मानक
प्रपत्र किसी स्थान को + के रूप में एन्कोड करते हैं जबकि URI मानक %20 कहते हैं, और इसका कारण ऐतिहासिक है। यह पोस्ट प्रारंभिक HTML रूपों से लेकर आज की WHATWG परिभाषा तक परंपरा का पता लगाती है और बताती है कि यह कभी दूर क्यों नहीं हुई।
प्लस बनाम %20—क्यों फॉर्म और यूआरआई रिक्त स्थान को अलग-अलग तरीके से एन्कोड करते हैं
HTML फॉर्म GET के रूप में सबमिट किए गए हैं और क्वेरी स्ट्रिंग में रिक्त स्थान को प्लस चिह्न के रूप में एन्कोड किया गया है। RFC 3986 के बाद URL में वही स्थान %20 हो जाता है। दोनों सही हैं क्योंकि वे अलग-अलग मानकों का पालन करते हैं। रिक्त स्थान वाले फॉर्म फ़ील्ड फॉर्म एन्कोडिंग में नाम = मान + के साथ + रिक्त स्थान बन जाते हैं लेकिन RFC 3986 में %20। प्लस-प्रतिशत-बीस भेद चिह्न जो मानक आपके डेटा पर लागू होता है।
फॉर्म एन्कोडिंग RFC 1866 (1995), HTML 2.0 की मूल फॉर्म सबमिशन परिभाषा से ऐतिहासिक सम्मेलन के रूप में रिक्त स्थान के लिए प्लस का उपयोग करता है। GET एन्कोडेड स्थानों को प्लस चिह्न के रूप में अनुरोध करता है, प्लस को अक्षरशः के लिए आरक्षित करता है + %2B के रूप में एन्कोड किया जाता है। यह नियम केवल एप्लिकेशन/x-www-form-urlencoded, पर लागू होता है, सामान्य URI सिंटैक्स पर नहीं। अरबों सर्वर ढाँचे इस सम्मेलन पर निर्भर हो गये। दोनों का परीक्षण करने से स्पष्ट अंतर पता चलता है: फॉर्म मोड प्लस उत्पन्न करता है; URI मोड %20 उत्पन्न करता है। URL एनकोडर और डिकोडर सीधे तुलना करने के लिए दोनों मोड प्रदान करता है।
प्रारंभिक HTML फॉर्म और GET सबमिशन - फॉर्म एन्कोडिंग को कैसे परिभाषित किया गया था और + को क्यों चुना गया था
RFC 1866 (1995) परिभाषित फॉर्म सबमिशन जहां रिक्त स्थान प्लस बन जाते हैं और शाब्दिक प्लस %2B हो जाता है। यह केवल एप्लिकेशन/x-www-form-urlencoded. RFC 3986 पर लागू होता है, जो सामान्य URI सिंटैक्स के लिए निर्दिष्ट %20 है। दो मानक जानबूझकर सह-अस्तित्व में थे।
RFC 2396 ने पहले के मानकों की तुलना में अधिक कठोरता से वर्ण सेट को स्पष्ट किया। इसने URI संरचना बनाम अनारक्षित को शाब्दिक डेटा के रूप में परोसने वाले आरक्षित वर्णों को औपचारिक रूप दिया। जैसे-जैसे ब्राउज़र और प्रॉक्सी व्यवहार विकसित होता है, मानक निकाय उसे संहिताबद्ध करते हैं। RFC 3986 एन्कोडिंग व्यवहार को बदले बिना, केवल संकेतन को स्पष्ट करते हुए, बाद में आया। सभी मौजूदा ब्राउज़र UTF-8 एन्कोडिंग पर मानकीकृत हैं। सबमिट बटन के माध्यम से HTML फॉर्म रिक्त स्थान के प्लस के साथ आवेदन /x-www-form-urlencoded प्रारूप में भेजें। मैन्युअल URI निर्माण %20 का उपयोग करता है। दोनों मानकों को समझना एकीकरण आश्चर्य को रोकता है।
RFC 1866 और बाद के HTML विनिर्देश - जहां नियम लिखा गया था और यह URI सिंटैक्स से कैसे अलग हुआ
WHATWG URL मानक निर्दिष्ट करता है URLSearchParams.toString() रिक्त स्थान के लिए प्लस चिह्न के साथ एप्लिकेशन/x-www-form-urlencoded आउटपुट उत्पन्न करता है। URL कंस्ट्रक्टर प्रतिशत-एनकोड RFC 3986 के बाद करता है। ब्राउज़र स्पेस एन्कोड के साथ URL पर नेविगेट कर रहा है %20; GET एनकोड प्लस के रूप में सबमिट किया गया फॉर्म। ये मौलिक रूप से अलग-अलग टूल अलग-अलग उद्देश्यों की पूर्ति करते हैं। मैनुअल एन्कोडयूआरआईकंपोनेंट रिक्त स्थान के लिए %20 देता है—RFC 3986 शैली। उसी URL पर सबमिट किए गए फॉर्म प्लस भेजें। फॉर्म सबमिशन को पार्स करने वाले सर्वर प्लस की अपेक्षा करते हैं; %20 प्राप्त करने से साइलेंट पैरामीटर विफलता होती है।
दोनों का परीक्षण करने से सर्वर-साइड धारणाओं का पता चलता है जिन पर आप निर्भर हैं। JavaScript URLSearchParams सुरक्षित फॉर्म-शैली एन्कोडिंग छुपाने के साथ-साथ जटिलता भी प्रदान करता है। URLSearchParams का निर्माण करें, प्रविष्टियाँ जोड़ें, उचित प्लस के साथ application/x-www-form-urlencoded प्राप्त करने के लिए toString() पर कॉल करें। वैकल्पिक रूप से encodeURIComponent के साथ क्वेरी स्ट्रिंग बनाएं; आपको RFC 3986 %20 मिलता है। कभी भी दृष्टिकोणों का मिश्रण न करें। मैन्युअल प्लस और एनकोडयूआरआईकंपोनेंट के साथ क्वेरी स्ट्रिंग अस्पष्टता पैदा करती हैं। रिसीवर यह अंतर नहीं कर सकते कि प्लस का मतलब स्पेस है या शाब्दिक प्लस। मानक दृष्टिकोण लगातार संभालते हैं।
URL मानक आज - एप्लिकेशन/x-www-form-urlencoded अपने स्वयं के नियमों के साथ एक अलग धारावाहिक के रूप में
JSON API आमतौर पर प्लस को स्पेस के रूप में अस्वीकार कर देते हैं, %20 प्रति RFC 3986 की अपेक्षा करते हैं। प्लस भेजने वाले ग्राहक चुपचाप विफल हो जाते हैं: पैरामीटर गायब हो जाते हैं। दोनों एन्कोडिंग के साथ APआई का परीक्षण करने से पता चलता है कि वे किस मानक को स्वीकार करते हैं। JavaScript में URLSearchParams फॉर्म एन्कोडिंग को संभालता है। URL एनकोडर और डिकोडर RFC 3986 %20 उत्पन्न करता है।
HTML फ़ॉर्म सबमिशन स्वचालित रूप से एन्कोडिंग को संभालता है। आपका सर्वर फ्रेमवर्क तय करता है कि कौन से नियम लागू होंगे। रेल्स, Django, PHP सभी स्वचालित रूप से प्राप्त फॉर्म डेटा में प्लस को स्पेस के रूप में मानते हैं। लेकिन समान समापन बिंदुओं के लिए मैन्युअल रूप से क्वेरी स्ट्रिंग बनाना बेहद मायने रखता है। प्लस अपलोड करने से अस्पष्टता पैदा होती है। विशिष्टता अनुपालन और वास्तविक दुनिया सर्वर व्यवहार में थोड़ा अंतर है। दस्तावेज करें कि आपके समापन बिंदु किस मानक की अपेक्षा करते हैं। दोनों एन्कोडिंग शैलियों का परीक्षण करें। रक्षात्मक कोड दोनों को खूबसूरती से संभालता है।
कार्यान्वित उदाहरण: एक ही फॉर्म फ़ील्ड को क्वेरी स्ट्रिंग और अनुरोध निकाय के रूप में देखा जाता है - एक स्थान पर + और दूसरे स्थान पर %20 के साथ
JavaScript URLSearchParams फॉर्म-एन्कोडिंग लागू करता है: स्पेस प्लस बन जाता है, %20 नहीं। नया URLSearchParams({q: "helloworld"}) "q=hello+world" उत्पन्न करता है, न कि "q=hello%20world"। यह ऐतिहासिक अनुप्रयोग/x-www-form-urlencoded नियम है जिसे विशेष रूप से JavaScript में बनाया गया है। लेकिन इस स्ट्रिंग को नई URL में कच्ची क्वेरी के रूप में पास करने से प्लस प्लस बना रहता है; केवल URLSearchParams ही इसे स्पेस के रूप में डिकोड करता है। कंस्ट्रक्टर जो देखता है उसके प्रति वफादार होता है। फ़ंक्शंस को गलत तरीके से मिलाने पर प्लस-चिह्न अंतर सामान्य बग का कारण बनता है।
URL कंस्ट्रक्टर और encodeURIComponent अलग-अलग टूल हैं। encodeURIComponent अनारक्षित अक्षरों, अंकों और - _ को छोड़कर लगभग सभी चीज़ों को एनकोड करता है। ! ~ * ' ( ). यह कोई संदर्भ नहीं मानता. URL कंस्ट्रक्टर वास्तविक URL को पार्स करता है और प्रति घटक WHATWG नियम लागू करता है। encodeURIComponent "hello/world" को "hello%2Fworld" में बदल देता है; नया URL स्लैश को पथ विभाजक के रूप में देखता है। वही इनपुट, अलग आउटपुट। टुकड़ों को जोड़कर URL बनाते समय encodeURIComponent का उपयोग करें। पूर्ण या आंशिक URL के लिए URLSearchParams या URL कंस्ट्रक्टर का उपयोग करें।
इसे ठीक क्यों नहीं किया जा सकता - दशकों के सर्वर और क्लाइंट जो वर्तमान व्यवहार पर निर्भर हैं
प्रतिशत-एन्कोडिंग नियम RFC 1738 (1994) से RFC 2396 (1998) से RFC 3986 (2005) तक विकसित हुए। प्रत्येक पीढ़ी ने अस्पष्टताओं को स्पष्ट किया। RFC 1738 रूढ़िवादी था, पात्रों को असुरक्षित मानता था क्योंकि प्रारंभिक वेब में सीमित चरित्र समर्थन था। UTF-8 पर तैनाती मानकीकृत हो गई, कार्यान्वयन सुसंगत हो गया। बाद के मानकों ने सिस्टम में सुरक्षित साबित होने वाले पात्रों पर प्रतिबंधों में ढील दी। आधुनिक सर्वसम्मति: UTF-8 हर जगह। मानक निकाय पिछड़ी संगतता को जमकर बनाए रखते हैं। फिक्सिंग के लिए विश्वव्यापी समन्वय की आवश्यकता होगी - तीन दशकों के बाद असंभव। दो मानक जानबूझकर सह-अस्तित्व में हैं।
प्लस और %20 दोनों के साथ परीक्षण से सर्वर धारणाओं का पता चलता है। सर्वर लॉग दिखाते हैं कि ग्राहक क्या भेजते हैं। फॉर्म प्लस का उपयोग करते हैं; मैन्युअल URL %20 का उपयोग करते हैं। संदर्भ के अनुसार चुनें और API दस्तावेज़ का पालन करें।
इसमें क्या शामिल नहीं है - मल्टीपार्ट/form-data और JSON निकाय
दोनों एन्कोडिंग का परीक्षण करने से सर्वर व्यवहार का पता चलता है। a+b दोनों तरह से भेजें. कई उत्पादन सर्वर फॉर्म एन्कोडिंग की अपेक्षा करते हैं; नए APआई %20 की अपेक्षा करते हैं। आपकी पसंद प्राप्तकर्ता की अपेक्षाओं पर निर्भर करती है। URLSearchParams फॉर्म एन्कोडिंग को संभालता है; encodeURIComponent RFC एन्कोडिंग को संभालता है।
एन्कोडिंग विधियों को कभी भी संयोजित न करें। encodeURIComponent %2B के साथ एन्कोड किया गया मान, फिर URLSearchParams को पास किया गया, %252B के रूप में डबल-एनकोड किया गया है। एक बार डिकोड करने से प्लस के बजाय %2B प्राप्त होता है। वर्ण धन चिह्न के बजाय शाब्दिक प्रतिशत-दो-छह स्ट्रिंग बन जाता है। अपनी निर्माण प्रक्रिया में मध्यवर्ती चरणों की जाँच करें। एन्कोडिंग प्रति मान केवल एक बार होती है। दस्तावेज़ कि आपकी पाइपलाइन किस एन्कोडिंग मानक का उपयोग करती है। प्लस, स्पेस, एम्परसेंड सहित विशेष वर्णों के साथ परीक्षण करें।
टेकअवे: दो मानक, दोनों अपने संदर्भ में सही हैं - कैसे URL एनकोडर और डिकोडर आपको रिक्त स्थान के लिए %20 के साथ RFC 3986 फॉर्म देता है, ताकि आप जान सकें कि आप किसे देख रहे हैं
प्लस-बनाम-बीस स्प्लिट ठीक करने योग्य बग नहीं है। यह अलग-अलग समस्याओं को अलग-अलग तरीके से हल करने वाले मानकों की ऐतिहासिक कलाकृति है। फिक्सिंग के लिए विश्वव्यापी समन्वय की आवश्यकता होगी - तीस वर्षों के बाद असंभव। मानक निकाय पूर्वव्यापी रूप से वेब को नहीं तोड़ते हैं। RFC 3986, प्रपत्र नियम, ब्राउज़र URL निर्माण प्रत्येक के मानक और कारण हैं। RFC 1866 फॉर्म एन्कोडिंग और RFC 3986 URI एन्कोडिंग विभिन्न परतों की सेवा करते हैं। अपने मानक को जानबूझ कर एनकोड करें। यथार्थवादी पेलोड के विरुद्ध परीक्षण करें।
संदर्भ के अनुसार एन्कोडिंग चुनें. प्रपत्र प्लस प्रति HTML मानकों का उपयोग करते हैं। मैन्युअल यूआरआई %20 प्रति RFC 3986 का उपयोग करते हैं। APआई निर्दिष्ट करते हैं कि किसकी अपेक्षा की जाए; दस्तावेज़ीकरण का पालन करें या दोनों का परीक्षण करें। URL एनकोडर और डिकोडर RFC 3986 दिखाता है। प्रपत्र एन्कोडिंग की आवश्यकता है? URLSearchParams ऐसा करता है। टूल एन्कोडिंग को मिश्रित नहीं करता है; मानकों को समझना आश्चर्य को रोकता है। परतों के बीच एन्कोडिंग असंगतता सूक्ष्म पैरामीटर हानि, ट्रंकेशन, डेटा भ्रष्टाचार का कारण बनती है। दोनों मानक अपने क्षेत्र में सही हैं। सोच-समझकर आवेदन करें और दस्तावेज तैयार करें।