क्या URL संवेदनशील होना चाहिए?

Question

मैंने गौर किया

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK

तथा

http://stackoverflow.com/questions/ask

दोनों ठीक काम करता है - वास्तव में पिछला वाला लोअरकेस में बदल जाता है।

मुझे लगता है कि यह उपयोगकर्ता के लिए समझ में आता है।

अगर मैं Google को देखता हूं तो यह URL ठीक काम करता है:

http://www.google.com/intl/en/about/corporate/index.html  

लेकिन "ABOUT" वाला यह काम नहीं कर रहा है:

http://www.google.com/intl/en/ABOUT/corporate/index.html   

क्या URL संवेदनशील होना चाहिए?

Comments

IMHO, URL को कभी भी संवेदनशील नहीं होना चाहिए, यह केवल उन लोगों के लिए जीवन कठिन बना रहा है जो इसका उपयोग कर रहे हैं।

— मुहम्मद उमर

सवाल "मामले के प्रति संवेदनशील होना चाहिए?" यह एक बुरा सवाल है क्योंकि यह राय आमंत्रित करता है। बल्कि, एक बेहतर सवाल यह होगा कि "WHY हैं (या WHY क्यों नहीं हैं) केस-सेंसिटिव हैं?", या "क्यों कुछ यूरल्स केस-सेंसिटिव हैं जबकि अन्य नहीं हैं?"

— छुरी

लेकिन एक संभावित उत्तर के लिए, WHATWG के नए URL Standard को देखें , जो कि नोड.जेएस द्वारा अपनाया गया है ।

— छरवे २०'१

मेरी राय में, वे नहीं होना चाहिए

— एंड्रयू

यदि ब्राउज़र मामले का सम्मान नहीं करता है, तो ipfs पता टूट जाएगा, लेकिन यह टूटा नहीं है

— बेनो तुंग

Answer 1

W3 के " HTML और URL " के अनुसार उन्हें:

URL, या URL के कुछ हिस्से हो सकते हैं, जहाँ मामला कोई मायने नहीं रखता है, लेकिन इन्हें पहचानना आसान नहीं हो सकता है। उपयोगकर्ताओं को हमेशा विचार करना चाहिए कि URL केस-संवेदी हैं।

Comments

मुझे लगता है कि "आप जो भी भेजते हैं उसमें आप उदार होते हैं और जो आप भेजते हैं उसमें रूढ़िवादी होते हैं" (IETF बोलते हैं) मेरे दिशानिर्देश होंगे।

— jldupont

W3 दिशानिर्देश उचित है। यह केवल यह बताता है कि किसी को यह अनुमान नहीं लगाना चाहिए कि सर्वर उस URL को कैसे संभालता है जिसे आप सबमिट कर रहे हैं। यह सर्वर पर निर्भर है कि अनुरोध URL को कैसे संभालना है। अधिकांश वेब सर्वर यूनिक्स / लिनक्स हैं और इसका अर्थ है कि अधिकांश वेब सर्वर संवेदनशील हैं।

— o

W3 का कहना है कि USERS को यह मान लेना चाहिए कि सर्वर केस-संवेदी हैं, लेकिन SERVERS के लिए कोई अनुशंसा नहीं देता है।

— 16

पुनर्जीवन के लिए, URL की व्याख्या करने वाले कार्यक्रमों को ऊपरी मामलों के अक्षरों को योजना के नाम (जैसे "HTTP" के साथ-साथ "http" की अनुमति देते हैं) स्रोत

— realPK

@PK_ ध्यान दें कि यह केवल URL के स्कीम भाग के लिए है। RFC1738 चर्चा नहीं करता है कि URL के अन्य भागों को केस संवेदी के रूप में व्याख्या किया जाना चाहिए या नहीं।

— दशरथ अष्टक

Answer 2

पठनीयता के लिए सभी " असंवेदनशील " को बोल्ड किया जाता है।

डोमेन नाम RFC 4343 के अनुसार असंवेदनशील हैं । बाकी URL को GET विधि के माध्यम से सर्वर पर भेजा जाता है। यह मामला संवेदनशील हो सकता है या नहीं।

