कभी-कभी रिक्त स्थान URL को +साइन इन करने के लिए एन्कोडेड हो जाते हैं, कुछ समय के लिए %20। क्या अंतर है और ऐसा क्यों होना चाहिए?
जवाबों:
+केवलapplication/x-www-form-urlencoded सामग्री में स्थान का अर्थ है, जैसे कि URL का क्वेरी भाग:
http://www.example.com/path/foo+bar/path?query+name=query+value
इस URL में, पैरामीटर नाम है query nameएक स्थान के साथ और मूल्य है query valueएक स्थान के साथ है, लेकिन रास्ते में फ़ोल्डर नाम का शाब्दिक है foo+bar, नहीं foo bar ।
%20इन संदर्भों में से किसी एक स्थान को एन्कोड करने का एक वैध तरीका है। इसलिए अगर आपको URL के भाग में शामिल करने के लिए एक स्ट्रिंग-URL को एनकोड करना है, तो हमेशा रिक्त स्थान को %20और pluses के साथ बदलना सुरक्षित है %2B। यह वह है जैसे। encodeURIComponent()जावास्क्रिप्ट में करता है। दुर्भाग्य से यह नहीं है कि PHP में urlencode क्या करता है ( rawurlencode अधिक सुरक्षित है)।
इसके अलावा HTML 4.01 विनिर्देश आवेदन / x-www-form-urlencoded देखें
query+name=query+valueएक फॉर्म से एक पैरामीटर बनाएगा <input name="query name" value="query value">। यह query%20nameएक फॉर्म से नहीं बनेगा , लेकिन इसके बजाय इसका उपयोग करना पूरी तरह से सुरक्षित है, जैसे। यदि आप एक फॉर्म जमा कर रहे हैं तो आप स्वयं के लिए XMLHttpRequest। यदि आपके पास इसमें जगह के साथ एक URL है, जैसे <a href="http://www.example.com/foo bar/">, तो ब्राउज़र %20आपको अपनी गलती को ठीक करने के लिए एन्कोड करेगा , लेकिन यह शायद सबसे अच्छा पर निर्भर नहीं है।
foo barके लिए foo+bar?
encodeURIComponent(s).replace(/%20/g, '+')अगर आपको वास्तव में जरूरत है+
http://www.example.com/some/path/to/resource?param1=value1
प्रश्न चिह्न से पहले का हिस्सा% एन्कोडिंग (इसलिए %20स्थान के लिए) का उपयोग करना चाहिए , प्रश्न चिह्न के बाद आप %20या तो +अंतरिक्ष के लिए उपयोग कर सकते हैं । यदि आपको +प्रश्न चिह्न के उपयोग के बाद वास्तविक की आवश्यकता है %2B।
decodeURIComponentयह डिकोड नहीं करता है।
+एक आरक्षित चरित्र है, यह ब्राउज़र द्वारा संरक्षित किया जाएगा।
+डिफ़ॉल्ट रूप से ( { foo: 'bar bar'}.to_query=> foo=bar+bar)
तो, यहाँ उत्तर सभी थोड़े अधूरे हैं। URL में किसी स्थान को एनकोड करने के लिए '% 20' के उपयोग को RFC3986 में स्पष्ट रूप से परिभाषित किया गया है , जो परिभाषित करता है कि एक URI कैसे बनाया जाता है। एन्कोडिंग रिक्त स्थान के लिए '+' का उपयोग करने के इस विनिर्देश में कोई उल्लेख नहीं है - यदि आप इस विनिर्देश द्वारा पूरी तरह से चलते हैं, तो एक स्थान को '% 20' के रूप में एन्कोड किया जाना चाहिए।
एन्कोडिंग रिक्त स्थान के लिए '+' का उपयोग करने का उल्लेख HTML विनिर्देश के विभिन्न अवतारों से आता है - विशेष रूप से सामग्री प्रकार 'आवेदन / x-www-form-urlencoded' अनुभाग में। इसका उपयोग फॉर्म डेटा पोस्ट करने के लिए किया जाता है।
अब, HTML 2.0 विनिर्देश (RFC1866) ने स्पष्ट रूप से खंड 8.2.2 में कहा है, कि GET अनुरोध के URL स्ट्रिंग के क्वेरी भाग को 'एप्लिकेशन / x-www-form-urlencoded' के रूप में एन्कोड किया जाना चाहिए। यह, सिद्धांत में, यह सुझाव देता है कि क्वेरी स्ट्रिंग ('?') के बाद URL में '+' का उपयोग करना कानूनी है।
लेकिन ... क्या यह वास्तव में है? याद रखें, HTML स्वयं एक सामग्री विनिर्देश है, और क्वेरी के साथ URL का उपयोग HTML के अलावा अन्य सामग्री के साथ किया जा सकता है। इसके अलावा, जब HTML संस्करण के बाद के संस्करण '+' को 'एप्लीकेशन / x-www-form-urlencoded' सामग्री में कानूनी के रूप में परिभाषित करना जारी रखते हैं, तो वे पूरी तरह से यह कहते हुए भाग छोड़ देते हैं कि GET अनुरोध क्वेरी स्ट्रिंग्स को उस प्रकार के रूप में परिभाषित किया गया है। वास्तव में, HTML 2.0 कल्पना के बाद किसी भी चीज़ में क्वेरी स्ट्रिंग एन्कोडिंग के बारे में कोई उल्लेख नहीं है।
जो हमें प्रश्न के साथ छोड़ देता है - क्या यह वैध है? निश्चित रूप से विरासत कोड का एक बहुत कुछ है जो क्वेरी तार में '+' का समर्थन करता है, और बहुत सारे कोड जो इसे भी उत्पन्न करता है। यदि आप '+' का उपयोग करते हैं तो ऑड्स अच्छा है, आप नहीं टूटेंगे। (और, वास्तव में, मैंने हाल ही में इस पर सभी शोध किए क्योंकि मैंने एक प्रमुख साइट की खोज की जो एक अंतरिक्ष के रूप में जीईटी क्वेरी में '% 20' को स्वीकार करने में विफल रही। वे वास्तव में किसी भी प्रतिशत एन्कोडेड वर्ण को डिकोड करने में विफल रहे। इसलिए सेवा। 'का उपयोग करना प्रासंगिक भी हो सकता है।'
लेकिन विनिर्देशों के एक शुद्ध पढ़ने से, बाद में संस्करणों में HTML 2.0 विनिर्देश से भाषा के बिना, URL पूरी तरह से RFC3986 द्वारा कवर किए गए हैं, जिसका अर्थ है कि रिक्त स्थान को '% 20' में परिवर्तित किया जाना चाहिए। और निश्चित रूप से यह मामला होना चाहिए अगर आप एक HTML दस्तावेज़ के अलावा कुछ भी अनुरोध कर रहे हैं।
%20( <a href="?q=a b">), लेकिन जब आप एक फॉर्म भेजते हैं, तो यह +साइन का उपयोग करता है । आप +साइन का उपयोग करके स्पष्ट रूप से ( <a href="?q=a+b">), या उपयोग करके फ़ॉर्म भेजकर ओवरराइड कर सकते हैं XMLHTTPRequest।
इसकी जगह हमेशा% 20 के रूप में रिक्त स्थान को एनकोड करती है, "+" के रूप में नहीं।
यह RFC-1866 (HTML 2.0 विनिर्देशन) था, जो निर्दिष्ट करता था कि अंतरिक्ष वर्णों को "+" के रूप में "एप्लिकेशन / x-www-form-urlencoded" सामग्री-प्रकार की-वैल्यू जोड़े में एन्कोड किया जाना चाहिए। (पैरा 8.2.1 देखें। सबपर पैरा 1.)। प्रपत्र डेटा एन्कोडिंग का यह तरीका बाद के HTML विनिर्देशों में भी दिया गया है, एप्लिकेशन / x-www-form-urlencoded के बारे में प्रासंगिक पैराग्राफ देखें।
यहां URL में ऐसी स्ट्रिंग का एक उदाहरण है जहां RFC-1866 प्लस के रूप में एन्कोडिंग रिक्त स्थान की अनुमति देता है: "http://example.com/over/there?name=foo+bar"। तो, केवल "?" के बाद, रिक्त स्थान को RFC-1866 के अनुसार, प्लसस द्वारा प्रतिस्थापित किया जा सकता है। अन्य मामलों में, रिक्त स्थान को 20% तक एन्कोड किया जाना चाहिए। लेकिन चूंकि यह संदर्भ निर्धारित करना कठिन है, इसलिए रिक्त स्थान को कभी भी "+" के रूप में एनकोड करना सबसे अच्छा अभ्यास है।
मैं RFC-3986, p.2.3 में परिभाषित "अनारक्षित" को छोड़कर सभी वर्णों को प्रतिशत-सांकेतिक शब्दों में बदलना चाहूंगा
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
क्या अंतर है: अन्य उत्तर देखें।
+इसके बजाय कब उपयोग करें %20? उपयोग करें +, यदि किसी कारण से, आप URL क्वेरी स्ट्रिंग ( ?.....) या हैश टुकड़ा ( #....) को अधिक पठनीय बनाना चाहते हैं। उदाहरण: आप वास्तव में इसे पढ़ सकते हैं:
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
( %2B= +)
लेकिन पढ़ने के लिए निम्नलिखित बहुत कठिन है: (कम से कम मेरे लिए)
मुझे लगता +है कि कुछ भी टूटने की संभावना नहीं है, क्योंकि Google उपयोग करता है +(ऊपर दिए गए लिंक को देखें) और उन्होंने शायद इस बारे में सोचा है। मैं +खुद को सिर्फ इसलिए इस्तेमाल करने जा रहा हूं क्योंकि पठनीय + Google को लगता है कि यह ठीक है।