यूनिफॉर्म रिसोर्स पहचानकर्ता: Difference between revisions

From Vigyanwiki
(Created page with "{{short description|String used to identify a name of a web resource}} {{Redirect|URI}} {{Confuse|URL}} {{Multiple issues| {{Technical|date=November 2020}} {{Primary sources|d...")
 
No edit summary
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{short description|String used to identify a name of a web resource}}
{{short description|String used to identify a name of a web resource}}
{{Redirect|URI}}
{{Confuse|URL}}
{{Multiple issues|
{{Technical|date=November 2020}}
{{Primary sources|date=November 2020}}
}}
{{Infobox technology standard
{{Infobox technology standard
| title            = Uniform Resource Identifier (URI)
| title            = यूनिफ़ॉर्म रिसोर्स पहचानकर्ता (यूआरआई)
| long_name        =   
| long_name        =   
| native_name      =  
| native_name      =  
Line 13: Line 7:
| image            =  
| image            =  
| caption          =  
| caption          =  
| abbreviation      = URI
| abbreviation      = यूआरआई
| domain            = [[World Wide Web]]
| domain            = [[वर्ल्ड वाइड वेब]]
}}
}}
यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) वर्णों का एक अनूठा क्रम है जो वेब तकनीकों द्वारा उपयोग किए जाने वाले तार्किक या भौतिक संसाधन की पहचान करता है। URI का उपयोग किसी भी चीज़ की पहचान करने के लिए किया जा सकता है, जिसमें वास्तविक दुनिया की वस्तुएँ, जैसे लोग और स्थान, अवधारणाएँ, या सूचना संसाधन जैसे वेब पेज और पुस्तकें शामिल हैं। कुछ यूआरआई एक नेटवर्क पर सूचना संसाधनों का पता लगाने और पुनः प्राप्त करने का एक साधन प्रदान करते हैं (या तो इंटरनेट पर या किसी अन्य निजी नेटवर्क पर, जैसे कंप्यूटर फाइल सिस्टम या [[इंट्रानेट]]); ये [[[[समान संसाधन का नाम]]]] (URL) हैं। एक URL संसाधन का स्थान प्रदान करता है। एक यूआरआई निर्दिष्ट स्थान या यूआरएल पर नाम से संसाधन की पहचान करता है। अन्य यूआरआई केवल एक अनूठा नाम प्रदान करते हैं, इसके बारे में संसाधन या जानकारी का पता लगाने या पुनः प्राप्त करने के साधन के बिना, ये समान संसाधन नाम (यूआरएन) हैं। यूआरआई का उपयोग करने वाली वेब प्रौद्योगिकियां वेब ब्राउज़र तक ही सीमित नहीं हैं। यूआरआई का उपयोग संसाधन विवरण फ्रेमवर्क (आरडीएफ) का उपयोग करके वर्णित किसी भी चीज़ की पहचान करने के लिए किया जाता है, उदाहरण के लिए, अवधारणाएं जो [[वेब ओन्टोलॉजी भाषा]] (ओडब्लूएल) का उपयोग करके परिभाषित ओन्टोलॉजी_(सूचना_विज्ञान) का हिस्सा हैं, और लोग जिन्हें एफओएएफ (ओन्टोलॉजी) का उपयोग करके वर्णित किया गया है। क्या प्रत्येक के पास एक व्यक्तिगत यूआरआई होगा।
 
'''यूनिफ़ॉर्म रिसोर्स पहचानकर्ता''' (यूआरआई) वर्णों का एक विशिष्ट अनुक्रम है जो वेब तकनीकों द्वारा उपयोग किए जाने वाले तार्किक या भौतिक संसाधनों की पहचान करता है। यूआरआईएस का उपयोग किसी भी वस्तु की पहचान करने के लिए किया जा सकता है जिसमें वास्तविक विश्व की वस्तुएँ जैसे लोग और स्थान, अवधारणाएँ या सूचना संसाधन जैसे वेब पेज और पुस्तकें सम्मिलित हैं। कुछ यूआरआई एक नेटवर्क पर सूचना संसाधनों का पता लगाने और पुनः प्राप्त करने का एक साधन प्रदान करते हैं या तो इंटरनेट पर या किसी अन्य निजी नेटवर्क पर, जैसे कंप्यूटर फाइल सिस्टम या [[इंट्रानेट]] आदि पर यूनिफ़ॉर्म रिसोर्स लोकेटर (यूआरएल) हैं। एक यूआरएल संसाधन का स्थान प्रदान करता है। एक यूआरआई निर्दिष्ट स्थान या यूआरएल पर नाम से संसाधन की पहचान करता है। अन्य यूआरआई केवल एक विशिष्ट नाम प्रदान करते हैं इसके विषय में संसाधन या जानकारी का पता लगाने या पुनः प्राप्त करने के साधन के अतिरिक्त ये यूनिफ़ॉर्म रिसोर्स नाम (यूआरएन) हैं। यूआरआई का उपयोग करने वाली वेब प्रौद्योगिकियां वेब ब्राउज़र तक ही सीमित नहीं होती हैं। यूआरआई का उपयोग संसाधन विवरण रूपरेखा (आरडीएफ) का उपयोग करके वर्णित किसी भी वस्तु की पहचान करने के लिए किया जाता है उदाहरण के लिए, अवधारणाएँ जो [[वेब ओन्टोलॉजी भाषा]] (ओडब्ल्यूएल) का उपयोग करके परिभाषित एक ऑन्कोलॉजी का भाग हैं और जिन लोगों को 'सहायक शब्दावली' का उपयोग करके वर्णित किया गया है उनमें से प्रत्येक पास एक अलग-अलग यूआरआई होता है।


== इतिहास ==
== इतिहास ==


=== गर्भाधान ===
=== अवधारणा ===
 