उदाहरण के लिए इस पृष्ठ को लें, stackoverflow.com प्राप्त करता है GET स्ट्रिंग / प्रश्न / 7996919 / चाहिए-यूआरएल-केस-संवेदी , आपके ब्राउज़र में एक HTML दस्तावेज़ भेज रहा है। Stackoverflow.com केस असंवेदनशील है क्योंकि यह / QUEStions / 7996919 / Should-url-be-case-sensitive के लिए समान परिणाम उत्पन्न करता है ।

दूसरी ओर, विकिपीडिया शीर्षक के पहले चरित्र को छोड़कर संवेदनशील है। यूआरएल https://en.wikipedia.org/wiki/Case_sensitivity और https://en.wikipedia.org/wiki/case_sensitivity एक ही लेख पर ले जाया जाता है, लेकिन https://en.wikipedia.org/wiki/CASE_SENSITIVITY रिटर्न 404।

Comments

विकिपीडिया वास्तव में उन मामलों में संवेदनशीलता के लिए बहुत क्षमाशील है जहां उपयोगकर्ता सोच सकते हैं कि एक शब्द एक मामला या दूसरा होना चाहिए, लेकिन यह ओसीडी के कारण अधिक है ... क्षमा करें, इसके संपादकों की प्रकृति पर विचार करें। इसके URL तकनीकी रूप से बहुत संवेदनशील हैं, हालाँकि।

— trysis

ऐसा इसलिए है क्योंकि स्टैकओवरफ्लो में किसी प्रश्न के URL का शब्दार्थ, पठनीय हिस्सा इसे पहचान नहीं पाता, इसकी पहचान करता है 7996919। URL का सिमेंटिक भाग बस SEO उद्देश्यों के लिए है।

— user3367701

वास्तव में भी /programming/7996919/should-BLABLA-be-or-NOT-to-be कार्य करता है। ऐसा इसलिए है क्योंकि stackoverflow.com का सर्वर केवल इसे पहचानने और सही URL और HTML पृष्ठ को वापस करने के लिए प्रश्न आईडी का उपयोग करता है।

— बोजी

Answer 3

होस्टिंग ओएस पर निर्भर करता है। विंडोज़ पर होस्ट की जाने वाली साइटें असंवेदनशील होती हैं क्योंकि अंतर्निहित फ़ाइल सिस्टम असंवेदनशील है। यूनिक्स प्रकार सिस्टम पर होस्ट की गई साइटें केस संवेदी होती हैं क्योंकि उनके अंतर्निहित फ़ाइल सिस्टम आमतौर पर संवेदनशील होते हैं। URL का होस्ट नाम भाग हमेशा असंवेदनशील होता है, यह शेष पथ जो भिन्न होता है।

Comments

हां, जैसा कि यह एक दर्द रहित रूप से http के अनुरोधों पर यूनिक्स ftp सर्वर पर पता चला है।

— लॉरी स्टर्न

सामान्य अर्थों में 'सर्वर पर निर्भर' कहना अधिक सटीक होगा - क्योंकि HTTP अनुरोधों का जवाब देने के लिए फाइलें परोसना एकमात्र तरीका नहीं है।

— वैलेंटाइन वेस्लेन्क

Answer 4

किसी URL का डोमेन नाम भाग DNS को अनदेखा करने के बाद से संवेदनशील नहीं है: http://en.example.org/और HTTP://EN.EXAMPLE.ORG/दोनों एक ही पृष्ठ को खोलते हैं।

पथ का उपयोग निर्दिष्ट करने के लिए किया जाता है और शायद अनुरोध किए गए संसाधन को ढूंढता है। यह केस-संवेदी है, हालांकि इसे कुछ सर्वरों द्वारा केस-असंवेदनशील के रूप में माना जा सकता है, विशेष रूप से Microsoft विंडोज पर आधारित।

यदि सर्वर संवेदनशील है और http://en.example.org/wiki/URLसही है, तो http://en.example.org/WIKI/URLया तब http://en.example.org/wiki/urlHTTP 404 त्रुटि पेज प्रदर्शित होगा, जब तक कि ये URL वैध संसाधनों की ओर इशारा नहीं करते।

Comments

