कौन से वर्ण URL को अमान्य बनाते हैं?
क्या ये वैध URL हैं?
example.com/file[/].htmlhttp://example.com/file[/].htmlजवाबों:
RFC 3986 द्वारा परिभाषित सामान्य URI में ( धारा 2 देखें : वर्ण ) निम्नलिखित 84 वर्णों में से कोई भी हो सकता है:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=
ध्यान दें कि यह सूची यह नहीं बताती है कि URI में ये अक्षर कहां हो सकते हैं।
किसी भी अन्य चरित्र को प्रतिशत-एन्कोडिंग ( %hh) के साथ एन्कोड किया जाना चाहिए । URI के प्रत्येक भाग में इस बारे में और प्रतिबंध हैं कि प्रतिशत-एन्कोडेड शब्द द्वारा किन वर्णों का प्रतिनिधित्व किया जाना चाहिए।
/^([!#$&-;=?-[]_a-z~]|%[0-9a-fA-F]{2})+$/ क्या ऐसा कुछ और था जिसे आपने पाया है कि इसे स्वीकार करना चाहिए था? (बस स्पष्ट होना चाहिए, कि regex केवल यह जांचता है कि क्या स्ट्रिंग में मान्य URL वर्ण हैं, न कि यदि स्ट्रिंग में अच्छी तरह से बनाया गया URL है।)
कुछ स्पष्टीकरण जोड़ने और ऊपर दिए गए प्रश्न को सीधे संबोधित करने के लिए, कई वर्ग के वर्ण हैं जो URL और URI के लिए समस्याएँ पैदा करते हैं।
कुछ वर्ण ऐसे हैं जो अस्वीकृत हैं और उन्हें कभी भी URL / URI, आरक्षित वर्ण (नीचे वर्णित), और अन्य वर्ण नहीं दिखाई देते हैं, जो कुछ मामलों में समस्याएँ पैदा कर सकते हैं, लेकिन उन्हें "नासमझ" या "असुरक्षित" के रूप में चिह्नित किया जाता है। वर्ण प्रतिबंधित क्यों हैं इसके लिए स्पष्टीकरण RFC-1738 (URL) और RFC-2396 (URI) में स्पष्ट रूप से लिखे गए हैं । ध्यान दें कि नए RFC-3986 (RFC-1738 के लिए अद्यतन) यह निर्धारित करता है कि दिए गए संदर्भ में किन वर्णों के निर्माण की अनुमति है, लेकिन पुरानी कल्पना एक सरल और अधिक सामान्य विवरण प्रस्तुत करती है जिसमें निम्नलिखित नियमों के साथ वर्णों की अनुमति नहीं है।
URI सिंटैक्स के भीतर अस्वीकृत US-ASCII वर्ण:
control = <US-ASCII coded characters 00-1F and 7F hexadecimal>
space = <US-ASCII coded character 20 hexadecimal>
delims = "<" | ">" | "#" | "%" | <">
वर्ण "#" को बाहर रखा गया है, क्योंकि इसका उपयोग किसी URI को खंडित पहचानकर्ता से हटाने के लिए किया जाता है। प्रतिशत वर्ण "%" को बाहर रखा गया है क्योंकि इसका उपयोग भागे हुए पात्रों के एन्कोडिंग के लिए किया जाता है। दूसरे शब्दों में, "#" और "%" एक विशिष्ट संदर्भ में उपयोग किए जाने वाले आरक्षित वर्ण हैं।
नासमझ पात्रों की सूची की अनुमति है, लेकिन समस्याओं का कारण हो सकता है:
unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
वर्ण जो किसी क्वेरी घटक और / या URI / URL के भीतर विशेष अर्थ में आरक्षित हैं :
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
ऊपर "आरक्षित" सिंटैक्स वर्ग उन वर्णों को संदर्भित करता है, जिन्हें किसी URI के भीतर अनुमति दी जाती है, लेकिन जिसे सामान्य URI सिंटैक्स के किसी विशेष घटक के भीतर अनुमति नहीं दी जा सकती है। "आरक्षित" सेट में वर्ण सभी संदर्भों में आरक्षित नहीं हैं । उदाहरण के लिए, होस्टनाम में एक वैकल्पिक उपयोगकर्ता नाम हो सकता है, इसलिए यह कुछ ऐसा हो सकता है ftp://user@hostname/जहां '@' वर्ण का विशेष अर्थ है।
यहाँ एक URL का उदाहरण दिया गया है जिसमें अमान्य और नासमझ अक्षर हैं (जैसे '$', '[', ']') और ठीक से एन्कोडेड होना चाहिए:
http://mw1.google.com/mw-earth-vectordb/kml-samples/gp/seattle/gigapxl/$[level]/r$[y]_c$[x].jpg
URI / URL के लिए कुछ वर्ण प्रतिबंध प्रोग्रामिंग भाषा पर निर्भर हैं। उदाहरण के लिए, '|' (0x7C) वर्ण हालांकि केवल यूआरआई कल्पना में "नासमझ" के रूप में चिह्नित है, जावा java.net.URI निर्माता में एक URISyntaxException फेंक देगा, इसलिए जैसे URL की अनुमति नहीं है और इसके बजाय एन्कोड किया जाना चाहिए जैसे कि जावा एक यूआरआई ऑब्जेक्ट उदाहरण के साथ।http://api.google.com/q?exp=a|bhttp://api.google.com/q?exp=a%7Cb
?सिर्फ ठीक है , लेकिन इसके पहले असंभव है, और मुझे नहीं लगता कि @इनमें से किसी भी सूची में है। ओह, और %25पिछले स्ट्रिंग के बजाय , क्या आपका मतलब नहीं है %7C?
यहां मौजूद अधिकांश उत्तर अव्यावहारिक हैं क्योंकि वे पते की वास्तविक दुनिया के उपयोग को पूरी तरह से अनदेखा करते हैं:
सबसे पहले, शब्दावली में एक विषयांतर। ये पते क्या हैं ? क्या वे मान्य URL हैं?
ऐतिहासिक रूप से, उत्तर "नहीं" था। RFC 3986 के अनुसार , 2005 से, ऐसे पते URI (और इसलिए URL नहीं हैं, क्योंकि URL एक प्रकार के URI हैं )। 2005 IETF मानकों की शब्दावली के अनुसार, हमें RFC 3987 में परिभाषित IRIs (अंतर्राष्ट्रीयकृत संसाधन पहचानकर्ता) को ठीक से कॉल करना चाहिए , जो कि तकनीकी रूप से URI नहीं हैं, लेकिन IRI में गैर-ASCII वर्ण प्रतिशत-एन्कोडिंग द्वारा केवल URI में परिवर्तित किए जा सकते हैं ।
आधुनिक कल्पना के अनुसार, उत्तर "हां" है। WHATWG लिविंग स्टैंडर्ड बस सब कुछ है कि पहले "URL" के रूप में "यूआरआई" या "आइरिस" कहा जा सकता है वर्गीकृत करता है। यह निर्दिष्ट शब्दावली के साथ संरेखित करता है कि कैसे सामान्य लोग जो कल्पना नहीं पढ़ते हैं वे "URL" शब्द का उपयोग करते हैं, जो कि कल्पना के लक्ष्यों में से एक था ।
"URL" के इस नए अर्थ के अनुसार, किन वर्णों की अनुमति है? URL के कई हिस्सों में, जैसे कि क्वेरी स्ट्रिंग और पथ, हमें मनमाने ढंग से "URL इकाइयों" का उपयोग करने की अनुमति है , जो हैं
"URL कोड पॉइंट" क्या हैं?
यूआरएल कोड अंक , ASCII अक्षरांकीय हैं U + 0021 (!), U + 0024 ($), U + 0026 (&), U + 0027 ( '), U + 0028 बायां कोष्ठक, U + 0029 दायां कोष्ठक, U + 002A (*), U + 002B (+), U + 002C ((), U + 002D (-), U + 002E (।), U + 002F (/), U + 003A (:), U + 003B (;), U + 003D (=), U + 003F (?), U + 0040 (@), U + 005F (_), U + 007E (~), और कोड अंक U-00A0 से U तक + 10FFFD, समावेशी, सरोगेट और गैर-लाभार्थियों को छोड़कर।
(ध्यान दें कि "URL कोड बिंदुओं" की सूची में शामिल नहीं है %, लेकिन %यदि उन्हें प्रतिशत-एन्कोडिंग अनुक्रम का हिस्सा है तो "URL कोड इकाइयों" में अनुमति दी गई है।)
केवल वही स्थान मैं देख सकता हूं, जहां कल्पना किसी भी वर्ण के उपयोग की अनुमति देती है जो इस सेट में नहीं है , मेजबान में है , जहां IPv6 पते में [और ]वर्ण संलग्न हैं । URL में हर जगह, या तो URL इकाइयों की अनुमति है या कुछ और भी वर्णों के प्रतिबंधक सेट हैं।
इतिहास की खातिर, और चूंकि यह पूरी तरह से यहां के जवाबों में पूरी तरह से नहीं खोजा गया है, चलो पुराने युग्मों के तहत जांच की अनुमति दी गई थी।
सबसे पहले, हमारे पास दो प्रकार के RFC 3986 आरक्षित वर्ण हैं :
:/?#[]@, जो RFC 3986 में परिभाषित URI के लिए सामान्य वाक्य-विन्यास का हिस्सा हैं!$&'()*+,;=, जो RFC के सामान्य सिंटैक्स का हिस्सा नहीं हैं, लेकिन विशेष रूप से URI योजनाओं के सिंटैक्टिक घटकों के रूप में उपयोग के लिए आरक्षित हैं। उदाहरण के लिए, अर्धविराम और अल्पविराम के की वाक्य रचना के हिस्से के रूप में इस्तेमाल कर रहे डेटा यूआरआई , और &और =सर्वव्यापक के हिस्से के रूप में इस्तेमाल कर रहे ?foo=bar&qux=bazहैं (जो क्वेरी स्ट्रिंग में प्रारूप नहीं है RFC 3986 द्वारा निर्दिष्ट)।उपरोक्त वर्णों में से कोई भी एक यूआरआई में कानूनी रूप से एन्कोडिंग के बिना उपयोग किया जा सकता है, या तो अपने वाक्यात्मक उद्देश्य की सेवा के लिए या कुछ स्थानों पर डेटा में शाब्दिक वर्णों के रूप में जहां ऐसे उपयोग को गलत तरीके से व्याख्या नहीं किया जा सकता है क्योंकि चरित्र अपने वाक्यात्मक उद्देश्य की सेवा कर रहा है। (उदाहरण के लिए, हालाँकि /URL में वाक्य-विन्यास का अर्थ है, आप इसे क्वेरी स्ट्रिंग में अनएन्कोडेड का उपयोग कर सकते हैं, क्योंकि इसका क्वेरी स्ट्रिंग में अर्थ नहीं है।)
RFC 3986 कुछ अनारक्षित वर्णों को भी निर्दिष्ट करता है , जिनका उपयोग हमेशा बिना किसी एन्कोडिंग के डेटा का प्रतिनिधित्व करने के लिए किया जा सकता है:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~अंत में, %चरित्र ही प्रतिशत एनकोडिंग के लिए अनुमति दी है।
केवल निम्नलिखित ASCII वर्णों को छोड़ता है जो URL में प्रदर्शित होने से मना किए जाते हैं:
"<>\^`{|}ASCII का हर दूसरा चरित्र कानूनी रूप से एक URL में फीचर कर सकता है।
फिर RFC 3987 निम्नलिखित यूनिकोड वर्ण श्रेणियों के साथ अनारक्षित वर्णों के सेट का विस्तार करता है:
%xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
पुरानी कल्पना से ये ब्लॉक विकल्प विचित्र लगते हैं और मनमाने ढंग से नवीनतम यूनिकोड ब्लॉक परिभाषाएं दी गई हैं ; यह संभवतः इसलिए है क्योंकि RFC 3987 लिखे जाने के बाद से दशक में ब्लॉक जोड़े गए हैं।
अंत में, यह शायद ध्यान देने योग्य है कि बस यह जानना कि कौन से वर्ण URL में कानूनी रूप से दिखाई दे सकते हैं, यह पहचानना पर्याप्त नहीं है कि कुछ दिए गए स्ट्रिंग एक कानूनी URL है या नहीं, क्योंकि कुछ वर्ण URL के विशेष भागों में केवल कानूनी हैं। उदाहरण के लिए, आरक्षित वर्ण [और http: // [1080 :: 8: 800: 200C: 417A] / foo] जैसे URL में IPv6 शाब्दिक होस्ट के हिस्से के रूप में कानूनी हैं, लेकिन किसी अन्य संदर्भ में कानूनी नहीं हैं, इसलिए ओपी का उदाहरण अवैध है।http://example.com/file[/].html
आपके पूरक प्रश्न में आपने पूछा कि www.example.com/file[/].htmlक्या एक वैध URL है।
वह URL मान्य नहीं है क्योंकि URL एक प्रकार का URI है और मान्य URI के पास एक योजना होनी चाहिए जैसे http:( RFC 3986 देखें )।
यदि आप यह पूछना चाहते हैं कि http://www.example.com/file[/].htmlक्या मान्य URL है तो उत्तर अभी भी नहीं है क्योंकि वर्ग ब्रैकेट वर्ण वहाँ मान्य नहीं हैं।
वर्गाकार कोष्ठक वर्ण इस प्रारूप में URL के लिए आरक्षित हैं: http://[2001:db8:85a3::8a2e:370:7334]/foo/bar(यानी एक होस्ट नाम के बजाय IPv6 शाब्दिक)
यदि आप इस मुद्दे को पूरी तरह से समझना चाहते हैं तो RFC 3986 को ध्यान से पढ़ना लायक है।
[और ]लगभग पारसर्स मैंने देखा है का यूआरआई मान्य नहीं हैं। यह वास्तव में मुझे असली दुनिया में खराब कर दिया है: stackoverflow.com/questions/11038967/…
UnwiseURI के लिए पार्सर बहुत गंभीरता से लेंगे और फिर भी URL लाइब्रेरी के साथ ठीक रहेंगे। यह है कि कोई झंडा नहीं है Unwise। मुझे यह देखना होगा कि URL के लिए Rust lang क्या है (क्योंकि यह एक ब्राउज़र के लिए बनाया जा रहा है, मैं उत्सुक हूँ कि यह क्या करता है)। अधिकांश ब्राउज़र हालांकि खुशी के साथ "[", "]" भी पारित करेंगे। इसलिए सिद्धांत में जैसे मैंने C / C ++ के साथ कहा था कि वे उप / सुपर हैं लेकिन वास्तविकता इतनी सच नहीं है। यह सुपर / सब्सेट की कल्पना और शब्दार्थ की व्याख्या पर अत्यधिक निर्भर है।
सभी मान्य वर्ण जिनका उपयोग URI में किया जा सकता है (एक URL एक प्रकार का URI है ) RFC 3986 में परिभाषित किया गया है ।
अन्य सभी वर्णों का उपयोग URL में किया जा सकता है बशर्ते कि वे पहले "URL एनकोडेड" हों। इसमें विशिष्ट "कोड" के लिए अमान्य वर्ण बदलना शामिल है (आमतौर पर प्रतिशत प्रतीक के रूप में (%) एक हेक्साडेसिमल द्वारा पीछा किया जाता है)।
यह लिंक, HTML URL एन्कोडिंग संदर्भ , में अमान्य वर्णों के लिए एन्कोडिंग की एक सूची है।
यूनिकोड के कई कैरेक्टर रेंज वैध HTML5 हैं , हालाँकि यह अभी भी उनका उपयोग करने के लिए एक अच्छा विचार नहीं हो सकता है।
उदाहरण के लिए, hrefडॉक्स http://www.w3.org/TR/html5/links.html#attr-hyperlink-href :
एक और क्षेत्र के तत्वों पर href विशेषता का मान होना चाहिए जो रिक्त स्थानों से घिरा एक मान्य URL है।
फिर "वैध URL" की परिभाषा http://url.spec.whatwg.org/ की ओर इशारा करती है , जो कहता है कि इसका उद्देश्य है:
RFC 3986 और RFC 3987 को समकालीन कार्यान्वयन के साथ संरेखित करें और इस प्रक्रिया में उन्हें अप्रचलित करें।
वह दस्तावेज़ URL कोड बिंदुओं को परिभाषित करता है :
ASCII अल्फ़ान्यूमेरिक, "!", "$", "&", "" "," (",") "," * "," + ",", "," - ",", "/"। , ":", ",", "=", "?", "@", "_", "~", और कोड अंक U + 00A0 से U + D7FF, U + E000 से U + FDCF , U + FDF0 से U + FFFD, U + 10000 से U + 1FFFD, U + 20000 से U + 2FFFD, U + 30000 से U + 3FFFD, U + 40000 से U + 4FFFD, U + 50000 से U + 5FFFD, U + +60000 से U + 6FFFD, U + 70000 से U + 7FFFD, U + 80000 से U + 8FFFD, U + 90000 से U + 9FFFD, U + A0000 से U + AFFDD, U + B0000 से U + BFFFD, U + C0000 U + CFFFD, U + D0000 to U + DFFFD, U + E1000 to U + EFFFD, U + F0000 to U + FFFFD, U + 100000 से U + 10FFFD।
"URL कोड पॉइंट" शब्द का उपयोग तब स्टेटमेंट में किया जाता है:
यदि c एक URL कोड बिंदु नहीं है और "%" नहीं है, तो पार्स त्रुटि है।
स्कीइंग एल्गोरिथ्म के कई हिस्सों में, स्कीमा, प्राधिकरण, रिश्तेदार पथ, क्वेरी और टुकड़े राज्यों सहित: तो मूल रूप से संपूर्ण URL।
इसके अलावा, सत्यापनकर्ता http://validator.w3.org/ जैसे "你好"URL के लिए पास करता है, और रिक्त स्थान जैसे वर्ण वाले URL के लिए पास नहीं होता है"a b"
बेशक, जैसा कि स्टीफन सी द्वारा उल्लेख किया गया है, यह केवल पात्रों के बारे में नहीं है, बल्कि संदर्भ के बारे में भी है: आपको पूरे एल्गोरिथ्म को समझना होगा। लेकिन चूंकि क्लास "URL कोड पॉइंट" का उपयोग एल्गोरिदम के प्रमुख बिंदुओं पर किया जाता है, इसलिए यह एक अच्छा विचार देता है कि आप क्या उपयोग कर सकते हैं या नहीं।
इसे भी देखें: URL में यूनिकोड वर्ण
मुझे स्ट्रिंग में यूआरएल को विभाजित करने के लिए चरित्र का चयन करने की आवश्यकता है, इसलिए मैंने उन पात्रों की सूची बनाने का निर्णय लिया, जो URL में स्वयं नहीं मिल सकते हैं:
>>> allowed = "-_.~!*'();:@&=+$,/?%#[]?@ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
>>> from string import printable
>>> ''.join(set(printable).difference(set(allowed)))
'`" <\x0b\n\r\x0c\\\t{^}|>'
तो, संभव विकल्प newline, tab, space, backslash और हैं "<>{}^|। मुझे लगता है कि मैं अंतरिक्ष या न्यूलाइन के साथ जाऊंगा। :)
वास्तव में आपके प्रश्न का उत्तर नहीं है, लेकिन url का मान्य करना वास्तव में एक गंभीर चिता है। आप शायद डोमेननाम को मान्य करने से बेहतर हैं और url का भाग छोड़ दें। वह मेरा अनुभव है। आप url को पिंग करने का भी सहारा ले सकते हैं और देख सकते हैं कि क्या यह एक वैध प्रतिक्रिया के रूप में परिणाम देता है, लेकिन इस तरह के एक सरल कार्य के लिए बहुत अधिक हो सकता है।
Url का पता लगाने के लिए नियमित भाव प्रचुर मात्रा में हैं, इसे Google :)
मैं पुराने http (0.9, 1.0, 1.1) अनुरोध और प्रतिक्रिया पाठक / लेखक को लागू कर रहा हूं। अनुरोध URI सबसे समस्याग्रस्त स्थान है।
आप RFC 1738, 2396 या 3986 का उपयोग नहीं कर सकते क्योंकि यह है। कई पुराने HTTP क्लाइंट और सर्वर हैं जो अधिक वर्णों की अनुमति देते हैं। इसलिए मैंने गलती से प्रकाशित वेबसर्वर एक्सेस लॉग के आधार पर शोध किया है "GET URI HTTP/1.0" 200:।
मैंने पाया है कि निम्न गैर-मानक वर्ण अक्सर URI में उपयोग किए जाते हैं:
\ { } < > | ` ^ "
इन पात्रों को RFC 1738 में असुरक्षित बताया गया था ।
यदि आप सभी पुराने HTTP क्लाइंट और सर्वर के साथ संगत होना चाहते हैं - तो आपको URI के अनुरोध में इन वर्णों को अनुमति देनी होगी ।
कृपया इस शोध के बारे में अधिक जानकारी http-og में पढ़ें ।
मैं PHP के लिए कुछ नियमित अभिव्यक्तियाँ लेकर आया हूँ जो पाठ में यूआरएल को एंकर टैग में बदल देगा। (सबसे पहले यह सभी www। Urls को http: // पर फिर से कनवर्ट करता है। फिर सभी url को https:? // // से एक href = ... लिंक के साथ परिवर्तित करता है।
$string = preg_replace('/(https?:\/\/)([!#$&-;=?\-\[\]_a-z~%]+)/sim', '<a href="$1$2">$2</a>',
preg_replace('/(\s)((www\.)([!#$&-;=?\-\[\]_a-z~%]+))/sim', '$1http://$2', $string)
);