पृष्ठभूमि (आगे सवाल नीचे)
मैं इसे आगे पीछे करने के लिए RFCs और SO पढ़ने की कोशिश कर रहा हूं, इसे क्रैक करने की कोशिश कर रहा हूं, लेकिन मुझे अभी भी जैक नहीं मिला है।
इसलिए मुझे लगता है कि हम सिर्फ "सर्वश्रेष्ठ" उत्तर के लिए वोट देते हैं और यह है, या?
मूल रूप से यह इस पर फोड़ा है।
3.4। क्वेरी घटक
क्वेरी घटक संसाधन द्वारा व्याख्या की जाने वाली जानकारी का एक स्ट्रिंग है।
query = *uricएक क्वेरी घटक के भीतर, वर्ण ",", "/", "?", ":", "@", "&", "=", "+", "," और "$" आरक्षित हैं।
पहली बात जो मुझे चकित करती है वह यह है कि * यूरिक को इस तरह परिभाषित किया जाता है
uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
यह हालांकि कुछ पैराग्राफों द्वारा स्पष्ट किया गया है जैसे कि
ऊपर "आरक्षित" सिंटैक्स वर्ग उन वर्णों को संदर्भित करता है जो एक यूआरआई के भीतर अनुमत होते हैं, लेकिन जो सामान्य यूआरआई सिंटैक्स के किसी विशेष घटक के भीतर अनुमति नहीं दी जा सकती है; उनका उपयोग धारा 3 में वर्णित घटकों के परिसीमन के रूप में किया जाता है।
"आरक्षित" सेट में वर्ण सभी संदर्भों में आरक्षित नहीं हैं। किसी भी यूआरआई घटक के भीतर वास्तव में आरक्षित वर्णों का समूह उस घटक द्वारा परिभाषित किया गया है। सामान्य तौर पर, यदि URI के ASCII एन्कोडिंग एन्कोडिंग के साथ चरित्र को बदल दिया जाता है, तो एक वर्ण आरक्षित होता है, यदि URI का शब्दार्थ बदल जाता है।
यह अंतिम अंश कुछ पीछे की ओर महसूस होता है, लेकिन यह स्पष्ट रूप से बताता है कि आरक्षित वर्ण सेट संदर्भ पर निर्भर करता है। फिर भी 3.4 बताता है कि सभी आरक्षित वर्ण एक क्वेरी घटक के भीतर आरक्षित हैं, हालांकि, केवल वही चीजें जो यहां शब्दार्थ को बदल देंगी, प्रश्न चिह्न (?) से बच रही है क्योंकि यूआरआई एक क्वेरी स्ट्रिंग की अवधारणा को परिभाषित नहीं करते हैं।
इस बिंदु पर मैंने RFC पर पूरी तरह से छोड़ दिया है लेकिन RFC 1738 विशेष रूप से दिलचस्प पाया।
एक HTTP URL फॉर्म लेता है:
http://<host>:<port>/<path>?<searchpart><पथ> और <खोजकर्ता घटक के भीतर, "/", ",?", "?" आरक्षित हैं। "/" वर्ण का उपयोग HTTP के भीतर एक श्रेणीबद्ध संरचना को नामित करने के लिए किया जा सकता है।
मैं कम से कम HTTP URL के संबंध में यह व्याख्या करता हूं कि RFC 1738 RFC 2396 को अधिगृहीत करता है। क्योंकि URI क्वेरी में क्वेरी स्ट्रिंग की कोई भी धारणा नहीं है, आरक्षित की व्याख्या वास्तव में मुझे क्वेरी स्ट्रिंग को परिभाषित करने की अनुमति नहीं देती है जैसा कि मुझे उपयोग किया जाता है। अब तक कर रहे हैं।
सवाल
यह सब तब शुरू हुआ जब मैं दूसरे संसाधन के अनुरोध के साथ संख्याओं की एक सूची पास करना चाहता था। मैं इसके बारे में ज्यादा नहीं सोचता था, और बस इसे अल्पविराम द्वारा अलग किए गए मानों के रूप में पारित करता था। मेरे आश्चर्य से हालांकि कोमा बच गया था। page.html?q=1,2,3एन्कोड किया गया क्वेरी page.html?q=1%2C2%2C3काम में बदल गया , लेकिन यह बदसूरत है और इसकी उम्मीद नहीं थी। तभी मैंने RFC से गुजरना शुरू किया।
मेरा पहला सवाल यह है कि क्या वास्तव में कॉमा को एन्कोडिंग करना आवश्यक है?
मेरा जवाब, RFC 2396 के अनुसार: हाँ, RFC 1738 के अनुसार: नहीं
बाद में मुझे अनुरोधों के बीच सूचियों के पारित होने के संबंध में संबंधित पोस्ट मिलीं। जहां सीएसवी दृष्टिकोण खराब के रूप में तैयार किया गया था। इसके बजाय यह दिखा, (इससे पहले यह नहीं देखा गया है)।
page.html?q=1;q=2;q=3
मेरा दूसरा प्रश्न, क्या यह एक मान्य URL है?
मेरा जवाब, RFC 2396 के अनुसार: नहीं, RFC 1738 के अनुसार: नहीं (; आरक्षित है)
जब तक यह संख्या है, तब तक सीएसवी को पास करने के साथ मेरे पास कोई समस्या नहीं है, लेकिन हाँ यदि आप कॉमा को अचानक किसी और चीज की आवश्यकता होती है, तो आप आगे और पीछे के मानों को एनकोड और डिकोड करने के जोखिम में दौड़ते हैं। वैसे भी मैंने ASP.NET के साथ अर्ध-कोलन क्वेरी स्ट्रिंग स्ट्रिंग की कोशिश की और परिणाम वह नहीं था जिसकी मुझे उम्मीद थी।
Default.aspx?a=1;a=2&b=1&a=3
Request.QueryString["a"] = "1;a=2,3"
Request.QueryString["b"] = "1"
मैं यह देखने में विफल हूं कि यह एक सीएसवी दृष्टिकोण से कैसे भिन्न होता है जब मैं "ए" के लिए पूछता हूं तो मुझे इसमें कॉमा के साथ एक स्ट्रिंग मिलती है। ASP.NET निश्चित रूप से एक संदर्भ कार्यान्वयन नहीं है, लेकिन इसने मुझे अभी तक निराश नहीं किया है।
लेकिन सबसे महत्वपूर्ण बात - मेरा तीसरा प्रश्न - इसके लिए विनिर्देश कहाँ है? और आप क्या करेंगे या उस मामले के लिए नहीं करेंगे?