इस उत्तर में एकमात्र सही शब्द है "यह केस-संवेदी है, हालांकि इसे केस-असंवेदनशील माना जा सकता है"। केवल मान्य उत्तर।

— डैनियल डब्ल्यू

@DanFromGermany, पथ केस-संवेदी है यहाँ से अस्पष्ट रूप से कटौती की जा सकती है "सामान्य रूप से URL केस-सेंसिटिव होते हैं (मशीन के नामों के अपवाद के साथ) URL, या URL के कुछ हिस्से हो सकते हैं, जहाँ केस की बात नहीं होती है, लेकिन पहचान होती है। ये आसान नहीं हो सकता है। ” लेकिन, इसे कम करना अस्पष्ट है। जैसा कि ऊपर की एक टिप्पणी में उल्लेख किया गया है, RFC1738 चर्चा नहीं करता है कि योजना के अलावा URL के कुछ हिस्सों को केस सेंसिटिव के रूप में समझा जाना चाहिए या नहीं। क्या आपके पास कोई लिंक है जो स्पष्ट करता है कि url के कौन से भाग केस-संवेदी हैं?

— गार्नेट

Rgar3986 से @garnet 6.2.2.1। केस सामान्यीकरण : जब कोई यूआरआई जेनेरिक सिंटैक्स के घटकों का उपयोग करता है, तो घटक सिंटैक्स तुल्यता नियम हमेशा लागू होते हैं; अर्थात्, योजना और मेजबान केस-असंवेदनशील हैं और इसलिए इसे कम करने के लिए सामान्य किया जाना चाहिए। उदाहरण के लिए, यूआरआई HTTP://www.EXAMPLE.com/के बराबर है http://www.example.com/। अन्य सामान्य वाक्य रचना घटकों को केस-संवेदी माना जाता है जब तक कि विशेष रूप से योजना द्वारा अन्यथा परिभाषित न किया गया हो। "

— डैनियल डब्ल्यू।

@garnet और HTTP RFC से : " जब वे मैच करते हैं या नहीं, यह तय करने के लिए दो यूआरआई की तुलना करते हैं, तो ग्राहक SHOULD पूरे यूआरआई की तुलना में केस-संवेदी ऑक्टेट-बाय-ऑक्टेट का उपयोग करता है [...] " योजना के अपवाद के साथ और खुद की मेजबानी करें)।

— डैनियल डब्ल्यू।

Answer 5

मैं पुराने लेखों को उछालने का प्रशंसक नहीं हूं, लेकिन क्योंकि यह इस विशेष मुद्दे के लिए पहली प्रतिक्रियाओं में से एक था, मुझे कुछ स्पष्ट करने की आवश्यकता महसूस हुई।

जैसा कि @Bhavin शाह का जवाब है कि यूआरएल का डोमेन हिस्सा असंवेदनशील है, इसलिए

http://google.com 

तथा

http://GOOGLE.COM 

तथा

http://GoOgLe.CoM 

सभी समान हैं लेकिन डोमेन नेम पार्ट के बाद सब कुछ केस सेंसिटिव माना जाता है।

इसलिए...

http://GOOGLE.COM/ABOUT

तथा

http://GOOGLE.COM/about

अलग है।

नोट: मैं "तकनीकी रूप से" बात कर रहा हूं और बहुत सारे मामलों में "सचमुच" नहीं है, वास्तव में, सर्वर इन वस्तुओं को संभालने के लिए सेटअप हैं, लेकिन उन्हें स्थापित करना संभव है, इसलिए उन्हें एक ही नहीं संभाला जाता है।

अलग-अलग सर्वर इसे अलग तरीके से संभालते हैं और कुछ मामलों में उन्हें संवेदनशील होना पड़ता है। कई मामलों में क्वेरी स्ट्रिंग मान एन्कोडेड होते हैं (जैसे कि सत्र Ids या Base64 एन्कोडेड डेटा क्वेरीज़ को क्वेरी स्ट्रिंग मान के रूप में पारित किया जाता है) ये आइटम उनके स्वभाव से संवेदनशील होते हैं इसलिए सर्वर को उन्हें संभालने में संवेदनशील होना पड़ता है।