URI और URL का एक साझा इतिहास है। 1990 में, [[हाइपरटेक्स्ट]] के लिए [[टिक बैरनर्स - ली]] के प्रस्तावों ने निहित रूप से एक यूआरएल के विचार को एक छोटी स्ट्रिंग के रूप में प्रस्तुत किया जो एक संसाधन का प्रतिनिधित्व करता है जो [[हाइपरलिंक]] का लक्ष्य है।<ref>{{cite web |last1=Palmer |first1=Sean |title=The Early History of HTML |url=http://infomesh.net/html/history/early/ |website=infomesh.net |access-date=6 December 2020}}</ref> उस समय, लोग इसे हाइपरटेक्स्ट नाम के रूप में संदर्भित करते थे<ref>{{cite web |title=W3 Naming Schemes |url=https://www.w3.org/History/19921103-hypertext/hypertext/WWW/Addressing/Addressing.html |website=www.w3.org |date=1992 |access-date=6 December 2020}}</ref> या दस्तावेज़ का नाम।
 
अगले साढ़े तीन वर्षों में, जैसे-जैसे वर्ल्ड वाइड वेब की एचटीएमएल, एचटीटीपी और वेब ब्राउज़र की मुख्य प्रौद्योगिकियां विकसित हुईं, एक स्ट्रिंग को अलग करने की आवश्यकता सामने आई, जो एक स्ट्रिंग से संसाधन के लिए एक पता प्रदान करती है, जिसे केवल एक संसाधन का नाम दिया गया है। यद्यपि अभी तक औपचारिक रूप से परिभाषित नहीं किया गया है, यूनिफ़ॉर्म रिसोर्स लोकेटर शब्द पूर्व का प्रतिनिधित्व करने के लिए आया था, और अधिक विवादास्पद यूनिफ़ॉर्म रिसोर्स नाम बाद वाले का प्रतिनिधित्व करने के लिए आया था। जुलाई 1992 में [[IETF]] UDI (यूनिवर्सल डॉक्यूमेंट आइडेंटिफ़ायर) बर्ड्स ऑफ़ ए फेदर (कंप्यूटिंग) पर बर्नर्स-ली की रिपोर्ट में URL (यूनिफ़ॉर्म रिसोर्स लोकेटर के रूप में), URN (मूल रूप से, यूनिक रिसोर्स नंबर के रूप में), और एक नए वर्किंग चार्टर की आवश्यकता का उल्लेख है। समूह।<ref>{{cite web |title=Proceedings of the Twenty-Fourth Internet Engineering Task Force |page=193 |url=https://www.ietf.org/proceedings/24.pdf |access-date=27 July 2021}}</ref> नवंबर 1992 में IETF URI वर्किंग ग्रुप की पहली बैठक हुई।<ref>{{cite web |title=Proceedings of the Twenty-Fifth Internet Engineering Task Force |page=501 |url=https://www.ietf.org/proceedings/25.pdf |access-date=27 July 2021}}</ref>
URLs और URNs को परिभाषित करने पर बहस के दौरान, यह स्पष्ट हो गया कि दो शब्दों द्वारा सन्निहित अवधारणाएँ मौलिक, व्यापक, संसाधन पहचान की धारणा के केवल पहलू थे। जून 1994 में, IETF ने टिप्पणियों के लिए बर्नर्स-ली का पहला अनुरोध प्रकाशित किया जिसमें URL और URN के अस्तित्व को स्वीकार किया गया था। सबसे महत्वपूर्ण बात यह है कि इसने यूनिवर्सल रिसोर्स आइडेंटिफ़ायर (यानी URL जैसी स्ट्रिंग्स जिनके सटीक सिंटैक्स और शब्दार्थ उनकी योजनाओं पर निर्भर थे) के लिए एक औपचारिक सिंटैक्स को परिभाषित किया। इसके साथ में {{IETF RFC|1630}} उस समय उपयोग में आने वाली URL योजनाओं के सिंटैक्स को संक्षेप में प्रस्तुत करने का प्रयास किया। इसने स्वीकार किया - लेकिन मानकीकरण नहीं किया - सापेक्ष URL और खंड पहचानकर्ताओं का अस्तित्व।<ref>{{cite journal |last1=Berners-Lee |first1=Tim |title=Universal Resource Identifiers in WWW |url=https://tools.ietf.org/html/rfc1630 |publisher=Network Working Group |access-date=6 December 2020 |date=June 1994|doi=10.17487/RFC1630 }}</ref>


यूआरआई और यूआरएल का एक साझा इतिहास है। 1990 में, [[हाइपरटेक्स्ट]] के लिए [[टिक बैरनर्स - ली|टिक बैरनर्स-ली]] के प्रस्तावों ने निहित रूप से यूआरएल के विचार को एक संसाधन का प्रतिनिधित्व करने वाली एक छोटी श्रृंखला के रूप में प्रस्तुत किया था जो एक [[हाइपरलिंक]] का लक्ष्य है।<ref>{{cite web |last1=Palmer |first1=Sean |title=The Early History of HTML |url=http://infomesh.net/html/history/early/ |website=infomesh.net |access-date=6 December 2020}}</ref> उस समय लोग इसे "हाइपरटेक्स्ट नाम" या "दस्तावेज़ नाम" कहते थे।<ref>{{cite web |title=W3 Naming Schemes |url=https://www.w3.org/History/19921103-hypertext/hypertext/WWW/Addressing/Addressing.html |website=www.w3.org |date=1992 |access-date=6 December 2020}}</ref>


=== शोधन ===
अगले तीन से चार वर्षों में, जैसे-जैसे वर्ल्ड वाइड वेब की एचटीएमएल, एचटीटीपी और वेब ब्राउज़र की मुख्य प्रौद्योगिकियां विकसित हुईं, तब इस हाइपरटेक्स्ट श्रृंखला को अलग करने की आवश्यकता सामने आयी थी जो एक श्रृंखला से संसाधन के लिए एक एड्रेस प्रदान करती है जिसे केवल एक संसाधन का नाम दिया गया है। यद्यपि इसको अभी तक औपचारिक रूप से परिभाषित नहीं किया गया है यूनिफ़ॉर्म रिसोर्स लोकेटर शब्द पूर्व का प्रतिनिधित्व करने के लिए विकसित किया गया था और अधिक विवादास्पद यूनिफ़ॉर्म रिसोर्स नाम बाद वाले का प्रतिनिधित्व करने के लिए हुआ था। जुलाई 1992 में आईईटीएफ "यूडीआई (यूनिवर्सल दस्तावेज़ पहचानकर्ता) बीओएफ" पर बर्नर्स-ली की रिपोर्ट में यूआरएल (यूनिफ़ॉर्म रिसोर्स लोकेटर के रूप में), यूआरएन मूल रूप से विशिष्ट संसाधन संख्या के रूप में और एक नए कार्यरत समूह को चार्टर करने की आवश्यकता का उल्लेख किया गया है।<ref>{{cite web |title=Proceedings of the Twenty-Fourth Internet Engineering Task Force |page=193 |url=https://www.ietf.org/proceedings/24.pdf |access-date=27 July 2021}}</ref> नवंबर 1992 में आईईटीएफ "यूआरआई कार्यरत समूह" की पहली बैठक हुई थी।<ref>{{cite web |title=Proceedings of the Twenty-Fifth Internet Engineering Task Force |page=501 |url=https://www.ietf.org/proceedings/25.pdf |access-date=27 July 2021}}</ref>


दिसंबर 1994 में, {{IETF RFC|1738}} औपचारिक रूप से सापेक्ष और निरपेक्ष URL को परिभाषित किया गया, सामान्य URL सिंटैक्स को परिष्कृत किया गया, यह परिभाषित किया गया कि सापेक्ष URL को निरपेक्ष रूप में कैसे हल किया जाए, और तब उपयोग में आने वाली URL योजनाओं को बेहतर ढंग से गिनाया जाए।<ref>{{cite journal |last1=Berners-Lee |first1=Tim |title=Request for Comments: 1738: Uniform Resource Locators (URL) |url=https://tools.ietf.org/html/rfc1738 |website=tools.ietf.org/html |access-date=6 December 2020 |date=December 1994|doi=10.17487/RFC1738 |doi-access=free }}</ref> यूआरएन की सहमत परिभाषा और सिंटैक्स को IETF <nowiki>RFC</nowiki> 2141 के प्रकाशन तक प्रतीक्षा करनी पड़ी<ref>{{cite journal |last1=Moats |first1=R. |title=Request for Comments: 2141: URN Syntax |url=https://tools.ietf.org/html/rfc2141 |website=tools.ietf.org |access-date=6 December 2020 |date=May 1997|doi=10.17487/RFC2141 }}</ref> मई 1997 में।
जिसमे यूआरएलएस और यूआरएनएस को परिभाषित करने पर वार्तालाप के समय यह स्पष्ट हो गया कि दो शब्दों द्वारा अंतःस्थापित अवधारणाएँ मौलिक, व्यापक, संसाधन पहचान की धारणा के केवल दृष्टिकोण थे। जून 1994 में आईईटीएफ ने टिप्पणियों के लिए बर्नर्स-ली का पहला अनुरोध प्रकाशित किया था जिसमें यूआरएल और यूआरएन के अस्तित्व को स्वीकृत किया गया था। सबसे महत्वपूर्ण अवधारणा यह है कि इसने यूनिवर्सल संसाधन पहचानकर्ता अर्थात यूआरएल जैसी श्रृंखलाए जिनके एल्गोरिथम और शब्दार्थ उनकी योजनाओं पर निर्भर थे जिनके के लिए एक औपचारिक एल्गोरिथम को परिभाषित किया था। इसके अतिरिक्त {{IETF RFC|1630}} ने उस समय उपयोग में आने वाली यूआरएल योजनाओं के एल्गोरिथम को संक्षेप में प्रस्तुत प्रयास किया था। लेकिन आपेक्षिक यूआरएल और खंड पहचानकर्ताओं के अस्तित्व को मानकीकृत नहीं किया था।<ref>{{cite journal |last1=Berners-Lee |first1=Tim |title=Universal Resource Identifiers in WWW |url=https://tools.ietf.org/html/rfc1630 |publisher=Network Working Group |access-date=6 December 2020 |date=June 1994|doi=10.17487/RFC1630 }}</ref>
=== संशोधन ===


IETF <nowiki>RFC</nowiki> 2396 का प्रकाशन<ref>{{cite journal |last1=Berners-Lee |first1=Tim |title=RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax |url=https://tools.ietf.org/html/rfc2396 |website=tools.ietf.org |access-date=6 December 2020 |date=August 1998|doi=10.17487/RFC2396 |doi-access=free }}</ref> अगस्त 1998 में देखा गया कि URI सिंटैक्स एक अलग विनिर्देश बन गया{{sfnp|RFC 2396|1998}} और सामान्य रूप से URI और URL से संबंधित RFC 1630 और 1738 के अधिकांश भाग IETF द्वारा संशोधित और विस्तारित किए गए थे। नए आरएफसी ने यूआरआई में यू के अर्थ को यूनिवर्सल से वर्दी में बदल दिया।
{{IETF RFC|1738}} औपचारिक रूप से आपेक्षिक और निरपेक्ष यूआरएल को परिभाषित करता है, सामान्य यूआरएल एल्गोरिथम को अपरिवर्तित करता है जो आपेक्षिक यूआरएल को निरपेक्ष रूप से हल करने के तरीके को परिभाषित करता है और तब उपयोग में आने वाली यूआरएल योजनाओं की अपेक्षाकृत रूप से गणना करता है।<ref>{{cite journal |last1=Berners-Lee |first1=Tim |title=Request for Comments: 1738: Uniform Resource Locators (URL) |url=https://tools.ietf.org/html/rfc1738 |website=tools.ietf.org/html |access-date=6 December 2020 |date=December 1994|doi=10.17487/RFC1738 |doi-access=free }}</ref> मई 1997 में आईईटीएफ आरएफसी 2141 के प्रकाशन तक यूआरएन की परिभाषा स्वीकृति और एल्गोरिथम के लिए प्रतीक्षा करना पड़ी।<ref>{{cite journal |last1=Moats |first1=R. |title=Request for Comments: 2141: URN Syntax |url=https://tools.ietf.org/html/rfc2141 |website=tools.ietf.org |access-date=6 December 2020 |date=May 1997|doi=10.17487/RFC2141 }}</ref> अगस्त 1998 में आईईटीएफ आरएफसी 2396<ref>{{cite journal |last1=Berners-Lee |first1=Tim |title=RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax |url=https://tools.ietf.org/html/rfc2396 |website=tools.ietf.org |access-date=6 December 2020 |date=August 1998|doi=10.17487/RFC2396 |doi-access=free }}</ref> के प्रकाशन ने प्रदर्शित किया कि यूआरआई एल्गोरिथम एक अलग विनिर्देश बन गया है{{sfnp|RFC 2396|1998}} और यूआरआई और यूआरएल से संबंधित आरएफसी 1630 और 1738 के अधिकांश भागो को आईईटीएफ द्वारा संशोधित और विस्तारित किया गया था। और नए आरएफसी ने "यूआरआई" में "यू" के अर्थ को "यूनिवर्सल" से "यूनिफार्म" में परिवर्तित कर दिया गया था।


दिसंबर 1999 में, {{IETF RFC|2732}}<ref>{{cite journal |last1=Hinden |first1=R. |title=RFC 2732:Format for Literal IPv6 Addresses in URL's |url=https://tools.ietf.org/html/rfc2732 |website=tools.ietf.org |access-date=6 December 2020 |date=December 1999|doi=10.17487/RFC2732 }}</ref> <nowiki>RFC 2396</nowiki> में मामूली अपडेट प्रदान किया, जिससे URI को [[IPv6]] पतों को समायोजित करने की अनुमति मिली। दो विशिष्टताओं में खोजी गई कई कमियों ने <nowiki>RFC 2396</nowiki> के सह-लेखक [[रॉय फील्डिंग]] द्वारा समन्वित एक सामुदायिक प्रयास का नेतृत्व किया, जिसका समापन IETF <nowiki>RFC</nowiki> 3986 के प्रकाशन में हुआ<ref>{{cite journal |last1=Berners-Lee |first1=Tim |title=RFC 3986: Uniform Resource Identifier (URI): Generic Syntax |url=https://tools.ietf.org/html/rfc3986 |website=tools.ietf.org |access-date=6 December 2020 |date=January 2005|doi=10.17487/RFC3986 }}</ref> जनवरी 2005 में। पूर्व मानक को अप्रचलित करते हुए, इसने मौजूदा URL योजनाओं के विवरण को अप्रचलित नहीं किया; <nowiki>RFC 1738</nowiki> ऐसी योजनाओं को नियंत्रित करना जारी रखता है, सिवाय इसके कि जहां अन्यथा अधिक्रमण किया गया हो। IETF <nowiki>RFC</nowiki> 2616<ref>{{cite journal |last1=Fielding |first1=R. |title=RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 |url=https://tools.ietf.org/html/rfc2616 |website=tools.ietf.org |access-date=6 December 2020 |date=June 1999|doi=10.17487/RFC2616 }}</ref> उदाहरण के लिए परिष्कृत करता है <code>http</code> योजना। इसके साथ ही, IETF ने <nowiki>RFC 3986</nowiki> की सामग्री को पूर्ण मानक STD 66 के रूप में प्रकाशित किया, जो एक आधिकारिक इंटरनेट प्रोटोकॉल के रूप में URI जेनेरिक सिंटैक्स की स्थापना को दर्शाता है।
दिसंबर 1999 में {{IETF RFC|2732}}<ref>{{cite journal |last1=Hinden |first1=R. |title=RFC 2732:Format for Literal IPv6 Addresses in URL's |url=https://tools.ietf.org/html/rfc2732 |website=tools.ietf.org |access-date=6 December 2020 |date=December 1999|doi=10.17487/RFC2732 }}</ref> ने आरएफसी 2396 को एक अपेक्षाकृत नया संस्कारण प्रदान किया था। जिससे यूआरआई को आईपीवी-6 एड्रेसों को समायोजित करने की स्वीकृति प्राप्त हुई और दो विशिष्टताओं में खोजी गई कई कमियों के कारण एक सामुदायिक प्रयास हुआ। जिसका समन्वय आरएफसी 2396 के सह-लेखक [[रॉय फील्डिंग]] ने किया था जो जनवरी 2005 में आईईटीएफ आरएफसी 3986<ref>{{cite journal |last1=Berners-Lee |first1=Tim |title=RFC 3986: Uniform Resource Identifier (URI): Generic Syntax |url=https://tools.ietf.org/html/rfc3986 |website=tools.ietf.org |access-date=6 December 2020 |date=January 2005|doi=10.17487/RFC3986 }}</ref> के प्रकाशन के साथ समाप्त हो गया था इसने सम्मिलित यूआरएल योजनाओं के विवरण को अप्रचलित नहीं किया और आरएफसी 1738 ऐसी योजनाओं को नियंत्रित करना प्रारम्भ किया गया इसके अतिरिक्त जहां अन्य आईईटीएफ आरएफसी 2616 का अधिक्रमण किया गया।<ref>{{cite journal |last1=Fielding |first1=R. |title=RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 |url=https://tools.ietf.org/html/rfc2616 |website=tools.ietf.org |access-date=6 December 2020 |date=June 1999|doi=10.17487/RFC2616 }}</ref> उदाहरण के लिए जो एचटीटीपी योजनाओ को परिशोधित करता है। इसके साथ ही आईईटीएफ ने आरएफसी 3986 के डेटा को पूर्ण मानक एसटीडी 66 के रूप में प्रकाशित किया था जो एक आधिकारिक इंटरनेट प्रोटोकॉल के रूप में यूआरआई एल्गोरिथम की स्थापना को प्रदर्शित करता है।
 
2001 में, W3C के टेक्निकल आर्किटेक्चर ग्रुप (TAG) ने किसी दिए गए संसाधन के कई संस्करणों को प्रकाशित करने के लिए सर्वोत्तम प्रथाओं और प्रामाणिक URI के लिए एक गाइड प्रकाशित किया।<ref>{{cite web |last1=Raman |first1=T.V. |title=On Linking Alternative Representations To Enable Discovery And Publishing |url=https://www.w3.org/2001/tag/doc/alternatives-discovery.html |website=www.w3.org |access-date=6 December 2020 |date=1 November 2006}}</ref> उदाहरण के लिए, सामग्री उस सामग्री तक पहुँचने के लिए उपयोग की जाने वाली डिवाइस की क्षमता या सेटिंग्स के लिए समायोजित करने के लिए भाषा या आकार के अनुसार भिन्न हो सकती है।
 
अगस्त 2002 में, IETF {{IETF RFC|3305}}<ref>{{cite journal |last1=Mealling |first1=M. |editor-first1=M |editor-first2=R |editor-last1=Mealling |editor-last2=Denenberg |title=RFC 3305: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names |url=https://tools.ietf.org/html/rfc3305 |website=tools.ietf.org |access-date=6 December 2020 |date=August 2002|doi=10.17487/RFC3305 }}</ref> ने बताया कि व्यापक सार्वजनिक उपयोग के बावजूद यूआरएल शब्द अप्रचलन में फीका पड़ गया था, और केवल एक अनुस्मारक के रूप में कार्य करता है कि कुछ यूआरआई ऐसे वास्तविक उपयोग की परवाह किए बिना नेटवर्क पहुंच को लागू करने वाली योजनाओं के पते के रूप में कार्य करते हैं। जैसा कि यूआरआई-आधारित मानक जैसे संसाधन विवरण रूपरेखा स्पष्ट करते हैं, संसाधन पहचान को इंटरनेट पर संसाधन प्रतिनिधित्व की पुनर्प्राप्ति का सुझाव देने की आवश्यकता नहीं है, न ही उन्हें नेटवर्क-आधारित संसाधनों की आवश्यकता है।
 
[[सेमांटिक वेब]] वास्तविक दुनिया में दस्तावेज़ों और अवधारणाओं दोनों की पहचान करने के लिए HTTP URI योजना का उपयोग करता है, एक ऐसा भेद जिसके कारण भ्रम पैदा हो गया है कि दोनों को कैसे अलग किया जाए। TAG ने 2005 में समस्या को हल करने के तरीके पर एक ई-मेल प्रकाशित किया, जिसे httpRange-14 रिज़ॉल्यूशन के रूप में जाना जाने लगा।<ref>{{cite web |last1=Fielding |first1=Roy |title=[httpRange-14] Resolved |url=https://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html |website=lists.w3.org |access-date=6 December 2020 |date=18 Jun 2005}}</ref> W3C ने बाद में सिमेंटिक वेब के लिए कूल यूआरआई शीर्षक से एक रुचि समूह नोट प्रकाशित किया, जिसमें [[सामग्री बातचीत]] के उपयोग और पुनर्निर्देशन के लिए [[HTTP 303]] प्रतिक्रिया कोड को और अधिक विस्तार से समझाया गया है।<ref>{{cite web |last1=Sauermann |first1=Leo |title=Cool URIs for the Semantic Web |url=https://www.w3.org/TR/cooluris/ |website=www.w3.org |access-date=6 December 2020 |date=December 2008}}</ref>


2001 में,डब्ल्यू-3-सी के तकनीकी संरचनात्मक समूह (टीएजी) ने किसी दिए गए संसाधन के कई संस्करणों को प्रकाशित करने के लिए सर्वोत्तम प्रथाओं और प्रामाणिक यूआरआई के लिए एक निर्देशो को प्रकाशित किया।<ref>{{cite web |last1=Raman |first1=T.V. |title=On Linking Alternative Representations To Enable Discovery And Publishing |url=https://www.w3.org/2001/tag/doc/alternatives-discovery.html |website=www.w3.org |access-date=6 December 2020 |date=1 November 2006}}</ref> उदाहरण के लिए, उस डेटा तक अभिगमन के लिए उपयोग किए जाने वाले उपकरण की क्षमता या सेटिंग्स को समायोजित करने के लिए भाषा या आकार के अनुसार भिन्न हो सकती है। अगस्त 2002 में, आईईटीएफ {{IETF RFC|3305}}<ref>{{cite journal |last1=Mealling |first1=M. |editor-first1=M |editor-first2=R |editor-last1=Mealling |editor-last2=Denenberg |title=RFC 3305: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names |url=https://tools.ietf.org/html/rfc3305 |website=tools.ietf.org |access-date=6 December 2020 |date=August 2002|doi=10.17487/RFC3305 }}</ref> ने बताया कि व्यापक रूप से सार्वजनिक उपयोग के अतिरिक्त "यूआरएल" शब्द लगभग अप्रचलन में अपेक्षाकृत रूप से कम पड़ गया था और केवल एक पूर्ण रूप में कार्य करता है कि कुछ यूआरआई नेटवर्क उपलब्धता को प्रयुक्त करने वाली योजनाओं के माध्यम से एड्रेस के रूप में कार्य करते हैं, यद्यपि ऐसे ही किसी वास्तविक उपयोग के लिए जैसा कि यूआरआई-आधारित मानक जैसे संसाधन विवरण रूपरेखा स्पष्ट करते हैं संसाधन पहचान को इंटरनेट पर संसाधन प्रतिनिधित्व की पुनर्प्राप्ति का सुझाव देने की आवश्यकता नहीं होती है,और न ही उन्हें नेटवर्क-आधारित संसाधनों की आवश्यकता होती है।


[[सेमांटिक वेब]] वास्तविक समाज में दस्तावेज़ों और अवधारणाओं दोनों की पहचान करने के लिए एचटीटीपी यूआरआई योजना का उपयोग करता है एक ऐसी विशिष्टता जिसके कारण भ्रम उत्पन्न हो गया है कि दोनों को कैसे अलग किया जाए। टीएजी ने 2005 में इस समस्या को हल करने के तरीके पर एक ई-मेल प्रकाशित किया था जिसे एचटीटीपी श्रेणी-14 विश्लेषण के रूप में जाना जाता है।<ref>{{cite web |last1=Fielding |first1=Roy |title=[httpRange-14] Resolved |url=https://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html |website=lists.w3.org |access-date=6 December 2020 |date=18 Jun 2005}}</ref> डब्ल्यू-3-सी ने बाद में सिमेंटिक वेब के लिए कुल यूआरआईएस शीर्षक से एक स्थित समूह टिप्पणी प्रकाशित किया था जिसमें [[सामग्री बातचीत|डेटा]] के उपयोग और पुनर्निर्देशन के लिए [[HTTP 303|एचटीटीपी 303]] प्रतिक्रिया कोड को और अधिक विस्तृत रूप से समझाया गया है।<ref>{{cite web |last1=Sauermann |first1=Leo |title=Cool URIs for the Semantic Web |url=https://www.w3.org/TR/cooluris/ |website=www.w3.org |access-date=6 December 2020 |date=December 2008}}</ref>
== डिजाइन ==
== डिजाइन ==


=== यूआरएल और यूआरएन ===
=== यूआरएल और यूआरएन ===


[[समान संसाधन का नाम]] (URN) एक URI है जो किसी विशेष नामस्थान में नाम से संसाधन की पहचान करता है। एक URN का उपयोग किसी संसाधन के बारे में बात करने के लिए किया जा सकता है, बिना इसके स्थान या इसे कैसे एक्सेस किया जाए। उदाहरण के लिए, [[अंतर्राष्ट्रीय मानक पुस्तक संख्या]] (ISBN) प्रणाली में, <nowiki>ISBN</nowiki> 0-486-27557-4 शेक्सपियर के नाटक [[रोमियो और जूलियट]] के एक विशिष्ट संस्करण की पहचान करता है। उस संस्करण का यूआरएन <nowiki>urn:isbn:0-486-27557-4</nowiki> होगा। हालाँकि, यह इस बारे में कोई जानकारी नहीं देता है कि उस पुस्तक की प्रति कहाँ से प्राप्त करें।
[[समान संसाधन का नाम|यूआरएन]] एक प्रकार यूआरआई है जो किसी विशेष एड्रेस के उसके नाम के संसाधन की पहचान करता है। एक यूआरएन का उपयोग किसी संसाधन के विषय में वार्तालाप करने के लिए किया जा सकता है कि बिना किसी एड्रेस के इसको कैसे नियंत्रित किया जाए। उदाहरण के लिए, [[अंतर्राष्ट्रीय मानक पुस्तक संख्या]] (आईएसबीएन) प्रणाली में, आईएसबीएन 0-486-27557-4 के सर्वश्रेष्ठ नाटककार [[रोमियो और जूलियट]] के एक विशिष्ट संस्करण की पहचान करता है। उस संस्करण के लिए यूआरएन:आईएसबीएन:0-486-27557-4 होगा। हालाँकि, यह इस विषय में कोई भी जानकारी नहीं प्रदान करता है कि उस पुस्तक की प्रति को कहाँ से प्राप्त किया जा सकता है।


एक [[यूनिफ़ॉर्म रिसोर्स लोकेटर]] (यूआरएल) एक यूआरआई है जो किसी संसाधन पर कार्य करने या उसका प्रतिनिधित्व प्राप्त करने के साधन को निर्दिष्ट करता है, यानी इसकी प्राथमिक पहुंच तंत्र और नेटवर्क स्थान दोनों को निर्दिष्ट करता है। उदाहरण के लिए, यूआरएल <code><nowiki>http://example.org/wiki/Main_Page</nowiki></code> के रूप में पहचाने जाने वाले संसाधन को संदर्भित करता है <code><nowiki>/wiki/Main_Page</nowiki></code>, जिसका प्रतिनिधित्व [[हाइपरटेक्स्ट परहस्त शिष्टाचार]] (http:) के माध्यम से उस नेटवर्क होस्ट से प्राप्त किया जा सकता है जिसका [[डोमेन नाम]] है <code><nowiki>example.org</nowiki></code>. (इस मामले में, HTTP आमतौर पर इसे [[HTML]] और संबंधित कोड के रूप में होने का अर्थ देता है। व्यवहार में, यह जरूरी नहीं है, क्योंकि HTTP अपने हेडर में मनमाने प्रारूपों को निर्दिष्ट करने की अनुमति देता है।)
[[यूनिफ़ॉर्म रिसोर्स लोकेटर]] (यूआरएल) एक यूआरआई है जो किसी संसाधन पर कार्य करने या उसका प्रतिनिधित्व प्राप्त करने के साधन को निर्दिष्ट करता है अर्थात इसकी प्राथमिक अभिगमन तंत्र और नेटवर्क एड्रेस दोनों को निर्दिष्ट करता है। उदाहरण के लिए, यूआरएल <code><nowiki>http://example.org/wiki/Main_Page</nowiki></code> के रूप में पहचाने जाने वाले संसाधन को संदर्भित करता है <code><nowiki>/wiki/Main_Page</nowiki></code>, जिसका प्रतिनिधित्व [[हाइपरटेक्स्ट परहस्त शिष्टाचार|हाइपरटेक्स्ट ट्रान्सफर प्रोटोकॉल]] <code>http:</code> के माध्यम से उस नेटवर्क होस्ट से प्राप्त किया जा सकता है जिसका [[डोमेन नाम]] <code><nowiki>example.org</nowiki></code> है। इस स्थिति में, एचटीटीपी मे सामान्यतः इसका अर्थ [[HTML|एचटीएमएल]] और संबंधित कोड के रूप में होता है। प्रयोगात्मक रूप से यह आवश्यक नहीं होता है, क्योंकि एचटीटीपी अपने हेडर मेंअपेक्षाकृत प्रारूपों को निर्दिष्ट करने की स्वीकृति देता है। यूआरएन किसी व्यक्ति के नाम के अनुरूप होता है जबकि यूआरएल उनके भौतिक एड्रेस के अनुरूप होता है। दूसरे शब्दों में, एक यूआरएन एक वस्तु की पहचान करता है और एक यूआरएल इसे खोजने के लिए एक तरीका प्रदान करता है।


URN किसी व्यक्ति के नाम के अनुरूप होता है, जबकि URL उनके मोहल्ले के पते के अनुरूप होता है। दूसरे शब्दों में, एक यूआरएन एक वस्तु की पहचान करता है और एक यूआरएल इसे खोजने के लिए एक तरीका प्रदान करता है।
तकनीकी प्रकाशन विशेष रूप से [[आईईटीएफ]] और [[वर्ल्ड वाइड वेब]] द्वारा निर्मित मानक सामान्यतः 30 जुलाई 2001 की [[वर्ल्ड वाइड विशेषताओ]] में उल्लिखित एक दृश्य को प्रदर्शित करते हैं जो यूआरएल में किसी औपचारिक उपखंड का समर्थन करने के अतिरिक्त यूआरआई और यूआरएन शब्द की प्राथमिकता को स्वीकृत करता है। {{cquote|यूआरएल एक उपयोगी यूआरएल होता है लेकिन इसमे एक अनौपचारिक अवधारणा यह है कि एक यूआरएल एक प्रकार का यूआरआई है जो किसी संसाधन की पहचान उसकी कुछ अन्य विशेषताओं के अतिरिक्त उसके प्राथमिक नियंत्रण क्रियाविधि (जैसे, उसके नेटवर्क "एड्रेस") के प्रतिनिधित्व के माध्यम से करता है।<ref>{{cite web |last1=URI Planning Interest Group, W3C/IETF |title=URIs, URLs, and URNs: Clarifications and Recommendations 1.0 |url=https://www.w3.org/TR/uri-clarification/ |website=www.w3.org |publisher=W3C/IETF |access-date=8 December 2020 |date=September 2001}}</ref>}}
इस प्रकार, एक यूआरएल केवल एक यूआरआई है जो एक नेटवर्क पर एक संसाधन को इंगित करने के लिए होता है।{{efn|A report published in 2002 by a joint W3C/IETF working group aimed to normalize the divergent views held within the IETF and W3C over the relationship between the various 'UR*' terms and standards. While not published as a full standard by either organization, it has become the basis for the above common understanding and has informed many standards since then.}}{{sfnp|Joint W3C/IETF URI Planning Interest Group|2002}} हालांकि, गैर-तकनीकी संदर्भों में और वर्ल्ड वाइड वेब के लिए सॉफ्टवेयर में "यूआरएल" शब्द का व्यापक रूप से उपयोग किया जाता है। इसके अतिरिक्त शब्द "वेब एड्रेस" (जिसकी कोई औपचारिक परिभाषा नहीं होती है) प्रायः गैर-तकनीकी प्रकाशनों में यूआरआई के समानार्थी शब्द के रूप में उपयोग किया जाता है जो एचटीटीपी या एचटीटीपीएस योजनाओं का उपयोग करती है। इस प्रकार की धारणाएं कई समस्याए उत्पन्न कर सकती हैं उदाहरण के लिए एक्सएमएल नाम एड्रेस की स्थिति में निर्धारित यूआरआई के लिए डेटा समान होता है।


तकनीकी प्रकाशन, विशेष रूप से [[इंटरनेट इंजीनियरिंग टास्क फोर्स]] और [[विश्वव्यापी वेब संकाय]] द्वारा निर्मित मानक, आमतौर पर 30 जुलाई 2001 की [[W3C अनुशंसा]] में उल्लिखित एक दृश्य को दर्शाते हैं, जो URL में किसी औपचारिक उपखंड का समर्थन करने के बजाय URI शब्द की प्राथमिकता को स्वीकार करता है। और यूआरएन। {{cquote|URL is a useful but informal concept: a URL is a type of URI that identifies a resource via a representation of its primary access mechanism (e.g., its network "location"), rather than by some other attributes it may have.<ref>{{cite web |last1=URI Planning Interest Group, W3C/IETF |title=URIs, URLs, and URNs: Clarifications and Recommendations 1.0 |url=https://www.w3.org/TR/uri-clarification/ |website=www.w3.org |publisher=W3C/IETF |access-date=8 December 2020 |date=September 2001}}</ref>}}
[[व्हाटवग]] द्वारा निर्मित विनिर्देश यूआरआई पर यूआरएल अधिकृत किया जाता है और इसलिए नए एचटीएमएल 5 एपीआई यूआरआई पर यूआरएल का उपयोग करते हैं।<ref>{{cite web |title=URL Standard: 6.3. URL APIs elsewhere |url=https://url.spec.whatwg.org/#url-apis-elsewhere}}</ref> {{cquote|यूआरएल शब्द पर मानकीकरण यूआरआई और आईआरआई अंतर्राष्ट्रीयकृत संसाधन पहचानकर्ता अस्पष्ट हैं। प्रयोगात्मक रूप से दोनों के लिए एक ही एल्गोरिदम का उपयोग किया जाता है इसलिए उन्हें अलग करने से किसी की सहायता नहीं होती है। इसलिए यूआरएल खोज परिणाम को आसानी से प्राप्त कर सकता है।<ref>{{cite web |title=URL Standard: Goals |url=https://url.spec.whatwg.org/#goals}}</ref>}}
जैसे, एक URL केवल एक URI है जो किसी नेटवर्क पर किसी संसाधन को इंगित करने के लिए होता है।{{efn|A report published in 2002 by a joint W3C/IETF working group aimed to normalize the divergent views held within the IETF and W3C over the relationship between the various 'UR*' terms and standards. While not published as a full standard by either organization, it has become the basis for the above common understanding and has informed many standards since then.}}{{sfnp|Joint W3C/IETF URI Planning Interest Group|2002}} हालांकि, गैर-तकनीकी संदर्भों में और वर्ल्ड वाइड वेब के लिए सॉफ्टवेयर में, यूआरएल शब्द का व्यापक रूप से उपयोग किया जाता है। इसके अतिरिक्त, शब्द वेब पता (जिसकी कोई औपचारिक परिभाषा नहीं है) अक्सर गैर-तकनीकी प्रकाशनों में एक URI के पर्याय के रूप में होता है जो http या https योजनाओं का उपयोग करता है। ऐसी धारणाएं भ्रम पैदा कर सकती हैं, उदाहरण के लिए, XML नामस्थानों के मामले में जिनका #Relation to XML नामस्थान है।
जबकि अधिकांश यूआरआई योजनाओं को मूल रूप से एक विशेष [[प्रोटोकॉल (कंप्यूटिंग)]] के साथ उपयोग करने के लिए डिज़ाइन किया गया था और प्रायः इनका एक ही एड्रेस होता है वे प्रोटोकॉल से अर्थपूर्ण रूप से भिन्न होते हैं। उदाहरण के लिए, एचटीटीपी का उपयोग सामान्यतः एचटीटीपी [[वेब संसाधन|वेब संसाधनों]] के साथ परस्परिक क्रिया करने के लिए किया जाता है, लेकिन [[फ़ाइल यूआरआई योजना]] में कोई प्रोटोकॉल नहीं होता है।


[[WHATWG]] द्वारा निर्मित विनिर्देश यूआरआई पर यूआरएल पसंद करते हैं, और इसलिए नए एचटीएमएल 5 एपीआई यूआरआई पर यूआरएल का इस्तेमाल करते हैं।<ref>{{cite web |title=URL Standard: 6.3. URL APIs elsewhere |url=https://url.spec.whatwg.org/#url-apis-elsewhere}}</ref> {{cquote|Standardize on the term URL. URI and IRI [Internationalized Resource Identifier] are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.<ref>{{cite web |title=URL Standard: Goals |url=https://url.spec.whatwg.org/#goals}}</ref>}}
=== एल्गोरिथम ===
जबकि अधिकांश यूआरआई योजनाओं को मूल रूप से एक विशेष [[प्रोटोकॉल (कंप्यूटिंग)]] के साथ उपयोग करने के लिए डिज़ाइन किया गया था, और अक्सर एक ही नाम होता है, वे शब्दार्थ रूप से प्रोटोकॉल से भिन्न होते हैं। उदाहरण के लिए, योजना http का उपयोग आम तौर पर HTTP का उपयोग कर [[वेब संसाधन]]ों के साथ बातचीत करने के लिए किया जाता है, लेकिन योजना [[फ़ाइल यूआरआई योजना]] में कोई प्रोटोकॉल नहीं है।
{{see also|यूआरआई योजनाओं की सूची}}
यूआरआई में एक योजना है जो उस योजना के भीतर पहचानकर्ता निर्दिष्ट करने के लिए एक विनिर्देश को संदर्भित करती है। इस प्रकार, यूआरआई एल्गोरिथम एक संघीय और विस्तरणीय (एक्स्टेंसिबल) नामकरण प्रणाली है जिसमें प्रत्येक योजना के विनिर्देश उस योजना का उपयोग करने वाले पहचानकर्ताओं के एल्गोरिथम और सिमेंटिक्स को प्रतिबंधित कर सकते हैं। यूआरआई वर्गीय एल्गोरिथम सभी यूआरआई योजनाओं के एल्गोरिथम का एक उच्च समूह है। इसे पहली बार आरएफसी 2396 में परिभाषित किया गया था जिसे अगस्त 1998 में प्रकाशित किया गया था{{sfnp|RFC 2396|1998}} और जनवरी 2005 में प्रकाशित आरएफसी 3986 में इसे अंतिम रूप दिया गया था।{{sfnp|RFC 3986|2005}}


=== <स्पैन क्लास = एंकर आईडी = सिंटैक्स> </ स्पैन> सिंटेक्स ===
यूआरआई [[ASCII|एएससीआईआई]] वर्णों के निर्धारित सेट से बना होता है जिसमें आरक्षित वर्ण होते हैं जिनमे सामान्य <code>:</code>, <code>/</code>, <code>?</code>, <code>#</code>, <code>[</code>, <code>]</code> और <code>@</code> योजना या कार्यान्वयन-विशिष्ट <code>!</code>, <code>$</code>, <code>&</code>, <code>'</code>, <code>(</code>, <code>)</code>, <code>*</code>, <code>+</code>, <code>,</code>, <code>;</code>, और <code>=</code>),{{sfnp|RFC 3986|2005|loc=§2.2}} अनारक्षित वर्ण ([[लैटिन-लिपि वर्णमाला]], [[अरबी अंक]], <code>-</code>, <code>.</code>, <code>_</code>, <code>~</code>),{{sfnp|RFC 3986|2005|loc=§2.3}} और <code>%</code>. आदि आरक्षित वर्ण सम्मिलित है।{{sfnp|RFC 3986|2005|loc=§2.1}} एल्गोरिथम घटकों और उप-घटकों को आरक्षित वर्णों मे (केवल घटकों के लिए सामान्य आरक्षित वर्णों से) से सीमांकक द्वारा अलग किया जाता है और पहचान डेटा को अनारक्षित वर्णों या आरक्षित वर्णों के रूप में परिभाषित किया जाता है जो क्रमशः घटक और उप-घटक में सीमांकक के रूप में कार्य नहीं करते हैं{{sfnp|RFC 3986|2005|loc=§2}} और प्रतिशत-एन्कोडिंग जब संबंधित वर्ण निर्धारित समूह के बाहर या घटक के भीतर या एक सीमांकक के रूप में उपयोग किया जा जाता है। एक पहचान डेटा [[ऑक्टेट (कंप्यूटिंग)]] का प्रतिशत-एन्कोडिंग वर्णों से मिलकर तीन वर्णों का अनुक्रम होता है उसके बाद दो हेक्साडेसिमल अंक उस ऑक्टेट के सांख्यिक मान का प्रतिनिधित्व करते हैं।{{sfnp|RFC 3986|2005|loc=§2.1}}
{{see also|List of URI schemes}}
एक यूआरआई में एक योजना है जो उस योजना के भीतर पहचानकर्ता निर्दिष्ट करने के लिए एक विनिर्देश को संदर्भित करती है। इस प्रकार, यूआरआई सिंटैक्स एक संघीय और एक्स्टेंसिबल नामकरण प्रणाली है जिसमें प्रत्येक योजना के विनिर्देश उस योजना का उपयोग करने वाले पहचानकर्ताओं के सिंटैक्स और सिमेंटिक्स को और प्रतिबंधित कर सकते हैं। यूआरआई जेनेरिक सिंटैक्स सभी यूआरआई योजनाओं के सिंटैक्स का सुपरसेट है। में पहली बार परिभाषित किया गया था {{IETF RFC|2396}}, अगस्त 1998 में प्रकाशित,{{sfnp|RFC 2396|1998}} और में अंतिम रूप दिया {{IETF RFC|3986}}, जनवरी 2005 में प्रकाशित।{{sfnp|RFC 3986|2005}}
एक URI [[ASCII]] वर्णों के अनुमत सेट से बना होता है जिसमें आरक्षित वर्ण होते हैं (जेनेरिक: <code>:</code>, <code>/</code>, <code>?</code>, <code>#</code>, <code>[</code>, <code>]</code>, और <code>@</code>; योजना- या कार्यान्वयन-विशिष्ट: <code>!</code>, <code>$</code>, <code>&</code>, <code>'</code>, <code>(</code>, <code>)</code>, <code>*</code>, <code>+</code>, <code>,</code>, <code>;</code>, और <code>=</code>),{{sfnp|RFC 3986|2005|loc=§2.2}} अनारक्षित वर्ण ([[लैटिन-लिपि वर्णमाला]], [[अरबी अंक]], <code>-</code>, <code>.</code>, <code>_</code>, और <code>~</code>),{{sfnp|RFC 3986|2005|loc=§2.3}} और चरित्र <code>%</code>.{{sfnp|RFC 3986|2005|loc=§2.1}} सिंटैक्स घटकों और उप-घटकों को आरक्षित वर्णों (केवल घटकों के लिए सामान्य आरक्षित वर्णों से) से सीमांकक द्वारा अलग किया जाता है और पहचान डेटा को अनारक्षित वर्णों, आरक्षित वर्णों के रूप में परिभाषित किया जाता है जो क्रमशः घटक और उप-घटक में सीमांकक के रूप में कार्य नहीं करते हैं,{{sfnp|RFC 3986|2005|loc=§2}} और प्रतिशत-एन्कोडिंग जब संबंधित वर्ण अनुमत सेट के बाहर है या घटक के भीतर, या भीतर एक सीमांकक के रूप में उपयोग किया जा रहा है। एक पहचान डेटा [[ऑक्टेट (कंप्यूटिंग)]] का प्रतिशत-एन्कोडिंग चरित्र से मिलकर तीन वर्णों का अनुक्रम है <code>%</code> उसके बाद दो हेक्साडेसिमल अंक उस ऑक्टेट के सांख्यिक मान का प्रतिनिधित्व करते हैं।{{sfnp|RFC 3986|2005|loc=§2.1}}
<सेक्शन स्टार्ट = सिंटैक्स /><!-- This section is transcluded in other articles. See Help:Labeled section transclusion -->
URI जेनेरिक सिंटैक्स में पाँच घटक होते हैं जो बाएँ से दाएँ घटते महत्व के क्रम में क्रमबद्ध रूप से व्यवस्थित होते हैं:{{sfnp|RFC 3986|2005|loc=§3}}
<पूर्व>
यूआरआई = योजना: [// प्राधिकरण] पथ [? क्वेरी] [# टुकड़ा]
</पूर्व>


एक घटक अपरिभाषित है यदि उसके पास एक संबद्ध सीमांकक है और सीमांकक URI में प्रकट नहीं होता है; योजना और पथ घटक हमेशा परिभाषित होते हैं।{{sfnp|RFC 3986|2005|loc=§5.2.1}} कोई घटक रिक्त है यदि उसमें कोई वर्ण नहीं है; योजना घटक हमेशा खाली नहीं होता है।{{sfnp|RFC 3986|2005|loc=§3}}
यूआरआई एल्गोरिथम में पाँच घटक होते हैं जो बाएँ से दाएँ घटते महत्व के अनुक्रम में क्रमबद्ध रूप से व्यवस्थित होते हैं:{{sfnp|RFC 3986|2005|loc=§3}}
प्राधिकरण घटक में उप-घटक होते हैं:
RI = scheme ":" ["//" authority] path ["?" query] ["#" fragment]
एक घटक अपरिभाषित होता है यदि उसके पास एक संबद्ध सीमांकक होता है और सीमांकक यूआरआई में प्रकट नहीं होता है; योजना और एड्रेस घटक सदैव परिभाषित होते हैं।{{sfnp|RFC 3986|2005|loc=§5.2.1}} कोई घटक तब रिक्त होता है जब उसमें कोई वर्ण नहीं होता है योजना घटक सदैव रिक्त नहीं होता है।{{sfnp|RFC 3986|2005|loc=§3}} क्योकि प्राधिकरण घटक में सदैव उप-घटक होते हैं:
authority = [userinfo "@"] host [":" port]
यह [[सिंटैक्स आरेख|एल्गोरिथम आरेख]] में इस प्रकार प्रदर्शित किया गया है:


<पूर्व>
[[File:URI syntax diagram.svg|यूआरआई सिंटैक्स आरेख|1115x1115px]]यूआरआई में निम्न अनुक्रम सम्मिलित होते हैं:
प्राधिकरण = [उपयोगकर्ता जानकारी @] होस्ट [: पोर्ट]
* एक गैर-रिक्त योजना घटक जिसके बाद एक कोलन (<code>:</code>) होता है जिसमें एक अक्षर से शुरू होने वाले वर्णों का अनुक्रम होता है और अक्षरों, अंकों, प्लस (<code>+</code>), समय (<code>.</code>) या हाइफ़न (<code>-</code>) के किसी भी संयोजन के बाद होता है। हालांकि योजनाएँ केस-असंवेदनशील होती हैं, निहित रूप से लोअरकेस और योजनाओं को निर्दिष्ट करने वाले दस्तावेज़ों को लोअरकेस अक्षरों के साथ ऐसा करना चाहिए। लोकप्रिय योजनाओं के उदाहरणों में <code>[[Hypertext Transfer Protocol|http]]</code>, <code>[[HTTP Secure|https]]</code>, <code>[[File Transfer Protocol|ftp]]</code>, <code>[[mailto]]</code>, <code>[[File URI scheme|file]]</code>, <code>[[Data URI scheme|data]]</code> और <code>[[Internet Relay Chat#URI scheme|irc]]</code> सम्मिलित हैं। यूआरआई योजनाओं को [[Internet Assigned Numbers Authority|इंटरनेट निरुपित संख्या प्राधिकरण]] (आईएएनए) के साथ पंजीकृत होना चाहिए, हालांकि गैर-पंजीकृत योजनाओं का प्रयोगात्मक रूप से उपयोग किया जाता है।{{efn|The procedures for registering new URI schemes were originally defined in 1999 by {{IETF RFC|2717}}, and are now defined by {{IETF RFC|7595|link=no}}, published in June 2015.{{sfnp|IETF|2015}}}}  
</पूर्व>
*दो स्लैश (<code>//</code>) से पहले से ही एक वैकल्पिक प्राधिकरण घटक मे सम्मिलित होते हैं:
 
** एक वैकल्पिक <code>userinfo</code>उप-घटक जिसके बाद एक प्रतीक <code>@</code> होता है, जिसमें एक [[उपयोगकर्ता (कंप्यूटिंग)]] नाम और एक कोलन (:) से पहले एक वैकल्पिक [[पासवर्ड]] सम्मिलित हो सकता है।
यह [[सिंटैक्स आरेख]] में इस प्रकार दर्शाया गया है:
**जिसके पहले कोलन (<code>:</code>). प्रारूप का उपयोग <code>username:password</code> <code>userinfo</code> उप-घटक में सुरक्षा कारणों से हटा दिया गया है। ऐप्लिकेशन को पहले कोलन (<code>:</code>) एक<code>userinfo</code> उपघटक के भीतर पाया जाता है जब तक कि कोलन के बाद का डेटा रिक्त स्ट्रिंग के रूप मे कोई पासवर्ड नहीं दर्शाता है।
 
** एक होस्ट उप-घटक, जिसमें एक पंजीकृत नाम ([[होस्ट का नाम|होस्ट नाम]] सहित लेकिन सीमित नहीं होता है) या एक आईपी एड्रेस सम्मिलित होता है। [[IPv4|आईपीवी 4]] एड्रेस डॉट-दशमलव संकेतन में होने चाहिए और आईपीवी-6 एड्रेस कोष्ठक (<code>[]</code>) में संलग्न होने चाहिए।{{sfnp|RFC 3986|2005|loc=§3.2.2}}{{efn|For URIs relating to resources on the World Wide Web, some web browsers allow {{code|.0}} portions of dot-decimal notation to be dropped or raw integer IP addresses to be used.{{sfnp|Lawrence|2014}}}}
[[File:URI syntax diagram.svg|यूआरआई सिंटैक्स आरेख]]यूआरआई में शामिल हैं:
** दशमलव अंकों से मिलकर एक कोलन (<code>:</code>) से पहले एक वैकल्पिक पोर्ट उपघटक होता है।
* एक गैर-रिक्त{{visible anchor|scheme}}घटक के बाद एक कोलन (<code>:</code>), एक अक्षर से शुरू होने वाले वर्णों के अनुक्रम से मिलकर बनता है और उसके बाद अक्षरों, अंकों के किसी भी संयोजन के साथ (<code>+</code>), अवधि (<code>.</code>), या हाइफ़न (<code>-</code>). हालांकि योजनाएँ केस-असंवेदनशील हैं, विहित रूप लोअरकेस है और योजनाओं को निर्दिष्ट करने वाले दस्तावेज़ों को लोअरकेस अक्षरों के साथ ऐसा करना चाहिए। लोकप्रिय योजनाओं के उदाहरणों में शामिल हैं <code>[[Hypertext Transfer Protocol|http]]</code>, <code>[[HTTP Secure|https]]</code>, <code>[[File Transfer Protocol|ftp]]</code>, <code>[[mailto]]</code>, <code>[[File URI scheme|file]]</code>, <code>[[Data URI scheme|data]]</code> और <code>[[Internet Relay Chat#URI scheme|irc]]</code>. URI योजनाओं को [[Internet Assigned Numbers Authority]]|Internet Assigned Numbers Authority (IANA) के साथ पंजीकृत होना चाहिए, हालांकि व्यवहार में गैर-पंजीकृत योजनाओं का उपयोग किया जाता है।{{efn|The procedures for registering new URI schemes were originally defined in 1999 by {{IETF RFC|2717}}, and are now defined by {{IETF RFC|7595|link=no}}, published in June 2015.{{sfnp|IETF|2015}}}}
* एक एड्रेस घटक जिसमें स्लैश (<code>/</code>) द्वारा अलग किए गए एड्रेस खंडों का अनुक्रम सम्मिलित होता है। और यूआरआई के लिए एक एड्रेस सदैव परिभाषित किया जाता है, हालांकि परिभाषित एड्रेस रिक्त (शून्य लंबाई) हो सकता है। एक खंड रिक्त भी हो सकता है जिसके परिणामस्वरूप एड्रेस घटक में निरंतर दो स्लैश (<code>//</code>) हो सकते हैं। एक एड्रेस घटक एक फाइल सिस्टम एड्रेस के समान या मानचित्रित हो सकता है लेकिन सदैव किसी एक से संबंध नहीं दर्शाता है। यदि एक प्राधिकरण घटक परिभाषित किया गया है तो एड्रेस घटक या तो रिक्त होना चाहिए या स्लैश (<code>/</code>) से प्रारम्भ होना चाहिए। यदि एक प्राधिकरण घटक अपरिभाषित है तो एड्रेस एक रिक्त खंड के साथ प्रारम्भ नहीं हो सकता है अर्थात, दो स्लैश (<code>//</code>) के साथ क्योंकि निम्नलिखित वर्णों को प्राधिकरण घटक के रूप में समझा जा सकता है।{{sfnp|RFC 2396|1998|loc=§3.3}}
* एक वैकल्पिक{{visible anchor|authority}}घटक दो स्लैश से पहले (<code>//</code>), जिसमें शामिल हैं:
: परिपाटी के अनुसार, एचटीटीपी और एचटीटीपीएस यूआरआई में एड्रेस के अंतिम भाग का नाम होता है{{visible anchor|pathinfo}}और यह वैकल्पिक है। यह शून्य या अधिक एड्रेस खंडों से बना है जो एक मौजूदा भौतिक संसाधन नाम (जैसे एक फ़ाइल, एक आंतरिक मॉड्यूल प्रोग्राम या एक निष्पादन योग्य प्रोग्राम) को संदर्भित नहीं करता है, लेकिन एक तार्किक भाग (जैसे एक कमांड या क्वालीफायर भाग) के लिए होता है एड्रेस के पहले भाग के लिए अलग से पारित किया जाना चाहिए जो एक निष्पादन योग्य मॉड्यूल या [[वेब सर्वर]] द्वारा प्रबंधित प्रोग्राम की पहचान करता है; इसका उपयोग प्रायः गतिशील सामग्री (दस्तावेज़ इत्यादि) का चयन करने या अनुरोध के अनुसार इसे अनुकूलित करने के लिए किया जाता है (यह भी देखें: [[कॉमन गेटवे इंटरफ़ेस]] और PATH_INFO, आदि)।
** एक वैकल्पिक{{visible anchor|userinfo}}उपघटक के बाद एक प्रतीक पर (<code>@</code>), जिसमें एक [[उपयोगकर्ता (कंप्यूटिंग)]] और एक वैकल्पिक [[पासवर्ड]] शामिल हो सकता है, जिसके पहले कोलन (<code>:</code>). प्रारूप का उपयोग <code>username:password</code> userinfo उप-घटक में सुरक्षा कारणों से हटा दिया गया है। ऐप्लिकेशन को पहले कोलन (<code>:</code>) एक userinfo उपघटक के भीतर पाया जाता है जब तक कि कोलन के बाद का डेटा खाली स्ट्रिंग नहीं है (कोई पासवर्ड नहीं दर्शाता है)।
:अधिवेशन के अनुसार, एचटीटीपी और एचटीटीपीएस यूआरआई में एड्रेस के अंतिम भाग को 'एड्रेसइन्फो' नाम दिया गया है और यह वैकल्पिक है। यह शून्य या अधिक एड्रेस खंडों से बना होता है जो एक सम्मिलित भौतिक संसाधन नाम (जैसे फ़ाइल, आंतरिक मॉड्यूल प्रोग्राम या एक निष्पादन योग्य प्रोग्राम) को संदर्भित नहीं करता है लेकिन एक तार्किक भाग (जैसे एक कमांड या क्वालीफायर भाग) के लिए होता है एड्रेस के पहले भाग के लिए अलग से इसे निर्धारित किया जाता है जो एक निष्पादन योग्य मॉड्यूल या वेब सर्वर द्वारा प्रबंधित प्रोग्राम की पहचान करता है इसका उपयोग प्रायः गतिशील डेटा (दस्तावेज़, आदि) का चयन करने या अनुरोध के अनुसार इसे अनुकूलित करने के लिए किया जाता है।
** ए{{visible anchor|host}}उप-घटक, जिसमें या तो एक पंजीकृत नाम ([[होस्ट का नाम]] सहित लेकिन सीमित नहीं) या एक आईपी पता शामिल है। [[IPv4]] पते डॉट-दशमलव संकेतन में होने चाहिए, और IPv6 पते कोष्ठक में संलग्न होने चाहिए (<code>[]</code>).{{sfnp|RFC 3986|2005|loc=§3.2.2}}{{efn|For URIs relating to resources on the World Wide Web, some web browsers allow {{code|.0}} portions of dot-decimal notation to be dropped or raw integer IP addresses to be used.{{sfnp|Lawrence|2014}}}}
:उदाहरण: यूआरआई: {{code|1="http://www.example.com/questions/3456/my-document"}}  
** एक वैकल्पिक{{visible anchor|port}}एक कोलन से पहले उपघटक (<code>:</code>), दशमलव अंकों से मिलकर।
:जहाँ : {{code|1="/questions"}} एड्रेस का पहला भाग है जो एक निष्पादन योग्य मॉड्यूल या प्रोग्राम और {{code|1="/3456/my-document"}} नामक एड्रेस का दूसरा भाग है जिसे निष्पादन योग्य मॉड्यूल या प्रोग्राम नाम दिया गया है {{code|1="/questions"}} अनुरोधित दस्तावेज़ का चयन करने के लिए एक एचटीटीपी और एचटीटीपीएस यूआरआई जिसमें क्वेरी भाग के अतिरिक्त एड्रेसिनफो भाग होता है उसे 'क्लीन यूआरएल' के रूप में संदर्भित किया जा सकता है जिसका अंतिम भाग 'स्लग' हो सकता है।
* ए{{visible anchor|path}}घटक, एक स्लैश द्वारा अलग किए गए पथ खंडों के अनुक्रम से मिलकर (<code>/</code>). एक यूआरआई के लिए एक पथ हमेशा परिभाषित किया जाता है, हालांकि परिभाषित पथ खाली (शून्य लंबाई) हो सकता है। एक खंड खाली भी हो सकता है, जिसके परिणामस्वरूप लगातार दो स्लैश (<code>//</code>) पथ घटक में। एक पथ घटक एक [[पथ (कंप्यूटिंग)]] के समान या मैप कर सकता है, लेकिन हमेशा किसी एक के साथ संबंध नहीं दर्शाता है। यदि एक प्राधिकरण घटक परिभाषित किया गया है, तो पथ घटक या तो खाली होना चाहिए या स्लैश से शुरू होना चाहिए (<code>/</code>). यदि एक प्राधिकरण घटक अपरिभाषित है, तो पथ एक खाली खंड से शुरू नहीं हो सकता है - अर्थात, दो स्लैश के साथ (<code>//</code>)—चूंकि निम्नलिखित वर्णों की व्याख्या एक प्राधिकरण घटक के रूप में की जाएगी।{{sfnp|RFC 2396|1998|loc=§3.3}}
: परिपाटी के अनुसार, http और https URI में, ''पथ'' के अंतिम भाग का नाम होता है{{visible anchor|pathinfo}}और यह वैकल्पिक है। यह शून्य या अधिक पथ खंडों से बना है जो एक मौजूदा भौतिक संसाधन नाम (जैसे एक फ़ाइल, एक आंतरिक मॉड्यूल प्रोग्राम या एक निष्पादन योग्य प्रोग्राम) को संदर्भित नहीं करता है, लेकिन एक तार्किक भाग (जैसे एक कमांड या क्वालीफायर भाग) के लिए होता है पथ के पहले भाग के लिए अलग से पारित किया जाना चाहिए जो एक निष्पादन योग्य मॉड्यूल या [[वेब सर्वर]] द्वारा प्रबंधित प्रोग्राम की पहचान करता है; इसका उपयोग अक्सर गतिशील सामग्री (दस्तावेज़ इत्यादि) का चयन करने या अनुरोध के अनुसार इसे अनुकूलित करने के लिए किया जाता है (यह भी देखें: [[कॉमन गेटवे इंटरफ़ेस]] और PATH_INFO, आदि)।
: उदाहरण:
:: यूआरआई: {{code|1="http://www.example.com/questions/3456/my-document"}}
:: कहाँ: {{code|1="/questions"}} पथ का पहला भाग है (एक निष्पादन योग्य मॉड्यूल या प्रोग्राम) और {{code|1="/3456/my-document"}} पाथिनफो नामक पथ का दूसरा भाग है, जिसे निष्पादन योग्य मॉड्यूल या प्रोग्राम नाम से पास किया जाता है {{code|1="/questions"}} अनुरोधित दस्तावेज़ का चयन करने के लिए।
: #query भाग के बिना ''pathinfo'' भाग वाले एक http या https URI को 'क्लीन URL' के रूप में भी संदर्भित किया जा सकता है, जिसका अंतिम भाग 'क्लीन URL#स्लग' हो सकता है।


{| class="wikitable" style="float: right; font-size: 0.9em; margin-left: 1em"
{| class="wikitable" style="float: right; font-size: 0.9em; margin-left: 1em"
|-
|-
! Query delimiter
! क्वेरी सीमांकक
! Example
! उदाहरण
|-
|-
| Ampersand (<code>&amp;</code>)
| एम्पसेंड (<code>&amp;</code>)
| <code>key1=value1&key2=value2</code>
| <code>key1=value1&key2=value2</code>
|-
|-
| Semicolon (<code>;</code>){{efn|Historic {{IETF RFC|1866}} (obsoleted by {{IETF RFC|2854|link=no}}) encourages CGI authors to support ';' in addition to '&'.{{sfnp|RFC 1866|1995|loc=§8.2.1}}}}
| सेमीकोलन (<code>;</code>){{efn|Historic {{IETF RFC|1866}} (obsoleted by {{IETF RFC|2854|link=no}}) encourages CGI authors to support ';' in addition to '&'.{{sfnp|RFC 1866|1995|loc=§8.2.1}}}}
| <code>key1=value1;key2=value2</code>
| <code>key1=value1;key2=value2</code>
|}
|}
* एक वैकल्पिक{{visible anchor|query}}एक प्रश्न चिह्न से पहले घटक (<code>?</code>), गैर-श्रेणीबद्ध डेटा की एक [[क्वेरी स्ट्रिंग]] से मिलकर। इसका सिंटैक्स अच्छी तरह से परिभाषित नहीं है, लेकिन परिपाटी के अनुसार यह अक्सर विशेषता-मान जोड़े का एक क्रम होता है जो एक सीमांकक द्वारा अलग किया जाता है।
* प्रश्न चिह्न (<code>?</code>) से पहले एक वैकल्पिक क्वेरी घटक, जिसमें गैर-श्रेणीबद्ध डेटा की [[क्वेरी स्ट्रिंग]] सम्मिलित होता है। इसका सिंटैक्स अपेक्षाकृत रूप से परिभाषित नहीं होता है लेकिन अधिवेशन के अनुसार यह प्रायः विशेष मान श्रंखला का एक अनुक्रम होता है जो एक सीमांकक द्वारा अलग किया जाता है।
* एक वैकल्पिक{{visible anchor|fragment}}घटक [[संख्या चिह्न]] से पहले (<code>#</code>). फ़्रैगमेंट में एक [[टुकड़ा पहचानकर्ता]] होता है जो द्वितीयक संसाधन को दिशा प्रदान करता है, जैसे कि किसी लेख में अनुभाग शीर्षक, जिसे शेष URI द्वारा पहचाना जाता है। जब प्राथमिक संसाधन एक HTML दस्तावेज़ होता है, तो फ़्रैगमेंट अक्सर एक HTML#Attributes| होता है<code>id</code> एक विशिष्ट तत्व की विशेषता, और वेब ब्राउज़र इस तत्व को देखने के लिए स्क्रॉल करेंगे। <सेक्शन एंड = सिंटैक्स />
* एक हैश (<code>#</code>) से पहले एक वैकल्पिक घटक भाग में एक एड्रेस [[टुकड़ा पहचानकर्ता|पहचानकर्ता]] होता है जो द्वितीयक संसाधन को दिशा प्रदान करता है जैसे कि किसी लेख में अनुभाग शीर्षक, जिसे शेष यूआरआई द्वारा पहचाना जाता है। जब प्राथमिक संसाधन एक एचटीएमएल दस्तावेज़ होता है, तो खंड प्रायः एक विशिष्ट तत्व की एक आईडी विशेषता होती है और वेब ब्राउज़र इस तत्व को देखने के लिए स्क्रॉल करते है।
 
योजना- या कार्यान्वयन-विशिष्ट आरक्षित वर्ण <code>+</code> योजना में इस्तेमाल किया जा सकता है, उपयोगकर्ता जानकारी, होस्ट, पथ, क्वेरी, और खंड, और योजना- या कार्यान्वयन-विशिष्ट आरक्षित वर्ण <code>!</code>, <code>$</code>, <code>&</code>, <code>'</code>, <code>(</code>, <code>)</code>, <code>*</code>, <code>,</code>, <code>;</code>, और <code>=</code> उपयोगकर्ता जानकारी, होस्ट, पथ, क्वेरी और खंड में उपयोग किया जा सकता है। इसके अतिरिक्त, सामान्य आरक्षित वर्ण <code>:</code> उपयोगकर्ता जानकारी, पथ, क्वेरी और खंड, सामान्य आरक्षित वर्णों में उपयोग किया जा सकता है <code>@</code> और <code>/</code> पथ, क्वेरी और खंड, और सामान्य आरक्षित वर्ण में उपयोग किया जा सकता है <code>?</code> क्वेरी और खंड में इस्तेमाल किया जा सकता है।{{sfnp|RFC 3986|2005|loc=§A}}
 


योजना या कार्यान्वयन-विशिष्ट आरक्षित वर्ण <code>+</code> का उपयोग योजना, उपयोगकर्ता जानकारी, होस्ट, एड्रेस, क्वेरी और खंड और योजना या कार्यान्वयन-विशिष्ट आरक्षित वर्णों में किया जा सकता है या विशिष्ट आरक्षित वर्णों <code>!</code>, <code>$</code>, <code>&</code>, <code>'</code>, <code>(</code>, <code>)</code>, <code>*</code>, <code>,</code>, <code>;</code>, और <code>=</code> का उपयोग उपयोगकर्ता इन्फो, होस्ट, एड्रेस, क्वेरी और फ्रैगमेंट में किया जा सकता है। इसके अतिरिक्त, सामान्य आरक्षित वर्ण <code>:</code> का उपयोग उपयोगकर्ताइन्फो, पथ, क्वेरी और खंड में किया जा सकता है, सामान्य आरक्षित वर्ण <code>@</code> और <code>/</code>का उपयोग एड्रेस, क्वेरी और खंड में किया जा सकता है और सामान्य आरक्षित वर्ण <code>?</code> क्वेरी और खंड के रूप मे उपयोग किया जा सकता है।{{sfnp|RFC 3986|2005|loc=§A}}
=== उदाहरण यूआरआई ===
=== उदाहरण यूआरआई ===


निम्नलिखित आंकड़ा उदाहरण यूआरआई और उनके घटक भागों को प्रदर्शित करता है।
निम्नलिखित डेटा उदाहरण यूआरआई और उनके घटक भागों को प्रदर्शित करता है।


{{Pre|<nowiki/>
{{Pre|1=userinfo      host      port
          {{color|rgb(0, 76, 178)|userinfo}}       {{color|rgb(0, 177, 17)|host}}     {{color|rgb(178, 111, 0)|port}}
           ┌──┴───┐ ┌──────┴──────┐ ┌┴┐
           {{color|rgb(0, 76, 178)|┌──┴───┐}} {{color|rgb(0, 177, 17)|┌──────┴──────┐}} {{color|rgb(178, 111, 0)|┌┴┐}}
   https://john.doe@www.example.com:123/forum/questions/?tag=networking&order=newest#top
   <nowiki>https://john.doe@www.example.com:123/forum/questions/?tag=networking&order=newest#top</nowiki>
   └─┬─┘  └───────────┬──────────┘    └───────┬───────┘ └────────────┬────────────┘ └┬┘
   {{color|rgb(178, 111, 0)|└─┬─┘}}   {{color|rgb(176, 0, 177)|└───────────┬──────────┘}}   {{color|rgb(0, 76, 178)|└───────┬───────┘}} {{color|rgb(0, 178, 17)|└────────────┬────────────┘}} {{color|rgb(178, 111, 0)|└┬┘}}
   scheme          authority                  path                  query          fragment
   {{color|rgb(178, 111, 0)|scheme}}         {{color|rgb(176, 0, 177)|authority}}                 {{color|rgb(0, 76, 178)|path}}                 {{color|rgb(0, 178, 17)|{{color|rgb(0, 178, 17)|query}}}}           {{color|rgb(178, 111, 0)|fragment}}
<nowiki>ldap://[2001:db8::7]/c=GB?objectClass?one</nowiki> 
{{color|rgb(178, 111, 0)|└┬─┘}}  {{color|rgb(176, 0, 177)|└─────┬─────┘}}{{color|rgb(0, 76, 178)|└─┬─┘}} {{color|rgb(0, 178, 17)|└──────┬──────┘}}
  {{color|rgb(178, 111, 0)|scheme}}  {{color|rgb(176, 0, 177)|authority}}  {{color|rgb(0, 76, 178)|path}}      {{color|rgb(0, 178, 17)|query}}
<nowiki>mailto:John.Doe@example.com</nowiki> 
{{color|rgb(178, 111, 0)|└─┬──┘}} {{color|rgb(0, 76, 178)|└────┬─────────────┘}}
  {{color|rgb(178, 111, 0)|scheme}}    {{color|rgb(0, 76, 178)|path}}
<nowiki>news:comp.infosystems.www.servers.unix</nowiki> 
{{color|rgb(178, 111, 0)|└┬─┘}} {{color|rgb(0, 76, 178)|└─────────────┬─────────────────┘}}
  {{color|rgb(178, 111, 0)|scheme}}            {{color|rgb(0, 76, 178)|path}}
<nowiki>टेलीः+1-816-555-1212</nowiki> 
{{color|rgb(178, 111, 0)|└┬┘}} {{color|rgb(0, 76, 178)|└──────┬──────┘}}
  {{color|rgb(178, 111, 0)|scheme}}    {{color|rgb(0, 76, 178)|path}}
<nowiki>टेलनेट://192.0.2.16:80/</nowiki> 
{{color|rgb(178, 111, 0)|└─┬──┘}}  {{color|rgb(176, 0, 177)|└─────┬─────┘}}{{color|rgb(0, 76, 178)|│}}
  {{color|rgb(178, 111, 0)|scheme}}    {{color|rgb(176, 0, 177)|authority}}  {{color|rgb(0, 76, 178)|path}}
<nowiki>urn:oasis:names:specification:docbook:dtd:xml:4.1.2</nowiki> 
{{color|rgb(178, 111, 0)|└┬┘}} {{color|rgb(0, 76, 178)|└──────────────────────┬──────────────────────┘}}
  {{color|rgb(178, 111, 0)|scheme}}                    {{color|rgb(0, 76, 178)|path}}
}}


डीओआई ([[डिजिटल ऑब्जेक्ट पहचानकर्ता]]) [[हैंडल सिस्टम]] के भीतर फिट होते हैं और यूआरआई सिस्टम, हैंडल सिस्टम # डीओआई-हैंडल-यूआरआई के भीतर फिट होते हैं।<!--Per the [[Digital object identifier]] and [[Handle System]] articles, which see.-->
  ldap://[2001:db8::7]/c=GB?objectClass?one
  └┬─┘  └─────┬─────┘└─┬─┘ └──────┬──────┘
  scheme  authority  path      query


  mailto:John.Doe@example.com
  └─┬──┘ └────┬─────────────┘
  scheme    path


=== यूआरआई संदर्भ ===
  news:comp.infosystems.www.servers.unix
  └┬─┘ └─────────────┬─────────────────┘
  scheme            path


एक URI संदर्भ या तो एक URI या एक सापेक्ष संदर्भ होता है जब यह एक योजना घटक के साथ शुरू नहीं होता है जिसके बाद एक कोलन होता है (<code>:</code>).{{sfnp|RFC 3986|2005|loc=§4.1}} एक पथ खंड जिसमें एक कोलन वर्ण होता है (उदा., <code>foo:bar</code>) का उपयोग सापेक्ष संदर्भ के पहले पथ खंड के रूप में नहीं किया जा सकता है यदि इसका पथ घटक स्लैश से शुरू नहीं होता है (<code>/</code>), क्योंकि यह एक योजना घटक के लिए गलत होगा। इस तरह के पाथ सेगमेंट के पहले एक डॉट पाथ सेगमेंट होना चाहिए (उदाहरण के लिए, <code>./foo:bar</code>).{{sfnp|RFC 3986|2005|loc=§4.2}}
  tel:+1-816-555-1212
वेब दस्तावेज़ मार्कअप भाषाएँ अन्य संसाधनों, जैसे बाहरी दस्तावेज़ों या समान तार्किक दस्तावेज़ के विशिष्ट भागों को इंगित करने के लिए अक्सर URI संदर्भों का उपयोग करती हैं:{{sfnp|RFC 3986|2005|loc=§4.4}}
  └┬┘ └──────┬──────┘
* HTML में, का मान <code>src</code> की विशेषता <code>img</code> तत्व एक यूआरआई संदर्भ प्रदान करता है, जैसा कि का मान करता है <code>href</code> की विशेषता <code>a</code> या <code>link</code> तत्व;
  scheme    path
* [[XML]] में, के बाद प्रदर्शित होने वाला [[सिस्टम पहचानकर्ता]] <code>SYSTEM</code> दस्तावेज़ प्रकार की परिभाषा में कीवर्ड एक खंड रहित URI संदर्भ है;
* [[XSLT]] में, का मान <code>href</code> की विशेषता <code>xsl:import</code> तत्व/निर्देश एक यूआरआई संदर्भ है; इसी तरह पहला तर्क <code>document()</code> समारोह।


<पूर्व>
  telnet://192.0.2.16:80/
https://example.com/path/resource.txt#fragment
  └─┬──┘  └─────┬─────┘│
//example.com/path/resource.txt
  scheme    authority  path
/पथ/संसाधन.txt
पथ/संसाधन.txt
../resource.txt
./resource.txt
संसाधन.txt
#टुकड़ा
</पूर्व>


=== संकल्प ===
  urn:oasis:names:specification:docbook:dtd:xml:4.1.2
  └┬┘ └──────────────────────┬──────────────────────┘
  scheme                    path}}


आधार URI के विरुद्ध URI संदर्भ को हल करने से लक्ष्य URI बनता है। इसका तात्पर्य है कि आधार यूआरआई मौजूद है और एक पूर्ण यूआरआई है (एक यूआरआई जिसमें कोई खंड घटक नहीं है)। पूर्वता के क्रम में आधार URI प्राप्त किया जा सकता है:{{sfnp|RFC 3986|2005|loc=§5.1}}
डीओआई [[डिजिटल ऑब्जेक्ट पहचानकर्ता|(डिजिटल ऑब्जेक्ट पहचानकर्ता]]) [[हैंडल सिस्टम|नियंत्रण सिस्टम]] के भीतर प्रयुक्त होते हैं और यूआरआई सिस्टम के भीतर फिट होते हैं, जैसा कि उपयुक्त एल्गोरिथम द्वारा सुविधा प्रदान की जाती है।
* संदर्भ यूआरआई ही अगर यह एक यूआरआई है;
=== यूआरआई संदर्भ ===
* प्रतिनिधित्व की सामग्री;
* प्रतिनिधित्व को समाहित करने वाली इकाई;
* यूआरआई प्रतिनिधित्व की वास्तविक पुनर्प्राप्ति के लिए उपयोग किया जाता है;
* आवेदन का संदर्भ।


के एक अच्छी तरह से परिभाषित आधार यूआरआई के साथ एक प्रतिनिधित्व के भीतर
यूआरआई संदर्भ या तो एक यूआरआई या एक सापेक्ष संदर्भ होता है, जब यह एक योजना घटक के बाद एक कोलन <code>:</code> के साथ प्रारम्भ नहीं होता है।{{sfnp|RFC 3986|2005|loc=§4.1}} तब एक एड्रेस खंड जिसमें एक कोलन वर्ण होता है (उदाहरण के लिए, <code>foo:bar</code>) को सापेक्ष संदर्भ के पहले एड्रेस खंड के रूप में उपयोग नहीं किया जा सकता है यदि इसका एड्रेस घटक स्लैश (<code>/</code>) से प्रारम्भ नहीं होता है क्योंकि यह एक योजना घटक के लिए गलत होता है इस प्रकार के एड्रेस सेगमेंट <code>./foo:bar</code> के पहले एक डॉट एड्रेस सेगमेंट होता है। {{sfnp|RFC 3986|2005|loc=§4.2}}


<पूर्व>
वेब दस्तावेज़ मार्कअप भाषाएँ अन्य संसाधनों, जैसे बाहरी दस्तावेज़ों या समान तार्किक दस्तावेज़ के विशिष्ट भागों को इंगित करने के लिए प्रायः यूआरआई संदर्भों का उपयोग करती हैं:{{sfnp|RFC 3986|2005|loc=§4.4}}
http://a/b/c/d;p?q
* एचटीएमएल में, <code>img</code> तत्व की <code>src</code> विशेषता का मान एक यूआरआई संदर्भ प्रदान करता है, जैसा कि <code>a</code> या <code>link</code> की <code>href</code> विशेषता का मान करता है।
</पूर्व>
* [[XML|एक्सएमएल]] में, के बाद प्रदर्शित होने वाला [[सिस्टम पहचानकर्ता]] <code>SYSTEM</code> दस्तावेज़ प्रकार की परिभाषा में कीवर्ड एक खंड रहित यूआरआई संदर्भ होता है।
* [[XSLT|एक्सएसएलटी]] में एक्सएसएल की <code>href</code> विशेषता का मान: <code>xsl:import</code> निर्देश एक यूआरआई संदर्भ होता है इसी प्रकार <code>document()</code> कारक के लिए पहला तर्क होता है।
https://example.com/path/resource.txt#fragment
//example.com/path/resource.txt
/path/resource.txt
path/resource.txt
../resource.txt
./resource.txt
resource.txt
#fragme


इसके लक्ष्य URI के लिए एक सापेक्ष संदर्भ निम्नानुसार हल किया गया है:{{sfnp|RFC 3986|2005|loc=§5.4}}
=== विश्लेषण ===
<पूर्व>
जी: एच -> जी: एच
जी -> http: // ए / बी / सी / जी
./g -> http://a/b/c/g
जी/ -> http://a/b/c/g/
/ जी -> http: // ए / जी
// जी -> http: // जी
?y -> http://a/b/c/d;p?y
जी? वाई -> http://a/b/c/g?y
#s -> http://a/b/c/d;p?q#s
जी#एस -> http://ए/बी/सी/जी#एस
g?y#s -> http://a/b/c/g?y#s
;x -> http://a/b/c/;x
g;x -> http://a/b/c/g;x
g;x?y#s -> http://a/b/c/g;x?y#s
          -> http://a/b/c/d;p?q
. -> http://ए/बी/सी/
./ -> http://a/b/c/
.. -> http: // ए / बी /
../ -> http://a/b/
../g -> http://a/b/g
../.. -> http://a/
../../ -> http://a/
../../g -> http://a/g
</पूर्व>


=== URL मूंगिंग ===
आधार यूआरआई के विरुद्ध यूआरआई संदर्भ को हल करने से लक्ष्य यूआरआई बनता है। इसका तात्पर्य है कि आधार यूआरआई मौजूद है और एक पूर्ण यूआरआई है (एक यूआरआई जिसमें कोई खंड घटक नहीं है)। पूर्वता के क्रम में आधार यूआरआई प्राप्त किया जा सकता है:{{sfnp|RFC 3986|2005|loc=§5.1}}
URL मूंगिंग एक ऐसी तकनीक है जिसके द्वारा URL में कमांड_(कंप्यूटिंग) जोड़ा जाता है, आमतौर पर अंत में, ? लेक्सिकल_विश्लेषण # टोकन। यह आमतौर पर [[WebDAV]] में [[HTTP]] में कार्यक्षमता जोड़ने के तंत्र के रूप में उपयोग किया जाता है। वर्जनिंग सिस्टम में, उदाहरण के लिए, URL में चेकआउट कमांड जोड़ने के लिए, इसे इस रूप में लिखा जाता है <code><nowiki>http://editing.com/resource/file.php?command=checkout</nowiki></code>. इसमें Common_Gateway_Interface दोनों के लिए आसान होने का लाभ है और इस मामले में HTTP और अंतर्निहित संसाधन के बीच मध्यस्थ के रूप में भी कार्य करता है।{{sfn|Whitehead|1998|p=38}}


यूआरआई के विपरीत यूआरआई संदर्भ को हल करने से लक्ष्य यूआरआई बनता है। इसका तात्पर्य है कि यूआरआई सम्मिलित होता है और एक पूर्ण यूआरआई है एक यूआरआई जिसमें कोई खंड घटक नहीं है आधार यूआरआई प्राथमिकता के अनुक्रम में से प्राप्त किया जा सकता है:{{sfnp|RFC 3986|2005|loc=§5.1}}
* संदर्भ यूआरआई ही अगर यह एक यूआरआई है।
* डेटा का प्रतिनिधित्व
* प्रतिनिधित्व को समाहित करने वाली इकाई
* यूआरआई प्रतिनिधित्व की वास्तविक पुनर्प्राप्ति के लिए उपयोग किया जाता है।
* आवेदन का संदर्भ।
प्रतिनिधित्व के भीतर अपेक्षाकृत रूप से परिभाषित आधार के साथ एक सापेक्ष संदर्भ के यूआरआई को इसके लक्ष्य यूआरआई के रूप में निम्नानुसार हल किया गया है:{{sfnp|RFC 3986|2005|loc=§5.4}}
"g:h"  -> http://a/b/c/d;p?q
  "g:h"  -> "g:h"
"g"    -> "http://a/b/c/g
"./g"  -> "http://a/b/c/g/
"g/"  -> "http://a/b/c/d;p?y
"/g"  -> "<nowiki>http://a/g</nowiki>"
"//g"  -> "<nowiki>http://g</nowiki>"
"?y"  -> "http://a/b/c/g?y
"
"g?y"  -> "http://a/b/c/g?y"#s"
    -> "http://a/b/c/d;p?q#s
"g#s"  -> "http://a/b/c/g?y"
"g?y#s"  -> "<nowiki>http://a/b/c/g?y#s</nowiki>"
";x"  -> "<nowiki>http://a/b/c/;x</nowiki>"
"g;x"  -> "<nowiki>http://a/b/c/g;x</nowiki>"
"g;x?y#s" -> "<nowiki>http://a/b/c/g;x?y#s</nowiki>"
""    -> "http://a/b/c/d;p?q
"."    -> "http://a/b/c/
"./"  -> "http://a/b/
".."  -> " http://a/
"../"  -> " http://a/g"
"../g"  -> " http://a/g"
"../.."  -> "<nowiki>http://a/</nowiki>"
"../../" -> "<nowiki>http://a/</nowiki>"
"../../g" -> "<nowiki>http://a/g</nowiki>"


=== यूआरएल मूंगिंग ===
यूआरएल मूंगिंग एक ऐसी तकनीक है जिसके द्वारा एक कमांड को यूआरएल में संबद्ध किया जाता है और सामान्यतः अंत में, "?" के बाद टोकन पर यह सामान्य रूप से [[WebDAV|वेब डीएवी]] में [[HTTP|एचटीटीपी]] में कार्यक्षमता जोड़ने के रूप में उपयोग किया जाता है। वर्जनिंग सिस्टम में, उदाहरण के लिए यूआरएल में "चेकआउट" कमांड जोड़ने के लिए, इसे <code><nowiki>http://editing.com/resource/file.php?command=checkout</nowiki></code> लिखा जाता है। यह सीजीआई के लिए आसान होने और इस स्थिति में एचटीटीपी और अंतर्निहित संसाधनों के बीच एक मध्यस्थ के रूप में कार्य करने का लाभ होता है।{{sfn|Whitehead|1998|p=38}}
=== [[एक्सएमएल नेमस्पेस]] से संबंध ===
=== [[एक्सएमएल नेमस्पेस]] से संबंध ===


एक्सएमएल में, एक एक्सएमएल नेमस्पेस एक अमूर्त डोमेन है जिसमें तत्व और विशेषता नामों का संग्रह असाइन किया जा सकता है।<!-- who or what can do such assignation? --> नेमस्पेस नाम एक वर्ण स्ट्रिंग है जिसे सामान्य यूआरआई सिंटैक्स का पालन करना चाहिए।{{sfnp|Morrison|2006}} हालाँकि, नाम को आमतौर पर URI नहीं माना जाता है,{{sfnp|Harold|2004}} क्योंकि यूआरआई विनिर्देश न केवल शाब्दिक घटकों पर, बल्कि उनके इच्छित उपयोग पर भी निर्णय लेता है। एक नाम स्थान का नाम जरूरी नहीं कि यूआरआई योजनाओं के किसी भी शब्दार्थ को दर्शाता है; उदाहरण के लिए, http: से शुरू होने वाले नाम स्थान का HTTP के उपयोग के लिए कोई अर्थ नहीं हो सकता है।
एक्सएमएल में, "नेमस्पेस" एक सब डोमेन है जिसमें तत्व और विशेषता नामों का संग्रह निर्धारित किया जा सकता है। नेमस्पेस नाम एक वर्ण स्ट्रिंग है जिसे सामान्य यूआरआई सिंटैक्स का अनुसरण करना चाहिए। हालांकि, नाम को सामान्यतः यूआरआई नहीं माना जाता है{{sfnp|Morrison|2006}} क्योंकि यूआरआई विनिर्देश न केवल शब्दावली घटकों पर बल्कि उनके इच्छित उपयोग पर भी निर्णय लेता है।{{sfnp|Harold|2004}} एक नाम एड्रेस का नाम आवश्यक नहीं कि यूआरआई योजनाओं के किसी भी शब्दार्थ को प्रदर्शित करता है उदाहरण के लिए एचटीटीपी से प्रारम्भ होने वाले नाम एड्रेस का एचटीटीपी के उपयोग के लिए कोई अर्थ नहीं हो सकता है।
 
मूल रूप से, नाम स्थान का नाम किसी गैर-रिक्त यूआरआई संदर्भ के सिंटैक्स से मेल खा सकता है, लेकिन संबंधित यूआरआई संदर्भों के उपयोग को डब्ल्यू3सी द्वारा बहिष्कृत कर दिया गया था।{{sfnp|W3C|2009}} XML 1.1 में नामस्थानों के लिए एक अलग W3C विनिर्देश अंतर्राष्ट्रीयकृत संसाधन पहचानकर्ता (IRI) संदर्भों को URI संदर्भों के अतिरिक्त नामस्थान नामों के आधार के रूप में कार्य करने की अनुमति देता है।{{sfnp|W3C|2006}}
 


मूल रूप से, 'नेमस्पेस' किसी गैर-रिक्त यूआरआई संदर्भ के सिंटैक्स के अनुरूप हो सकता है लेकिन संबंधित यूआरआई संदर्भों के उपयोग को डब्ल्यू-3-सी द्वारा अस्वीकृत कर दिया गया था।{{sfnp|W3C|2009}} एक्सएमएल 1.1 में "नेमस्पेस" के लिए एक अलग डब्ल्यू-3-सी विशिष्टता अंतर्राष्ट्रीयकृत संसाधन पहचानकर्ता (आईआरआई) संदर्भों को यूआरआई संदर्भों के अतिरिक्त नेमस्पेस नामों के आधार के रूप में कार्य करने की स्वीकृति होती है।{{sfnp|W3C|2006}}
== यह भी देखें ==
== यह भी देखें ==


* [[क्यूरी]]
* [[क्यूरी|सीयूआरआईई]]
* जुड़ा हुआ डेटा
* संलग्न डेटा
* [[एक्स्टेंसिबल संसाधन पहचानकर्ता]]
* [[एक्स्टेंसिबल संसाधन पहचानकर्ता]]
* [[अंतर्राष्ट्रीय संसाधन पहचानकर्ता]] (IRI)
* [[अंतर्राष्ट्रीय संसाधन पहचानकर्ता]] (आईआरआई)
* [[इंटरनेट संसाधन लोकेटर]]
* [[इंटरनेट संसाधन लोकेटर]]
* लगातार एक समान संसाधन लोकेटर
* सतत यूनिफ़ॉर्म रिसोर्स लोकेटर
* [[वर्दी नामकरण सम्मेलन]]
* [[वर्दी नामकरण सम्मेलन|यूनिफ़ॉर्म नामकरण अधिवेशन]]
* [[संसाधन निर्देशिका विवरण भाषा]]
* [[संसाधन निर्देशिका विवरण भाषा]]
* [[सार्वभौमिक अद्वितीय पहचानकर्ता]]
* [[सार्वभौमिक अद्वितीय पहचानकर्ता]]
Line 257: Line 225:


==बाहरी संबंध==
==बाहरी संबंध==
* [https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml URI Schemes]&nbsp;– [[Internet Assigned Numbers Authority|IANA]]-maintained registry of URI Schemes
* [https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml यूआरआई Schemes]&nbsp;– [[Internet Assigned Numbers Authority|IANA]]-maintained registry of यूआरआई Schemes
* [https://www.w3.org/wiki/UriSchemes URI schemes on the W3C wiki]
* [https://www.w3.org/wiki/UriSchemes यूआरआई schemes on the W3C wiki]
* [https://www.w3.org/TR/webarch/#identification Architecture of the World Wide Web, Volume One, §2: Identification]&nbsp;– by W3C
* [https://www.w3.org/TR/webarch/#identification Architecture of the World Wide Web, Volume One, §2: Identification]&nbsp;– by W3C
* [https://www.w3.org/TR/uri-clarification/ W3C URI Clarification]
* [https://www.w3.org/TR/uri-clarification/ W3C यूआरआई Clarification]
 
{{Semantic Web|state=collapsed}}
{{URI scheme}}
{{Hypermedia}}


{{Authority control}}
{{Authority control}}
{{Use dmy dates|date=May 2020|cs1-dates=y|}}[[Category: अनुप्रयोग परत प्रोटोकॉल]] [[Category: इंटरनेट प्रोटोकॉल]] [[Category: इंटरनेट मानक]] [[Category: सिमेंटिक वेब| सिमेंटिक वेब]] [[Category: यूआरएल]]
{{Use dmy dates|date=May 2020|cs1-dates=y|}}
 
 


[[Category: Machine Translated Page]]
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category:CS1 errors]]
[[Category:Created On 17/02/2023]]
[[Category:Created On 17/02/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Use dmy dates from May 2020]]
[[Category:अनुप्रयोग परत प्रोटोकॉल]]
[[Category:इंटरनेट प्रोटोकॉल]]
[[Category:इंटरनेट मानक]]
[[Category:यूआरएल]]
[[Category:सिमेंटिक वेब| सिमेंटिक वेब]]

Latest revision as of 10:45, 21 February 2023

यूनिफ़ॉर्म रिसोर्स पहचानकर्ता (यूआरआई)
Abbreviationयूआरआई
Domainवर्ल्ड वाइड वेब

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

इतिहास

अवधारणा

यूआरआई और यूआरएल का एक साझा इतिहास है। 1990 में, हाइपरटेक्स्ट के लिए टिक बैरनर्स-ली के प्रस्तावों ने निहित रूप से यूआरएल के विचार को एक संसाधन का प्रतिनिधित्व करने वाली एक छोटी श्रृंखला के रूप में प्रस्तुत किया था जो एक हाइपरलिंक का लक्ष्य है।[1] उस समय लोग इसे "हाइपरटेक्स्ट नाम" या "दस्तावेज़ नाम" कहते थे।[2]

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

जिसमे यूआरएलएस और यूआरएनएस को परिभाषित करने पर वार्तालाप के समय यह स्पष्ट हो गया कि दो शब्दों द्वारा अंतःस्थापित अवधारणाएँ मौलिक, व्यापक, संसाधन पहचान की धारणा के केवल दृष्टिकोण थे। जून 1994 में आईईटीएफ ने टिप्पणियों के लिए बर्नर्स-ली का पहला अनुरोध प्रकाशित किया था जिसमें यूआरएल और यूआरएन के अस्तित्व को स्वीकृत किया गया था। सबसे महत्वपूर्ण अवधारणा यह है कि इसने यूनिवर्सल संसाधन पहचानकर्ता अर्थात यूआरएल जैसी श्रृंखलाए जिनके एल्गोरिथम और शब्दार्थ उनकी योजनाओं पर निर्भर थे जिनके के लिए एक औपचारिक एल्गोरिथम को परिभाषित किया था। इसके अतिरिक्त RFC 1630 ने उस समय उपयोग में आने वाली यूआरएल योजनाओं के एल्गोरिथम को संक्षेप में प्रस्तुत प्रयास किया था। लेकिन आपेक्षिक यूआरएल और खंड पहचानकर्ताओं के अस्तित्व को मानकीकृत नहीं किया था।[5]

संशोधन

RFC 1738 औपचारिक रूप से आपेक्षिक और निरपेक्ष यूआरएल को परिभाषित करता है, सामान्य यूआरएल एल्गोरिथम को अपरिवर्तित करता है जो आपेक्षिक यूआरएल को निरपेक्ष रूप से हल करने के तरीके को परिभाषित करता है और तब उपयोग में आने वाली यूआरएल योजनाओं की अपेक्षाकृत रूप से गणना करता है।[6] मई 1997 में आईईटीएफ आरएफसी 2141 के प्रकाशन तक यूआरएन की परिभाषा स्वीकृति और एल्गोरिथम के लिए प्रतीक्षा करना पड़ी।[7] अगस्त 1998 में आईईटीएफ आरएफसी 2396[8] के प्रकाशन ने प्रदर्शित किया कि यूआरआई एल्गोरिथम एक अलग विनिर्देश बन गया है[9] और यूआरआई और यूआरएल से संबंधित आरएफसी 1630 और 1738 के अधिकांश भागो को आईईटीएफ द्वारा संशोधित और विस्तारित किया गया था। और नए आरएफसी ने "यूआरआई" में "यू" के अर्थ को "यूनिवर्सल" से "यूनिफार्म" में परिवर्तित कर दिया गया था।

दिसंबर 1999 में RFC 2732[10] ने आरएफसी 2396 को एक अपेक्षाकृत नया संस्कारण प्रदान किया था। जिससे यूआरआई को आईपीवी-6 एड्रेसों को समायोजित करने की स्वीकृति प्राप्त हुई और दो विशिष्टताओं में खोजी गई कई कमियों के कारण एक सामुदायिक प्रयास हुआ। जिसका समन्वय आरएफसी 2396 के सह-लेखक रॉय फील्डिंग ने किया था जो जनवरी 2005 में आईईटीएफ आरएफसी 3986[11] के प्रकाशन के साथ समाप्त हो गया था इसने सम्मिलित यूआरएल योजनाओं के विवरण को अप्रचलित नहीं किया और आरएफसी 1738 ऐसी योजनाओं को नियंत्रित करना प्रारम्भ किया गया इसके अतिरिक्त जहां अन्य आईईटीएफ आरएफसी 2616 का अधिक्रमण किया गया।[12] उदाहरण के लिए जो एचटीटीपी योजनाओ को परिशोधित करता है। इसके साथ ही आईईटीएफ ने आरएफसी 3986 के डेटा को पूर्ण मानक एसटीडी 66 के रूप में प्रकाशित किया था जो एक आधिकारिक इंटरनेट प्रोटोकॉल के रूप में यूआरआई एल्गोरिथम की स्थापना को प्रदर्शित करता है।

2001 में,डब्ल्यू-3-सी के तकनीकी संरचनात्मक समूह (टीएजी) ने किसी दिए गए संसाधन के कई संस्करणों को प्रकाशित करने के लिए सर्वोत्तम प्रथाओं और प्रामाणिक यूआरआई के लिए एक निर्देशो को प्रकाशित किया।[13] उदाहरण के लिए, उस डेटा तक अभिगमन के लिए उपयोग किए जाने वाले उपकरण की क्षमता या सेटिंग्स को समायोजित करने के लिए भाषा या आकार के अनुसार भिन्न हो सकती है। अगस्त 2002 में, आईईटीएफ RFC 3305[14] ने बताया कि व्यापक रूप से सार्वजनिक उपयोग के अतिरिक्त "यूआरएल" शब्द लगभग अप्रचलन में अपेक्षाकृत रूप से कम पड़ गया था और केवल एक पूर्ण रूप में कार्य करता है कि कुछ यूआरआई नेटवर्क उपलब्धता को प्रयुक्त करने वाली योजनाओं के माध्यम से एड्रेस के रूप में कार्य करते हैं, यद्यपि ऐसे ही किसी वास्तविक उपयोग के लिए जैसा कि यूआरआई-आधारित मानक जैसे संसाधन विवरण रूपरेखा स्पष्ट करते हैं संसाधन पहचान को इंटरनेट पर संसाधन प्रतिनिधित्व की पुनर्प्राप्ति का सुझाव देने की आवश्यकता नहीं होती है,और न ही उन्हें नेटवर्क-आधारित संसाधनों की आवश्यकता होती है।

सेमांटिक वेब वास्तविक समाज में दस्तावेज़ों और अवधारणाओं दोनों की पहचान करने के लिए एचटीटीपी यूआरआई योजना का उपयोग करता है एक ऐसी विशिष्टता जिसके कारण भ्रम उत्पन्न हो गया है कि दोनों को कैसे अलग किया जाए। टीएजी ने 2005 में इस समस्या को हल करने के तरीके पर एक ई-मेल प्रकाशित किया था जिसे एचटीटीपी श्रेणी-14 विश्लेषण के रूप में जाना जाता है।[15] डब्ल्यू-3-सी ने बाद में सिमेंटिक वेब के लिए कुल यूआरआईएस शीर्षक से एक स्थित समूह टिप्पणी प्रकाशित किया था जिसमें डेटा के उपयोग और पुनर्निर्देशन के लिए एचटीटीपी 303 प्रतिक्रिया कोड को और अधिक विस्तृत रूप से समझाया गया है।[16]

डिजाइन

यूआरएल और यूआरएन

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

यूनिफ़ॉर्म रिसोर्स लोकेटर (यूआरएल) एक यूआरआई है जो किसी संसाधन पर कार्य करने या उसका प्रतिनिधित्व प्राप्त करने के साधन को निर्दिष्ट करता है अर्थात इसकी प्राथमिक अभिगमन तंत्र और नेटवर्क एड्रेस दोनों को निर्दिष्ट करता है। उदाहरण के लिए, यूआरएल http://example.org/wiki/Main_Page के रूप में पहचाने जाने वाले संसाधन को संदर्भित करता है /wiki/Main_Page, जिसका प्रतिनिधित्व हाइपरटेक्स्ट ट्रान्सफर प्रोटोकॉल http: के माध्यम से उस नेटवर्क होस्ट से प्राप्त किया जा सकता है जिसका डोमेन नाम example.org है। इस स्थिति में, एचटीटीपी मे सामान्यतः इसका अर्थ एचटीएमएल और संबंधित कोड के रूप में होता है। प्रयोगात्मक रूप से यह आवश्यक नहीं होता है, क्योंकि एचटीटीपी अपने हेडर मेंअपेक्षाकृत प्रारूपों को निर्दिष्ट करने की स्वीकृति देता है। यूआरएन किसी व्यक्ति के नाम के अनुरूप होता है जबकि यूआरएल उनके भौतिक एड्रेस के अनुरूप होता है। दूसरे शब्दों में, एक यूआरएन एक वस्तु की पहचान करता है और एक यूआरएल इसे खोजने के लिए एक तरीका प्रदान करता है।

तकनीकी प्रकाशन विशेष रूप से आईईटीएफ और वर्ल्ड वाइड वेब द्वारा निर्मित मानक सामान्यतः 30 जुलाई 2001 की वर्ल्ड वाइड विशेषताओ में उल्लिखित एक दृश्य को प्रदर्शित करते हैं जो यूआरएल में किसी औपचारिक उपखंड का समर्थन करने के अतिरिक्त यूआरआई और यूआरएन शब्द की प्राथमिकता को स्वीकृत करता है।

यूआरएल एक उपयोगी यूआरएल होता है लेकिन इसमे एक अनौपचारिक अवधारणा यह है कि एक यूआरएल एक प्रकार का यूआरआई है जो किसी संसाधन की पहचान उसकी कुछ अन्य विशेषताओं के अतिरिक्त उसके प्राथमिक नियंत्रण क्रियाविधि (जैसे, उसके नेटवर्क "एड्रेस") के प्रतिनिधित्व के माध्यम से करता है।[17]

इस प्रकार, एक यूआरएल केवल एक यूआरआई है जो एक नेटवर्क पर एक संसाधन को इंगित करने के लिए होता है।[lower-alpha 1][18] हालांकि, गैर-तकनीकी संदर्भों में और वर्ल्ड वाइड वेब के लिए सॉफ्टवेयर में "यूआरएल" शब्द का व्यापक रूप से उपयोग किया जाता है। इसके अतिरिक्त शब्द "वेब एड्रेस" (जिसकी कोई औपचारिक परिभाषा नहीं होती है) प्रायः गैर-तकनीकी प्रकाशनों में यूआरआई के समानार्थी शब्द के रूप में उपयोग किया जाता है जो एचटीटीपी या एचटीटीपीएस योजनाओं का उपयोग करती है। इस प्रकार की धारणाएं कई समस्याए उत्पन्न कर सकती हैं उदाहरण के लिए एक्सएमएल नाम एड्रेस की स्थिति में निर्धारित यूआरआई के लिए डेटा समान होता है।

व्हाटवग द्वारा निर्मित विनिर्देश यूआरआई पर यूआरएल अधिकृत किया जाता है और इसलिए नए एचटीएमएल 5 एपीआई यूआरआई पर यूआरएल का उपयोग करते हैं।[19]

यूआरएल शब्द पर मानकीकरण यूआरआई और आईआरआई अंतर्राष्ट्रीयकृत संसाधन पहचानकर्ता अस्पष्ट हैं। प्रयोगात्मक रूप से दोनों के लिए एक ही एल्गोरिदम का उपयोग किया जाता है इसलिए उन्हें अलग करने से किसी की सहायता नहीं होती है। इसलिए यूआरएल खोज परिणाम को आसानी से प्राप्त कर सकता है।[20]

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

एल्गोरिथम

यूआरआई में एक योजना है जो उस योजना के भीतर पहचानकर्ता निर्दिष्ट करने के लिए एक विनिर्देश को संदर्भित करती है। इस प्रकार, यूआरआई एल्गोरिथम एक संघीय और विस्तरणीय (एक्स्टेंसिबल) नामकरण प्रणाली है जिसमें प्रत्येक योजना के विनिर्देश उस योजना का उपयोग करने वाले पहचानकर्ताओं के एल्गोरिथम और सिमेंटिक्स को प्रतिबंधित कर सकते हैं। यूआरआई वर्गीय एल्गोरिथम सभी यूआरआई योजनाओं के एल्गोरिथम का एक उच्च समूह है। इसे पहली बार आरएफसी 2396 में परिभाषित किया गया था जिसे अगस्त 1998 में प्रकाशित किया गया था[9] और जनवरी 2005 में प्रकाशित आरएफसी 3986 में इसे अंतिम रूप दिया गया था।[21]

यूआरआई एएससीआईआई वर्णों के निर्धारित सेट से बना होता है जिसमें आरक्षित वर्ण होते हैं जिनमे सामान्य :, /, ?, #, [, ] और @ योजना या कार्यान्वयन-विशिष्ट !, $, &, ', (, ), *, +, ,, ;, और =),[22] अनारक्षित वर्ण (लैटिन-लिपि वर्णमाला, अरबी अंक, -, ., _, ~),[23] और %. आदि आरक्षित वर्ण सम्मिलित है।[24] एल्गोरिथम घटकों और उप-घटकों को आरक्षित वर्णों मे (केवल घटकों के लिए सामान्य आरक्षित वर्णों से) से सीमांकक द्वारा अलग किया जाता है और पहचान डेटा को अनारक्षित वर्णों या आरक्षित वर्णों के रूप में परिभाषित किया जाता है जो क्रमशः घटक और उप-घटक में सीमांकक के रूप में कार्य नहीं करते हैं[25] और प्रतिशत-एन्कोडिंग जब संबंधित वर्ण निर्धारित समूह के बाहर या घटक के भीतर या एक सीमांकक के रूप में उपयोग किया जा जाता है। एक पहचान डेटा ऑक्टेट (कंप्यूटिंग) का प्रतिशत-एन्कोडिंग वर्णों से मिलकर तीन वर्णों का अनुक्रम होता है उसके बाद दो हेक्साडेसिमल अंक उस ऑक्टेट के सांख्यिक मान का प्रतिनिधित्व करते हैं।[24]

यूआरआई एल्गोरिथम में पाँच घटक होते हैं जो बाएँ से दाएँ घटते महत्व के अनुक्रम में क्रमबद्ध रूप से व्यवस्थित होते हैं:[26]

RI = scheme ":" ["//" authority] path ["?" query] ["#" fragment]

एक घटक अपरिभाषित होता है यदि उसके पास एक संबद्ध सीमांकक होता है और सीमांकक यूआरआई में प्रकट नहीं होता है; योजना और एड्रेस घटक सदैव परिभाषित होते हैं।[27] कोई घटक तब रिक्त होता है जब उसमें कोई वर्ण नहीं होता है योजना घटक सदैव रिक्त नहीं होता है।[26] क्योकि प्राधिकरण घटक में सदैव उप-घटक होते हैं:

authority = [userinfo "@"] host [":" port]

यह एल्गोरिथम आरेख में इस प्रकार प्रदर्शित किया गया है:

यूआरआई सिंटैक्स आरेखयूआरआई में निम्न अनुक्रम सम्मिलित होते हैं:

  • एक गैर-रिक्त योजना घटक जिसके बाद एक कोलन (:) होता है जिसमें एक अक्षर से शुरू होने वाले वर्णों का अनुक्रम होता है और अक्षरों, अंकों, प्लस (+), समय (.) या हाइफ़न (-) के किसी भी संयोजन के बाद होता है। हालांकि योजनाएँ केस-असंवेदनशील होती हैं, निहित रूप से लोअरकेस और योजनाओं को निर्दिष्ट करने वाले दस्तावेज़ों को लोअरकेस अक्षरों के साथ ऐसा करना चाहिए। लोकप्रिय योजनाओं के उदाहरणों में http, https, ftp, mailto, file, data और irc सम्मिलित हैं। यूआरआई योजनाओं को इंटरनेट निरुपित संख्या प्राधिकरण (आईएएनए) के साथ पंजीकृत होना चाहिए, हालांकि गैर-पंजीकृत योजनाओं का प्रयोगात्मक रूप से उपयोग किया जाता है।[lower-alpha 2]
  • दो स्लैश (//) से पहले से ही एक वैकल्पिक प्राधिकरण घटक मे सम्मिलित होते हैं:
    • एक वैकल्पिक userinfoउप-घटक जिसके बाद एक प्रतीक @ होता है, जिसमें एक उपयोगकर्ता (कंप्यूटिंग) नाम और एक कोलन (:) से पहले एक वैकल्पिक पासवर्ड सम्मिलित हो सकता है।
    • जिसके पहले कोलन (:). प्रारूप का उपयोग username:password userinfo उप-घटक में सुरक्षा कारणों से हटा दिया गया है। ऐप्लिकेशन को पहले कोलन (:) एकuserinfo उपघटक के भीतर पाया जाता है जब तक कि कोलन के बाद का डेटा रिक्त स्ट्रिंग के रूप मे कोई पासवर्ड नहीं दर्शाता है।
    • एक होस्ट उप-घटक, जिसमें एक पंजीकृत नाम (होस्ट नाम सहित लेकिन सीमित नहीं होता है) या एक आईपी एड्रेस सम्मिलित होता है। आईपीवी 4 एड्रेस डॉट-दशमलव संकेतन में होने चाहिए और आईपीवी-6 एड्रेस कोष्ठक ([]) में संलग्न होने चाहिए।[29][lower-alpha 3]
    • दशमलव अंकों से मिलकर एक कोलन (:) से पहले एक वैकल्पिक पोर्ट उपघटक होता है।
  • एक एड्रेस घटक जिसमें स्लैश (/) द्वारा अलग किए गए एड्रेस खंडों का अनुक्रम सम्मिलित होता है। और यूआरआई के लिए एक एड्रेस सदैव परिभाषित किया जाता है, हालांकि परिभाषित एड्रेस रिक्त (शून्य लंबाई) हो सकता है। एक खंड रिक्त भी हो सकता है जिसके परिणामस्वरूप एड्रेस घटक में निरंतर दो स्लैश (//) हो सकते हैं। एक एड्रेस घटक एक फाइल सिस्टम एड्रेस के समान या मानचित्रित हो सकता है लेकिन सदैव किसी एक से संबंध नहीं दर्शाता है। यदि एक प्राधिकरण घटक परिभाषित किया गया है तो एड्रेस घटक या तो रिक्त होना चाहिए या स्लैश (/) से प्रारम्भ होना चाहिए। यदि एक प्राधिकरण घटक अपरिभाषित है तो एड्रेस एक रिक्त खंड के साथ प्रारम्भ नहीं हो सकता है अर्थात, दो स्लैश (//) के साथ क्योंकि निम्नलिखित वर्णों को प्राधिकरण घटक के रूप में समझा जा सकता है।[31]
परिपाटी के अनुसार, एचटीटीपी और एचटीटीपीएस यूआरआई में एड्रेस के अंतिम भाग का नाम होता हैpathinfoऔर यह वैकल्पिक है। यह शून्य या अधिक एड्रेस खंडों से बना है जो एक मौजूदा भौतिक संसाधन नाम (जैसे एक फ़ाइल, एक आंतरिक मॉड्यूल प्रोग्राम या एक निष्पादन योग्य प्रोग्राम) को संदर्भित नहीं करता है, लेकिन एक तार्किक भाग (जैसे एक कमांड या क्वालीफायर भाग) के लिए होता है एड्रेस के पहले भाग के लिए अलग से पारित किया जाना चाहिए जो एक निष्पादन योग्य मॉड्यूल या वेब सर्वर द्वारा प्रबंधित प्रोग्राम की पहचान करता है; इसका उपयोग प्रायः गतिशील सामग्री (दस्तावेज़ इत्यादि) का चयन करने या अनुरोध के अनुसार इसे अनुकूलित करने के लिए किया जाता है (यह भी देखें: कॉमन गेटवे इंटरफ़ेस और PATH_INFO, आदि)।
अधिवेशन के अनुसार, एचटीटीपी और एचटीटीपीएस यूआरआई में एड्रेस के अंतिम भाग को 'एड्रेसइन्फो' नाम दिया गया है और यह वैकल्पिक है। यह शून्य या अधिक एड्रेस खंडों से बना होता है जो एक सम्मिलित भौतिक संसाधन नाम (जैसे फ़ाइल, आंतरिक मॉड्यूल प्रोग्राम या एक निष्पादन योग्य प्रोग्राम) को संदर्भित नहीं करता है लेकिन एक तार्किक भाग (जैसे एक कमांड या क्वालीफायर भाग) के लिए होता है एड्रेस के पहले भाग के लिए अलग से इसे निर्धारित किया जाता है जो एक निष्पादन योग्य मॉड्यूल या वेब सर्वर द्वारा प्रबंधित प्रोग्राम की पहचान करता है इसका उपयोग प्रायः गतिशील डेटा (दस्तावेज़, आदि) का चयन करने या अनुरोध के अनुसार इसे अनुकूलित करने के लिए किया जाता है।
उदाहरण: यूआरआई: "http://www.example.com/questions/3456/my-document"
जहाँ : "/questions" एड्रेस का पहला भाग है जो एक निष्पादन योग्य मॉड्यूल या प्रोग्राम और "/3456/my-document" नामक एड्रेस का दूसरा भाग है जिसे निष्पादन योग्य मॉड्यूल या प्रोग्राम नाम दिया गया है "/questions" अनुरोधित दस्तावेज़ का चयन करने के लिए एक एचटीटीपी और एचटीटीपीएस यूआरआई जिसमें क्वेरी भाग के अतिरिक्त एड्रेसिनफो भाग होता है उसे 'क्लीन यूआरएल' के रूप में संदर्भित किया जा सकता है जिसका अंतिम भाग 'स्लग' हो सकता है।
क्वेरी सीमांकक उदाहरण
एम्पसेंड (&) key1=value1&key2=value2
सेमीकोलन (;)[lower-alpha 4] key1=value1;key2=value2
  • प्रश्न चिह्न (?) से पहले एक वैकल्पिक क्वेरी घटक, जिसमें गैर-श्रेणीबद्ध डेटा की क्वेरी स्ट्रिंग सम्मिलित होता है। इसका सिंटैक्स अपेक्षाकृत रूप से परिभाषित नहीं होता है लेकिन अधिवेशन के अनुसार यह प्रायः विशेष मान श्रंखला का एक अनुक्रम होता है जो एक सीमांकक द्वारा अलग किया जाता है।
  • एक हैश (#) से पहले एक वैकल्पिक घटक भाग में एक एड्रेस पहचानकर्ता होता है जो द्वितीयक संसाधन को दिशा प्रदान करता है जैसे कि किसी लेख में अनुभाग शीर्षक, जिसे शेष यूआरआई द्वारा पहचाना जाता है। जब प्राथमिक संसाधन एक एचटीएमएल दस्तावेज़ होता है, तो खंड प्रायः एक विशिष्ट तत्व की एक आईडी विशेषता होती है और वेब ब्राउज़र इस तत्व को देखने के लिए स्क्रॉल करते है।

योजना या कार्यान्वयन-विशिष्ट आरक्षित वर्ण + का उपयोग योजना, उपयोगकर्ता जानकारी, होस्ट, एड्रेस, क्वेरी और खंड और योजना या कार्यान्वयन-विशिष्ट आरक्षित वर्णों में किया जा सकता है या विशिष्ट आरक्षित वर्णों !, $, &, ', (, ), *, ,, ;, और = का उपयोग उपयोगकर्ता इन्फो, होस्ट, एड्रेस, क्वेरी और फ्रैगमेंट में किया जा सकता है। इसके अतिरिक्त, सामान्य आरक्षित वर्ण : का उपयोग उपयोगकर्ताइन्फो, पथ, क्वेरी और खंड में किया जा सकता है, सामान्य आरक्षित वर्ण @ और /का उपयोग एड्रेस, क्वेरी और खंड में किया जा सकता है और सामान्य आरक्षित वर्ण ? क्वेरी और खंड के रूप मे उपयोग किया जा सकता है।[33]

उदाहरण यूआरआई

निम्नलिखित डेटा उदाहरण यूआरआई और उनके घटक भागों को प्रदर्शित करता है।

userinfo       host      port
          ┌──┴───┐ ┌──────┴──────┐ ┌┴┐
  https://john.doe@www.example.com:123/forum/questions/?tag=networking&order=newest#top
  └─┬─┘   └───────────┬──────────┘    └───────┬───────┘ └────────────┬────────────┘ └┬┘
  scheme          authority                  path                  query           fragment

  ldap://[2001:db8::7]/c=GB?objectClass?one
  └┬─┘   └─────┬─────┘└─┬─┘ └──────┬──────┘
  scheme   authority   path      query

  mailto:John.Doe@example.com
  └─┬──┘ └────┬─────────────┘
  scheme     path

  news:comp.infosystems.www.servers.unix
  └┬─┘ └─────────────┬─────────────────┘
  scheme            path

  tel:+1-816-555-1212
  └┬┘ └──────┬──────┘
  scheme    path

  telnet://192.0.2.16:80/
  └─┬──┘   └─────┬─────┘│
  scheme     authority  path

  urn:oasis:names:specification:docbook:dtd:xml:4.1.2
  └┬┘ └──────────────────────┬──────────────────────┘
  scheme                    path

डीओआई (डिजिटल ऑब्जेक्ट पहचानकर्ता) नियंत्रण सिस्टम के भीतर प्रयुक्त होते हैं और यूआरआई सिस्टम के भीतर फिट होते हैं, जैसा कि उपयुक्त एल्गोरिथम द्वारा सुविधा प्रदान की जाती है।

यूआरआई संदर्भ

यूआरआई संदर्भ या तो एक यूआरआई या एक सापेक्ष संदर्भ होता है, जब यह एक योजना घटक के बाद एक कोलन : के साथ प्रारम्भ नहीं होता है।[34] तब एक एड्रेस खंड जिसमें एक कोलन वर्ण होता है (उदाहरण के लिए, foo:bar) को सापेक्ष संदर्भ के पहले एड्रेस खंड के रूप में उपयोग नहीं किया जा सकता है यदि इसका एड्रेस घटक स्लैश (/) से प्रारम्भ नहीं होता है क्योंकि यह एक योजना घटक के लिए गलत होता है इस प्रकार के एड्रेस सेगमेंट ./foo:bar के पहले एक डॉट एड्रेस सेगमेंट होता है। [35]

वेब दस्तावेज़ मार्कअप भाषाएँ अन्य संसाधनों, जैसे बाहरी दस्तावेज़ों या समान तार्किक दस्तावेज़ के विशिष्ट भागों को इंगित करने के लिए प्रायः यूआरआई संदर्भों का उपयोग करती हैं:[36]

  • एचटीएमएल में, img तत्व की src विशेषता का मान एक यूआरआई संदर्भ प्रदान करता है, जैसा कि a या link की href विशेषता का मान करता है।
  • एक्सएमएल में, के बाद प्रदर्शित होने वाला सिस्टम पहचानकर्ता SYSTEM दस्तावेज़ प्रकार की परिभाषा में कीवर्ड एक खंड रहित यूआरआई संदर्भ होता है।
  • एक्सएसएलटी में एक्सएसएल की href विशेषता का मान: xsl:import निर्देश एक यूआरआई संदर्भ होता है इसी प्रकार document() कारक के लिए पहला तर्क होता है।
https://example.com/path/resource.txt#fragment
//example.com/path/resource.txt
/path/resource.txt
path/resource.txt
../resource.txt
./resource.txt
resource.txt
#fragme

विश्लेषण

आधार यूआरआई के विरुद्ध यूआरआई संदर्भ को हल करने से लक्ष्य यूआरआई बनता है। इसका तात्पर्य है कि आधार यूआरआई मौजूद है और एक पूर्ण यूआरआई है (एक यूआरआई जिसमें कोई खंड घटक नहीं है)। पूर्वता के क्रम में आधार यूआरआई प्राप्त किया जा सकता है:[37]

यूआरआई के विपरीत यूआरआई संदर्भ को हल करने से लक्ष्य यूआरआई बनता है। इसका तात्पर्य है कि यूआरआई सम्मिलित होता है और एक पूर्ण यूआरआई है एक यूआरआई जिसमें कोई खंड घटक नहीं है आधार यूआरआई प्राथमिकता के अनुक्रम में से प्राप्त किया जा सकता है:[37]

  • संदर्भ यूआरआई ही अगर यह एक यूआरआई है।
  • डेटा का प्रतिनिधित्व
  • प्रतिनिधित्व को समाहित करने वाली इकाई
  • यूआरआई प्रतिनिधित्व की वास्तविक पुनर्प्राप्ति के लिए उपयोग किया जाता है।
  • आवेदन का संदर्भ।

प्रतिनिधित्व के भीतर अपेक्षाकृत रूप से परिभाषित आधार के साथ एक सापेक्ष संदर्भ के यूआरआई को इसके लक्ष्य यूआरआई के रूप में निम्नानुसार हल किया गया है:[38]

"g:h"   -> http://a/b/c/d;p?q
 "g:h"   -> "g:h"
"g"    -> "http://a/b/c/g
"./g"   -> "http://a/b/c/g/
"g/"   -> "http://a/b/c/d;p?y
"/g"   -> "http://a/g"
"//g"   -> "http://g"
"?y"   -> "http://a/b/c/g?y
"
"g?y"   -> "http://a/b/c/g?y"#s"
   -> "http://a/b/c/d;p?q#s
"g#s"   -> "http://a/b/c/g?y"
"g?y#s"  -> "http://a/b/c/g?y#s"
";x"   -> "http://a/b/c/;x"
"g;x"   -> "http://a/b/c/g;x"
"g;x?y#s" -> "http://a/b/c/g;x?y#s"
""    -> "http://a/b/c/d;p?q
"."    -> "http://a/b/c/
"./"   -> "http://a/b/
".."   -> " http://a/
"../"   -> " http://a/g"
"../g"  -> " http://a/g"
"../.."  -> "http://a/"
"../../" -> "http://a/"
"../../g" -> "http://a/g"

यूआरएल मूंगिंग

यूआरएल मूंगिंग एक ऐसी तकनीक है जिसके द्वारा एक कमांड को यूआरएल में संबद्ध किया जाता है और सामान्यतः अंत में, "?" के बाद टोकन पर यह सामान्य रूप से वेब डीएवी में एचटीटीपी में कार्यक्षमता जोड़ने के रूप में उपयोग किया जाता है। वर्जनिंग सिस्टम में, उदाहरण के लिए यूआरएल में "चेकआउट" कमांड जोड़ने के लिए, इसे http://editing.com/resource/file.php?command=checkout लिखा जाता है। यह सीजीआई के लिए आसान होने और इस स्थिति में एचटीटीपी और अंतर्निहित संसाधनों के बीच एक मध्यस्थ के रूप में कार्य करने का लाभ होता है।[39]

एक्सएमएल नेमस्पेस से संबंध

एक्सएमएल में, "नेमस्पेस" एक सब डोमेन है जिसमें तत्व और विशेषता नामों का संग्रह निर्धारित किया जा सकता है। नेमस्पेस नाम एक वर्ण स्ट्रिंग है जिसे सामान्य यूआरआई सिंटैक्स का अनुसरण करना चाहिए। हालांकि, नाम को सामान्यतः यूआरआई नहीं माना जाता है[40] क्योंकि यूआरआई विनिर्देश न केवल शब्दावली घटकों पर बल्कि उनके इच्छित उपयोग पर भी निर्णय लेता है।[41] एक नाम एड्रेस का नाम आवश्यक नहीं कि यूआरआई योजनाओं के किसी भी शब्दार्थ को प्रदर्शित करता है उदाहरण के लिए एचटीटीपी से प्रारम्भ होने वाले नाम एड्रेस का एचटीटीपी के उपयोग के लिए कोई अर्थ नहीं हो सकता है।

मूल रूप से, 'नेमस्पेस' किसी गैर-रिक्त यूआरआई संदर्भ के सिंटैक्स के अनुरूप हो सकता है लेकिन संबंधित यूआरआई संदर्भों के उपयोग को डब्ल्यू-3-सी द्वारा अस्वीकृत कर दिया गया था।[42] एक्सएमएल 1.1 में "नेमस्पेस" के लिए एक अलग डब्ल्यू-3-सी विशिष्टता अंतर्राष्ट्रीयकृत संसाधन पहचानकर्ता (आईआरआई) संदर्भों को यूआरआई संदर्भों के अतिरिक्त नेमस्पेस नामों के आधार के रूप में कार्य करने की स्वीकृति होती है।[43]

यह भी देखें

टिप्पणियाँ

  1. A report published in 2002 by a joint W3C/IETF working group aimed to normalize the divergent views held within the IETF and W3C over the relationship between the various 'UR*' terms and standards. While not published as a full standard by either organization, it has become the basis for the above common understanding and has informed many standards since then.
  2. The procedures for registering new URI schemes were originally defined in 1999 by RFC 2717, and are now defined by RFC 7595, published in June 2015.[28]
  3. For URIs relating to resources on the World Wide Web, some web browsers allow .0 portions of dot-decimal notation to be dropped or raw integer IP addresses to be used.[30]
  4. Historic RFC 1866 (obsoleted by RFC 2854) encourages CGI authors to support ';' in addition to '&'.[32]


संदर्भ

  1. Palmer, Sean. "The Early History of HTML". infomesh.net. Retrieved 2020-12-06.
  2. "W3 Naming Schemes". www.w3.org. 1992. Retrieved 2020-12-06.
  3. "Proceedings of the Twenty-Fourth Internet Engineering Task Force" (PDF). p. 193. Retrieved 2021-07-27.
  4. "Proceedings of the Twenty-Fifth Internet Engineering Task Force" (PDF). p. 501. Retrieved 2021-07-27.
  5. Berners-Lee, Tim (June 1994). "Universal Resource Identifiers in WWW". Network Working Group. doi:10.17487/RFC1630. Retrieved 2020-12-06. {{cite journal}}: Cite journal requires |journal= (help)
  6. Berners-Lee, Tim (December 1994). "Request for Comments: 1738: Uniform Resource Locators (URL)". tools.ietf.org/html. doi:10.17487/RFC1738. Retrieved 2020-12-06.
  7. Moats, R. (May 1997). "Request for Comments: 2141: URN Syntax". tools.ietf.org. doi:10.17487/RFC2141. Retrieved 2020-12-06.
  8. Berners-Lee, Tim (August 1998). "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax". tools.ietf.org. doi:10.17487/RFC2396. Retrieved 2020-12-06.
  9. 9.0 9.1 RFC 2396 (1998).
  10. Hinden, R. (December 1999). "RFC 2732:Format for Literal IPv6 Addresses in URL's". tools.ietf.org. doi:10.17487/RFC2732. Retrieved 2020-12-06.
  11. Berners-Lee, Tim (January 2005). "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax". tools.ietf.org. doi:10.17487/RFC3986. Retrieved 2020-12-06.
  12. Fielding, R. (June 1999). "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1". tools.ietf.org. doi:10.17487/RFC2616. Retrieved 2020-12-06.
  13. Raman, T.V. (2006-11-01). "On Linking Alternative Representations To Enable Discovery And Publishing". www.w3.org. Retrieved 2020-12-06.
  14. Mealling, M. (August 2002). Mealling, M; Denenberg, R (eds.). "RFC 3305: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names". tools.ietf.org. doi:10.17487/RFC3305. Retrieved 2020-12-06.
  15. Fielding, Roy (2005-06-18). "[httpRange-14] Resolved". lists.w3.org. Retrieved 2020-12-06.
  16. Sauermann, Leo (December 2008). "Cool URIs for the Semantic Web". www.w3.org. Retrieved 2020-12-06.
  17. URI Planning Interest Group, W3C/IETF (September 2001). "URIs, URLs, and URNs: Clarifications and Recommendations 1.0". www.w3.org. W3C/IETF. Retrieved 2020-12-08.
  18. Joint W3C/IETF URI Planning Interest Group (2002).
  19. "URL Standard: 6.3. URL APIs elsewhere".
  20. "URL Standard: Goals".
  21. RFC 3986 (2005).
  22. RFC 3986 (2005), §2.2.
  23. RFC 3986 (2005), §2.3.
  24. 24.0 24.1 RFC 3986 (2005), §2.1.
  25. RFC 3986 (2005), §2.
  26. 26.0 26.1 RFC 3986 (2005), §3.
  27. RFC 3986 (2005), §5.2.1.
  28. IETF (2015).
  29. RFC 3986 (2005), §3.2.2.
  30. Lawrence (2014).
  31. RFC 2396 (1998), §3.3.
  32. RFC 1866 (1995), §8.2.1.
  33. RFC 3986 (2005), §A.
  34. RFC 3986 (2005), §4.1.
  35. RFC 3986 (2005), §4.2.
  36. RFC 3986 (2005), §4.4.
  37. 37.0 37.1 RFC 3986 (2005), §5.1.
  38. RFC 3986 (2005), §5.4.
  39. Whitehead 1998, p. 38.
  40. Morrison (2006).
  41. Harold (2004).
  42. W3C (2009).
  43. W3C (2006).


अग्रिम पठन


बाहरी संबंध