तो सवाल का जवाब देने के लिए, "सर्वर" को इस डेटा को हथियाने में संवेदनशील होना चाहिए, जवाब "हां, सबसे निश्चित रूप से है।"

बेशक सब कुछ केस सेंसिटिव होने की जरूरत नहीं है, लेकिन सर्वर को इस बात की जानकारी होनी चाहिए कि क्या है और उन मामलों को कैसे हैंडल करना है।

---

@ हर्ष सिम्हा की टिप्पणी मूल रूप से एक ही बात कहती है। मैंने इसे पोस्ट करने से पहले याद किया इसलिए मैं क्रेडिट देना चाहता हूं जहां क्रेडिट देय है।

Answer 6

यहां विनिर्देश देखें: खंड 2.7.3 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19

योजना और मेजबान केस-असंवेदनशील हैं और सामान्य रूप से लोअरकेस में प्रदान किए जाते हैं; अन्य सभी घटकों की तुलना केस-संवेदी तरीके से की जाती है।

Answer 7

निम्नलिखित को धयान मे रखते हुए:

https://www.example.com/createuser.php?name=Paul%20McCartney

इस काल्पनिक उदाहरण में, एक HTML फॉर्म - GET विधि का उपयोग करके - एक पीएचपी स्क्रिप्ट के लिए "नाम" पैरामीटर भेजता है जो एक नया उपयोगकर्ता खाता बनाता है।

और इस उदाहरण के साथ मैं जो बिंदु बना रहा हूं, वह यह है कि इस GET पैरामीटर को "मैककार्टनी" के पूंजीकरण को संरक्षित करने के लिए केस-संवेदी होने की आवश्यकता है (या, एक अन्य उदाहरण के रूप में, "वाल्टर डी'सनी" को संरक्षित करने के लिए, क्योंकि अन्य तरीके भी हैं। सामान्य पूंजीकरण नियमों को तोड़ने के लिए नाम)।

यह उन मामलों की तरह है जो डब्ल्यू 3 सी की सिफारिश को निर्देशित करते हैं कि योजना और मेजबान असंवेदनशील हैं, लेकिन उसके बाद सब कुछ संभावित रूप से संवेदनशील मामला है - और सर्वर पर छोड़ दिया जाता है। मानक द्वारा असंवेदनशीलता के मामले को मजबूर करना उपरोक्त उदाहरण को GET क्वेरी पैरामीटर के रूप में पारित उपयोगकर्ता इनपुट के मामले को संरक्षित करने में असमर्थ बना देगा।

लेकिन मैं यह कहूंगा कि हालांकि यह जरूरी है कि ऐसे मामलों को समायोजित करने के लिए कानून का पत्र है, कानून की भावना यह है कि जहां मामला अप्रासंगिक है, एक मामले में असंवेदनशील तरीके से व्यवहार करें। हालांकि, मानक आपको यह नहीं बता सकते हैं कि मामला कहां अप्रासंगिक है, क्योंकि मैंने जो उदाहरण दिए हैं, वह संदर्भ-निर्भर बात है।

(उदाहरण के लिए, खाता उपयोगकर्ता संभवतः असंवेदनशीलता के लिए सबसे अच्छा मजबूर होता है - जैसा कि "User123" और "user123" अलग-अलग खाते होने के कारण भ्रामक साबित हो सकते हैं - भले ही उनका वास्तविक नाम, ऊपर छोड़ दिया गया हो, सबसे अच्छा मामला संवेदनशील है।)

कभी-कभी यह प्रासंगिक है, ज्यादातर बार यह नहीं है। लेकिन इसे इन चीजों को तय करने के लिए सर्वर / वेब डेवलपर पर छोड़ दिया जाना चाहिए - और मानक द्वारा निर्धारित नहीं किया जा सकता है - जैसा कि उस स्तर पर ही संदर्भ जाना जा सकता है।

योजना और होस्ट केस असंवेदनशील हैं (जो मामले की असंवेदनशीलता के लिए मानक की प्राथमिकता को दर्शाता है, जहां इसे सार्वभौमिक रूप से निर्धारित किया जा सकता है)। बाकी आपको तय करना बाकी है, क्योंकि आप संदर्भ को बेहतर समझते हैं। लेकिन, जैसा कि चर्चा की गई है, आपको संभवतः कानून की भावना में, असंवेदनशीलता के मामले में डिफ़ॉल्ट होना चाहिए जब तक कि आपके पास एक अच्छा कारण न हो।

Comments

क्या क्वेरी स्ट्रिंग को स्थान का हिस्सा माना जाता है? मेरा मानना ​​है कि उन्हें अलग-अलग संस्थाओं के रूप में माना जाता है और स्थान के लिए उपयोग नहीं किया जाता है।

— jpmc26

क्वेरी स्ट्रिंग स्थान से अलग हैं, हाँ। लेकिन वही सिद्धांत जो मैंने क्वेरी पैरामीटर के साथ दिखाए हैं, वे URL के अन्य भागों पर भी लागू हो सकते हैं। कुछ CMSes, उदाहरण के लिए, बेहतर एसईओ-अनुकूल मानव-पठनीय URL (उदाहरण के लिए, Wordpress ऐसा करता है) के लिए "/user.php?id=3756" को उद्देश्यपूर्ण रूप से पुन: लिख सकता है। मुद्दा यह है कि मानकों को जानबूझकर पर्चे से दूर कर दिया जाता है जो संदर्भ-निर्भर है। यह तय करने के लिए सर्वर पर छोड़ दिया जाता है, क्योंकि सर्वर संदर्भ को समझता है, जहां एक सार्वभौमिक मानक नहीं हो सकता है।

— बॉब

Answer 8

URL को असंवेदनशील होना चाहिए जब तक कि कोई अच्छा कारण न हो कि वे क्यों न हों।

यह अनिवार्य नहीं है (यह किसी RFC का हिस्सा नहीं है) लेकिन यह URL के संचार और भंडारण को कहीं अधिक विश्वसनीय बनाता है।

यदि मेरे पास वेबसाइट पर दो पृष्ठ हैं:

http://stackoverflow.com/ABOUT.html

तथा

http://stackoverflow.com/about.html

उन्हें कैसे अलग होना चाहिए? हो सकता है कि किसी ने 'चिल्ला शैली' (कैप) लिखी हो - लेकिन एक आईए के दृष्टिकोण से, URL के मामले में परिवर्तन से कभी भी भेद नहीं किया जाना चाहिए।

इसके अलावा, अपाचे में इसे लागू करना आसान है - बस CheckSpelling Onmod_Speling से उपयोग करें ।

Answer 9

पुराना सवाल है लेकिन मैं यहां लड़खड़ा गया हूं इसलिए इस पर गोली नहीं चलानी चाहिए क्योंकि यह सवाल विभिन्न परिप्रेक्ष्य की तलाश में है और निश्चित जवाब नहीं।

w3c की अपनी सिफारिशें हो सकती हैं - जिसका मुझे बहुत ख्याल है - लेकिन सवाल यहाँ होने के बाद से पुनर्विचार करना चाहते हैं।

W3c को डोमेन नाम असंवेदनशील क्यों माना जाता है और बाद में असंवेदनशील होने पर कुछ भी छोड़ देता है?

मैं सोच रहा हूं कि तर्क यह है कि URL का डोमेन हिस्सा किसी उपयोगकर्ता द्वारा टाइप किया गया है। हाइपर टेक्स्ट होने के बाद सबकुछ मशीन (ब्राउज़र और बैक में सर्वर) द्वारा हल किया जाएगा।

मशीनें मनुष्यों की तुलना में मामले की संवेदनशीलता को बेहतर तरीके से संभाल सकती हैं (तकनीकी प्रकार :) नहीं)।

लेकिन सवाल सिर्फ इसलिए है कि मशीनें जो संभाल सकती हैं क्या उसे उसी तरह से किया जाना चाहिए?

मेरा मतलब है कि hereIsTheResourceबनाम बैठे संसाधन के नामकरण और पहुंच के क्या लाभ हैं hereistheresource?

पार्श्व ऊंट मामले की तुलना में बहुत ही अपठनीय है जो अधिक पठनीय है। मनुष्य के लिए पठनीय (तकनीकी प्रकार सहित)

तो यहाँ मेरे अंक हैं: -

संसाधन पथ प्रोग्रामिंग संरचना के बीच में कहीं गिरता है और कभी-कभी ब्राउज़र के पीछे एक अंतिम उपयोगकर्ता के करीब होता है।

आपका URL (डोमेन नाम को छोड़कर) असंवेदनशील होना चाहिए यदि आपके उपयोगकर्ताओं से अपेक्षा की जाती है कि वे इसे छू सकते हैं या इसे टाइप कर सकते हैं। आपको अपने आवेदन को AVOID में विकसित करना चाहिए जिसमें उपयोगकर्ता यथासंभव पथ टाइप कर सकें।

आपका URL (डोमेन नाम को छोड़कर) संवेदनशील होना चाहिए अगर आपके उपयोगकर्ता इसे कभी भी हाथ से नहीं लिखेंगे।

निष्कर्ष

पथ संवेदनशील होना चाहिए। मेरे बिंदु केस संवेदी रास्तों की ओर बढ़ रहे हैं।

Answer 10

URL वर्णों को हेक्स कोड में बदल दिया जाता है (यदि आपने कभी URL में रिक्त स्थानों को% 20, आदि के रूप में प्रदर्शित किया जा रहा है), और चूंकि निचले और ऊपरी मामले में अलग-अलग हेक्स मान हैं, तो यह सही अर्थ देता है कि URL निश्चित रूप से केस संवेदनशील हैं। हालाँकि प्रश्न की आत्मा को लगता है कि मानक होना चाहिए और मैं कहता हूं कि नहीं, लेकिन वे हैं। डेवलपर / प्रदाता को अपने कोड में इसके लिए जिम्मेदार होना चाहिए, अगर वे चाहते हैं कि यह अंतिम उपयोगकर्ता के लिए काम करे।

Comments

यह मजेदार है। नियमित रूप से ई ASCII वर्ण (जिसमें एक ऊपरी और निचला मामला है) वास्तव में सही नहीं हैं? यह केवल रिक्त स्थान और विस्तारित वर्ण हैं जो url में बच गए हैं। क्या किसी विस्तारित चार्ट में ऊपरी / निचले मामले का संशोधक है?

— टाइगरक्रैश

Answer 11

मुझे लगता है कि यह और क्या जवाब देता है या नहीं कहता है के आसपास के कई जवाब सवाल के बिंदु को याद कर रहे हैं। क्या उन्हें मामला संवेदनशील होना चाहिए ? यह एक लोडेड सवाल है। उपयोगकर्ता के दृष्टिकोण से, केस सेंसिटिविटी एक दर्द बिंदु है, सभी नहीं जानते कि इससे कोई फर्क पड़ता है। URIs होना चाहिए या नहीं होना चाहिए, इस सवाल के संदर्भ पर निर्भर करता है। तकनीकी लचीलेपन के लिए, हाँ, उन्हें होना चाहिए। प्रयोज्य के लिए, नहीं, उन्हें नहीं होना चाहिए।

Comments

निष्पक्ष होने के लिए, "SHOULD" पूछने वाला कोई भी सवाल स्वाभाविक रूप से राय-आधारित है और इसे StackOverflow से हटाया जा सकता है । (अधिक: stackoverflow.blog/2010/09/29/good-subjective-bad-subjective )

— छारवे

Answer 12

मामला संरक्षण

क्लाइंट और सर्वर के बीच URL केस-प्रोटेक्टिंग होते हैं । लेकिन कुछ कारणों से URL का कुछ भाग सर्वर के आधार पर केस-संवेदी हो सकता है या नहीं ।

मामले की संवेदनशीलता

साइट और / या सर्वर कॉन्फ़िगरेशन के आधार पर, URL के निम्नलिखित बोल्ड भाग केस-संवेदी हो सकते हैं।

    http: // www। example.com /abc/def.ghi?jkl=mno#pqr

    user @ example.com

दलील

URL में केस-सेंसिटिविटी के कई उपयोग हो सकते हैं। में मुख्य:

1. केस-संवेदी फाइल सिस्टम के साथ मूल संगतता।
2. URL के भीतर अधिक कॉम्पैक्ट डेटा एन्कोडिंग, जैसे कि क्रमांकन, हैशिंग, आईडी, पर्मलिंक और URL शॉर्टर्स।

एक डेवलपर के रूप में, मेरा मानना ​​है कि उपरोक्त को अक्सर बेहतर तरीकों से नियंत्रित किया जा सकता है, लेकिन मैं यह भी समझता हूं कि ऐसे मामले हैं जहां कोई स्थिति इसकी अनुमति नहीं दे सकती है।

उदाहरण के लिए, एक मौजूदा उत्पाद की कल्पना करें जिसके लिए "GET" URL में बहुत अधिक डेटा की आवश्यकता होती है, फिर भी इसे सभी प्रमुख सर्वरों, ब्राउज़रों और कैशिंग / प्रॉक्सी तंत्रों की अधिकतम URL लंबाई के साथ संगत होना चाहिए। यहां तक ​​कि एक मध्यम-लंबाई कमांड स्ट्रिंग (कुछ पुराने ब्राउज़रों के लिए 1,024 वर्णों के तहत) को फिट करने के लिए, आपको प्रत्येक अद्वितीय URL-सुरक्षित चरित्र का उपयोग करने की आवश्यकता होगी (जो मूल रूप से आधारभूत एन्कोडिंग है)।

एक आदर्श दुनिया में

URL केस-संवेदी होना चाहिए या नहीं यह बहस का विषय है। मेरा व्यक्तिगत रूप से मानना ​​है कि उन्हें सादगी के लिए नहीं होना चाहिए (हालांकि यह लंबे समय तक URL बना सकता है, हमारे पास उन मामलों को आसानी से संभालने के लिए प्रतिशत-एस्केप हैं जहां हमें सटीक वर्णों के संरक्षण को सुनिश्चित करना होगा, और URL में सही के अलावा अन्य डेटा स्थानांतरित करने के तरीके हैं) ।

इस तथ्य के आधार पर कई सहमत दिखते हैं कि प्रयोज्यता को बढ़ाने के लिए केस-असंवेदनशील यूआरएल कई लोकप्रिय साइटों और सेवाओं के लिए स्पष्ट रूप से सक्षम हैं। सबसे प्रमुख उदाहरण ईमेल पतों का उपयोगकर्ता नाम भाग है। अधिकांश ईमेल प्रदाता केस और कभी-कभी डॉट्स और अन्य प्रतीकों (जैसे "[e-mail]" को "[e-mail]" के समान होने पर भी अनदेखा कर देंगे)। भले ही ईमेल उपयोगकर्ता नाम कल्पना के अनुसार डिफ़ॉल्ट रूप से केस-संवेदी हो।

हालांकि, तथ्य यह है कि मैं या अन्य क्या चाहते हैं, इसके बावजूद, यह इस बात की स्थिति है कि वर्तमान में चीजें कैसे काम करती हैं। और जब केस-असंवेदनशील URL मानक के लिए दुनिया भर में एक संक्रमण निश्चित रूप से संभव है, तो संभवतः यह काफी लंबा समय लेगा क्योंकि केस-संवेदनशीलता वर्तमान में वेब के चारों ओर विभिन्न प्रयोजनों के लिए बड़े पैमाने पर उपयोग की जाती है।

सर्वोत्तम प्रथाएं

जहां तक ​​सर्वोत्तम प्रथाएं हैं, एक उपयोगकर्ता के रूप में आप ज्यादातर परिस्थितियों के लिए निचले स्तर पर रह सकते हैं और काम करने की चीजों की अपेक्षा कर सकते हैं। मुख्य अपवाद URL होंगे जो केस-आधारित एन्कोडिंग या दस्तावेज़ पथ का उपयोग सीधे फाइलसिस्टम समकक्षों के साथ करते हैं। हालाँकि, ऐसे जटिल URL आमतौर पर मैन्युअल रूप से टाइप किए जाने की बजाय कॉपी-पेस्ट (या बस क्लिक किए गए) होते हैं।

एक वेब डेवलपर के रूप में, आपको URL को यथासंभव असंवेदनशील रखने पर विचार करना चाहिए। हालांकि स्पष्ट रूप से कुछ कठिन-से-बचने वाली परिस्थितियां हैं, जो संदर्भ के आधार पर, जैसा कि ऊपर उल्लेख किया गया है।

Answer 13

सवाल यह है कि क्या url संवेदनशील होना चाहिए?

मुझे मामला संवेदनशील URL के पीछे कोई उपयोग या अच्छा अभ्यास नहीं दिखता है। यह बेवकूफ है, यह बेकार है और हर समय बचा जाना चाहिए।

बस अपनी राय का समर्थन करने के लिए, जब कोई पूछता है कि क्या URL है, तो आप कैसे समझा सकते हैं कि URL के कौन से अक्षर अपर या लोअर केस हैं? यह बकवास है और कोई भी आपको कभी भी अन्यथा नहीं बताना चाहिए।

Comments

मामला संवेदनशील होने पर URL का एक फ़ायदा है। कुछ वेबसाइटों में, जहाँ ऑब्जेक्ट्स को यूनिक आईडी के साथ एनकोड किया जाता है जिसे URL के माध्यम से संदर्भित किया जा सकता है, एन्कोडिंग base36 के बजाय base64 की तरह कुछ हो सकता है । यह आपको एक ही संख्या में URL वर्णों में घातीय रूप से अधिक अद्वितीय वस्तुओं को एनकोड करने की अनुमति देता है। उदाहरण के लिए, foo.com/000 - foo.com/zzz (केस असंवेदनशील) 36 ^ 3 अद्वितीय ऑब्जेक्ट्स को संदर्भित कर सकता है, जहां foo.com/000 - foo.com/ZZZ (केस संवेदनशील, जिसका अर्थ है foo.com/zzz) और foo.com/ZZZ अलग-अलग रास्ते हैं), 62 ^ 3 ऑब्जेक्ट को संदर्भित करेगा।

— हार्ट सिम्हा

यह एक जवाब नहीं है, यह एक राय है।

— टिन मैन

मैं इसे एक उदाहरण के साथ वापस करता हूं। URL का उपयोग लोग करते हैं-मूल प्रश्न- कंप्यूटर नहीं। यह बहुत कठिन है, इसलिए देखें कि कोई लिंक काम क्यों नहीं कर रहा है और चूंकि लगभग सभी डोमेन असंवेदनशील हैं, इसलिए बाकी यूआरएल चाहिए। डाउनवोट्स मेरे स्वर के स्वर के लिए हैं (जो खराब है), या क्योंकि तकनीकी लोग उपयोगकर्ता अनुभव पर तकनीकी सुंदरता को चुनते हैं।

— हेनरीकोपेन 5

@TheTinMan यह राय देने वाले सवाल का जवाब है।

— छरवे २०'१

मैं @HartSimha से सहमत हूं और चूंकि प्रश्न राय के लिए पूछता है: URL मार्ग का कोई भी भाग किसी अनन्य ऑब्जेक्ट की पहचान करने के लिए उपयोग किया जा रहा है, कृपया इंटरनेट पर जो सब अच्छा है, उसके प्यार के लिए कृपया इसे संवेदनशील न बनाएं।

— जॉयब्र

Answer 14

लिनक्स सर्वर में होस्ट की गई वेबसाइटों के लिए, URL संवेदनशील है। http://www.google.com/about और http://www.google.com/About को विभिन्न स्थानों पर पुनर्निर्देशित किया जाएगा। विंडोज सर्वर में रहते हुए, URL केस-असंवेदनशील है, जैसा कि एक FOLDER के नामकरण में है और इसे उसी स्थान पर पुनर्निर्देशित किया जाएगा।

Answer 15

गैर-संवेदी URL बनाना संभव है

RewriteEngine on
rewritemap lowercase int:tolower
RewriteCond $1 [A-Z]
RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L]

Google.com..GOOGLE.com आदि को सीधे google.com पर बनाना

Comments

यह प्रश्न का उत्तर नहीं देता है

— मोनोक्रोम

सवाल यह है: "क्या URL संवेदनशील होना चाहिए?" आपका उत्तर है: "केस को असंवेदनशील URL कैसे

— बनाएं