معرف الموارد الموحد

(تم التحويل من Uniform resource locator)
"URI" redirects here. For other uses, see URI (توضيح).
Uniform Resource Identifier (URI)
النطاقWorld Wide Web
الاختصارURI

معرّف الموارد الموحد Uniform Resource Identifier (URI ) هو سلسلة فريدة من الأحرف التي تحدد مورداً منطقياً أو مادياً تستخدمه تقنيات الوب. يمكن استخدام URIs لتحديد أي شيء، بما في ذلك كائنات العالم الحقيقي، مثل الأشخاص والأماكن أو المفاهيم أو موارد المعلومات مثل صفحات الوب والكتب. توفر بعض URIs وسيلة لتحديد موقع موارد المعلومات واستردادها على شبكة (إما على الإنترنت أو على شبكة خاصة أخرى، مثل نظام ملفات الحاسب أو الإنترانت)، وهذه هي محددات الموارد الموحد (عناوين URL). توفر URIs الأخرى اسماً فريداً فقط، بدون وسيلة لتحديد أو استرداد المورد أو المعلومات المتعلقة به، فهذه هي اسماء الموارد الموحدة (URN). لا تقتصر تقنيات الوب التي تستخدم URI على متصفحات الوب. تُستخدم URIs لتحديد أي شيء موصوف باستخدام إطار وصف الموارد (RDF)، على سبيل المثال، المفاهيم التي تشكل جزءاً من الأنطولوجية المحددة باستخدام لغة أنطولوجية الوب (OWL)، والأشخاص الذين تم وصفهم باستخدام مفردات صديق لصديق سيكون لكل منهم معرف URI فردي.

على الرغم من أن URI لا يزال مصطلحاً شائع الاستخدام، فقد تم استبدال المواصفات التي تحدد URIs بتلك الخاصة بـ معرف الموارد الدولي (IRI)، والتي توسع تعريف URI بحيث يمكن لـ IRI التعامل مع مجموعات الأحرف مثل كان‌جي بدلاً من التقيد بـ آسكي.[1] [2]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

تاريخ

تصور

URIs وعناوين URL لها محفوظات مشتركة. في عام 1990، قدمت مقترحات تيم برنرز-لي لـ نص فائق ضمنياً فكرة عنوان URL كسلسلة قصيرة تمثل مورداً هدفاً لـ ارتباط فائق.[3] في ذلك الوقت، أشار إليه الأشخاص باسم "اسم النص التشعبي"[4] أو "اسم المستند".

على مدى السنوات الثلاث والنصف التالية، مع تطور التقنيات الأساسية لشبكة الوب العالمية مثل HTML و HTTP ومتصفحات الوب، ظهرت الحاجة إلى التمييز بين سلسلة توفر عنواناً لمورد من سلسلة تسمى مورداً فقط. على الرغم من أنه لم يتم تعريفه رسمياً بعد، فقد جاء مصطلح محدد موقع الموارد الموحد ليمثل الأول، وأصبح اسم المورد الموحد الأكثر إثارة للجدل يمثل الأخير.

أثناء النقاش حول تحديد عناوين URL و URNs، أصبح من الواضح أن المفاهيم التي يجسدها المصطلحان كانت مجرد جوانب من المفهوم الأساسي والشامل لمفهوم تحديد الموارد. في يونيو 1994، نشر IETF أول طلب للتعليقات لـ برنرز لي أقر بوجود عناوين URL و URNs. والأهم من ذلك، أنها حددت بناء جملة رسمي لـ معرفات الموارد العالمية (أي سلاسل تشبه عنوان URL تعتمد تركيبها الدقيق ودلالاتها على مخططاتها). بالإضافة إلى ذلك، حاول RFC (RFC 1630) تلخيص تركيبات أنظمة URL المستخدمة في ذلك الوقت. أقرت - "لكنها لم تضع معايير" - بوجود عناوين URL النسبية ومعرفات الأجزاء.[5]

التنقيح

في ديسمبر 1994، حدد IETF RFC 1738 عناوين URL النسبية والمطلقة رسمياً، وصقل بناء جملة URL العام، وحدد كيفية حل عناوين URL النسبية إلى الشكل المطلق، وحدد بشكل أفضل مخططات عناوين URL التي كانت قيد الاستخدام.[6] كان على تعريف وبناء جملة URN المتفق عليهما الانتظار حتى نشر IETF RFC[7] في مايو 1997.

شهد نشر IETF RFC 2396[8]في أغسطس 1998، أصبح بناء جملة URI مواصفة منفصلة [9] وتمت مراجعة وتوسيع معظم أجزاء RFCs 1630 و 1738 المتعلقة بـ URIs وعناوين URL بشكل عام بواسطة IETF. قام RFC الجديد بتغيير معنى "U" في "URI" إلى "موحد" من "شامل".

في ديسمبر 1999، قدمت IETF RFC 2732[10]تحديثاً بسيطاً لـ RFC 2396، مما يسمح لعناوين URI باستيعاب عناوين IPv6. أدى عدد من أوجه القصور المكتشفة في المواصفات إلى جهد مجتمع، بتنسيق من المؤلف المشارك روي فيلدنگ، والذي بلغ ذروته في نشر IETF RFC 3986[11] في يناير 2005. على الرغم من تقادمها مع المعيار السابق، إلا أنها لم تجعل تفاصيل مخططات عناوين URL الحالية قديمة؛ يستمر RFC 1738 في التحكم في مثل هذه المخططات ما لم يتم استبدالها بخلاف ذلك. IETF RFC 2616[12]على سبيل المثال، تنقيح مخطط http. في الوقت نفسه، نشرت IETF محتوى RFC 3986 باعتباره المعيار الكامل STD 66، مما يعكس إنشاء بناء جملة URI العام كپروتوكول إنترنت رسمي.

في عام 2001، نشرت مجموعة الهندسة الفنية (TAG) التابعة لـ W3C دليلاً إلى أفضل الممارسات و URIs المتعارف عليها لنشر إصدارات متعددة من مورد معين.[13] على سبيل المثال، قد يختلف المحتوى حسب اللغة أو الحجم لضبط السعة أو إعدادات الجهاز المستخدم للوصول إلى هذا المحتوى.

في أغسطس 2002، أشار IETF RFC 3305[14] أشار إلى أن مصطلح "URL"، على الرغم من الاستخدام العام الواسع، قد تلاشى إلى ما يقرب من التلاشي، ويعمل فقط كتذكير بأن بعض URIs تعمل كعناوين من خلال وجود مخططات تشير إلى إمكانية الوصول إلى الشبكة، بغض النظر عن أي استخدام فعلي. كما توضح المعايير المستندة إلى URI مثل إطار وصف الموارد، فإن تحديد الموارد لا يحتاج إلى اقتراح استرداد تمثيلات الموارد عبر الإنترنت، ولا يحتاج إلى تضمين الموارد المستندة إلى الشبكة على الإطلاق.

يستخدم الوب الدلالي مخطط HTTP URI لتحديد كل من المستندات والمفاهيم في العالم الحقيقي، وهو تمييز تسبب في حدوث ارتباك حول كيفية التمييز بين الاثنين. نشرت TAG رسالة بريد إلكتروني في عام 2005 حول كيفية حل المشكلة، والتي أصبحت تُعرف باسم "حل httpRange-14".[15] قامت W3C لاحقًا بنشر ملاحظة مجموعة الاهتمامات بعنوان عناوين URI الرائعة للوب الدلالي، والتي أوضحت استخدام تفاوض المحتوى ورمز استجابة HTTP 303 لإعادة التوجيه بمزيد من التفصيل.[16]

التصميم

URLs و URNs

إن اسم المورد الموحد (URN) هو URI الذي يعرّف مورداً بالاسم في مساحة اسم معينة. يمكن استخدام URN للتحدث عن مورد دون الإشارة إلى موقعه أو كيفية الوصول إليه. على سبيل المثال، في نظام رقم الكتاب المعياري الدولي (ISBN)، يحدد ISBN 0-486-27557-4 إصداراً معيناً من مسرحية شكسبير "روميو وجولييت . سيكون URN لهذه الطبعة urn:isbn:0-486-27557-4. ومع ذلك، فإنه لا يقدم أي معلومات حول مكان العثور على نسخة من هذا الكتاب.

إن محدد موقع الموارد الموحد (URL) هو URI الذي يحدد وسائل التصرف أو الحصول على تمثيل مورد، أي تحديد آلية الوصول الأساسية وموقع الشبكة. على سبيل المثال، يشير عنوان http://example.org/wiki/Main_Page إلى مورد تم تحديده على أنه /wiki/Main_Page، الذي يمكن الحصول على تمثيله، في شكل HTML والرمز ذي الصلة، عبر پروتوكول نقل النص الفائق (http:) من مضيف الشبكة الذي هو نظام أسماء النطاقات example.org..

يمكن مقارنة URN باسم الشخص، بينما يمكن مقارنة عنوان URL بعنوان الشارع الخاص به. بمعنى آخر، يحدد URN عنصراً ويوفر عنوان URL طريقة للعثور عليه.

تعكس المنشورات الفنية، وخاصة المعايير التي تنتجها IETF و W3C، وجهة نظر محددة في توصية W3C لعام 2001، والتي تقر أسبقية مصطلح URI بدلاً من المصادقة على أي تقسيم فرعي رسمي إلى URL و URN.

URL هو مفهوم مفيد ولكنه غير رسمي: عنوان URL هو نوع من URI الذي يحدد مورداً عبر تمثيل آلية الوصول الأساسية (على سبيل المثال، "موقع" شبكته)، بدلاً من بعض السمات الأخرى التي قد يكون بها.[17]

على هذا النحو، فإن عنوان URL هو ببساطة عنوان URI يحدث للإشارة إلى مورد عبر شبكة.[أ][18]ومع ذلك، في السياقات غير الفنية وفي البرامج الخاصة بشبكة الوب العالمية، يظل مصطلح "URL" مستخدماً على نطاق واسع. بالإضافة إلى ذلك، غالباً ما يحدث مصطلح "عنوان الوب" (الذي ليس له تعريف رسمي) في المنشورات غير الفنية كمرادف لمعرف URI الذي يستخدم مخططات http أو https. يمكن أن تؤدي هذه الافتراضات إلى حدوث ارتباك، على سبيل المثال، في حالة مساحات أسماء XML التي تحتوي على التشابه المرئي مع URIs القابلة للحل.

المواصفات التي ينتجها WHATWG تفضل URL على URI ، ولذلك تستخدم واجهات برمجة تطبيقات HTML5 الأحدث URL على URI .[19]

التوحيد على مصطلح URL. URI و IRI [معرف الموارد الدولي] محيران فقط. في الممارسة العملية، يتم استخدام خوارزمية واحدة لكليهما، لذا فإن الحفاظ على تميزهما لا يساعد أي شخص. URL أيضاً يفوز بسهولة في مسابقة شعبية نتيجة البحث.[20]

بينما تم تصميم معظم مخططات URI في الأصل لاستخدامها مع پروتوكول معين، وغالباً ما يكون لها نفس الاسم، إلا أنها تختلف من حيث المعنى عن الپروتوكولات. على سبيل المثال، يتم استخدام المخطط http بشكل عام للتفاعل مع مورد الوب باستخدام HTTP، لكن المخطط ملف لا يحتوي پروتوكول.

بناء الجملة

يبدأ كل URI باسم مخطط يشير إلى مواصفات لتعيين المعرفات داخل هذا المخطط. على هذا النحو، فإن بناء جملة URI هو نظام تسمية موحد وقابل للتوسيع حيث قد تؤدي مواصفات كل مخطط إلى تقييد بناء الجملة ودلالات المعرفات باستخدام هذا المخطط. البنية العامة لـ URI هي مجموعة شاملة من بناء جملة جميع مخططات URI. تم تعريفه لأول مرة في RFC 2396، الذي نُشر في أغسطس 1998، [9] وتم الانتهاء منه في RFC 3986، المنشور في يناير 2005.[21]

يتكون بناء جملة URI العام من تسلسل هرمي من خمسة مكونات:[22] 

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

حيث ينقسم مكون الوزن إلى ثلاثة مكونات فرعية: 

authority = [userinfo@]host[:port]

يتم تمثيل هذا في مخطط بناء الجملة على النحو التالي:

مخطط بناء جملة URI

يتألف URI من:

  • مكون مخطط غير فارغ متبوعاً بنقطتين (:)، ويتألف من سلسلة من الأحرف تبدأ بحرف ويتبعها أي مجموعة من الأحرف، والأرقام، بالإضافة إلى (+)، والنقطة (.)، أو الواصلة (-). على الرغم من أن المخططات غير حساسة لحالة الأحرف، إلا أن النموذج الأساسي هو أحرف صغيرة ويجب أن تقوم المستندات التي تحدد المخططات بذلك باستخدام أحرف صغيرة. تتضمن أمثلة المخططات الشائعة http ، https ، ftp ، ميلتو ملف البيانات وirc. يجب تسجيل مخططات URI لدى هيئة الأرقام المخصصة للإنترنت (IANA)، على الرغم من استخدام المخططات غير المسجلة في الممارسة العملية.[ب]
  • مكون وزن اختياري مسبوق بشرطتين مائلتين (//)، يشتمل على:
    • مكون فرعي معلومات المستخدم اختياري قد يتكون من اسم مستخدم و كلمة المرور اختيارية مسبوقة بنقطتين (:، متبوعاً برمز في (@). تم إيقاف استخدام التنسيق username:password في المكون الفرعي لمعلومات المستخدم لأسباب أمنية. يجب ألا تعرض التطبيقات أي بيانات بعد علامة النقطتين الأولى (:) الموجودة داخل المكون الفرعي لمعلومات المستخدم، إلا إذا كانت البيانات بعد النقطتين عبارة عن سلسلة فارغة (تشير إلى عدم وجود كلمة مرور).
    • مكون فرعي للمضيف، يتكون إما من اسم مسجل (بما في ذلك على سبيل المثال لا الحصر اسم المضيف)، أو عنوان آي پي. يجب أن تكون عناوين IPv4 في ترميز النقطة العشرية، ويجب وضع عناوين IPv6 بين قوسين <([]).[24][ت]
    • مكون port اختياري فرعي مسبوق بنقطتين (:).
  • مكون مسار، يتألف من سلسلة من مقاطع المسار مفصولة بشرطة مائلة (/). يتم تعريف المسار دائماً لمعرف URI، على الرغم من أن المسار المحدد قد يكون فارغًا (طوله صفر). قد يكون المقطع فارغًا أيضًا ، مما ينتج عنه شرطتين مائلتين متتاليتين ( // ) في مكون المسار. قد يشبه مكون المسار مسار نظام الملفات أو يعينه تماماً، ولكنه لا يعني دائماً وجود علاقة به. إذا كان أحد مكونات الاستناد موجوداًَ، فيجب أن يكون مكون المسار إما فارغاً أو يبدأ بشرطة مائلة (/). إذا كان أحد مكونات الاستناد غائباً، فلا يمكن أن يبدأ المسار بمقطع فارغ، أي بشرطتين مائلتين (//)، حيث سيتم تفسير الأحرف التالية على أنها مكون استنادي.[26] قد تتم الإشارة إلى المقطع الأخير من المسار باسم 'slug'.
محدد الاستعلام مثال
Ampersand (&) key1=value1&key2=value2
Semicolon (;)[ث] key1=value1;key2=value2
  • مكون استعلام اختياري مسبوق بعلامة استفهام (؟)، تحتوي على سلسلة استعلام من البيانات غير الهرمية. لم يتم تعريف بناء الجملة الخاص بها بشكل جيد، ولكن وفقاً للاتفاقية، غالباً ما تكون سلسلة من أزواج سمة-قيمة مفصولة بـ محدد.
  • مكون fragment ختياري مسبوق بـ هاش (#). يحتوي الجزء على معرف جزئي يوفر توجيهاً إلى مورد ثانوي، مثل عنوان قسم في مقالة محددة بواسطة باقي URI. عندما يكون المصدر الأساسي مستند HTML، يكون الجزء غالباً id attribute لعنصر معين، وستقوم متصفحات الويب بتمرير هذا العنصر إلى العرض.

يتم تمثيل سلاسل البيانات من ثماني بتات داخل URI كأحرف. الأحرف المسموح بها داخل URI هي الأحرف آسكي للأحرف الصغيرة والكبيرة للحديث الأبجدية الإنگليزية، و الترقيم العربي، واصلة بين الكلمات، نقطة و شرطة سفلية و تلدة.[28] يجب أن تكون الثمانيات التي يتم تمثيلها بأي حرف آخر مرمز بنسبة مئوية.

من مجموعة أحرف آسكي، الأحرف : / ? # [ ] @ محجوزة للاستخدام كمحددات لمكونات URI العامة ويجب أن تكون مشفرة بالنسبة المئوية – على سبيل المثال، %3F لعلامة الاستفهام. .[29] الأحرف ! $ & ' ( ) * + , ; = مسموح باستخدام بنية URI العامة بدون تشفير في معلومات المستخدم والمضيف والمسار كمحددات. [24][30] بالإضافة إلى ذلك، قد يظهر : و @ غير مشفر داخل المسار والاستعلام والجزء؛ و? و / قد تظهر غير مشفرة كبيانات داخل الاستعلام أو الجزء.[30][31]

يعرض الشكل التالي أمثلة URIs والأجزاء المكونة لها. 

          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


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

مراجع URI

يعد مرجع URI إما URI أو مرجعاً نسبياً عندما لا يبدأ بمكون مخطط متبوعاً بنقطتين(:).[32] لا يمكن استخدام مقطع المسار الذي يحتوي على حرف النقطتين (على سبيل المثال، foo:bar) باعتباره مقطع المسار الأول لمرجع نسبي إذا لم يبدأ مكون المسار الخاص به بشرطة مائلة (/)، حيث يمكن اعتبارها خطأً لمكون مخطط. يجب أن يسبق مقطع المسار هذا مقطع مسار نقطة (على سبيل المثال، ./foo:bar).[33]

تستخدم مستندات الوب لغات توصيف النص بشكل متكرر مراجع URI للإشارة إلى موارد أخرى، مثل المستندات الخارجية أو أجزاء محددة من نفس المستند المنطقي:[34]

  • في HTML، توفر قيمة السمة src للعنصر img مرجع URI، وكذلك قيمة href سمة العنصر a أو link؛
  • في XML، معرف النظام الذي يظهر بعد الكلمة الأساسية SYSTEM في DTD هو مرجع URI غير مجزأ؛
  • في XSLT، قيمة السمة href للعنصر/التعليمات xsl:import هي مرجع URI؛ وبالمثل الوسيطة الأولى لوظيفة 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
#fragment

الثبات

ينتج عن حل مرجع URI مقابل URI الأساسي URI الهدف . هذا يعني أن URI الأساسي موجود وهو URI مطلق (URI بدون مكون جزء). يمكن الحصول على URI الأساسي، بترتيب الأسبقية، من:[35]

  • مرجع URI نفسه إذا كان URI;
  • محتوى التمثيل;
  • الكيان الذي يغلف التمثيل;
  • URI المستخدم للاسترداد الفعلي للتمثيل;
  • سياق التطبيق.

ضمن تمثيل مع قاعدة URI محددة جيداً لـ 

http://a/b/c/d;p?q

يتم حل مرجع نسبي إلى URI الهدف الخاص به على النحو التالي:[36] 

"g:h"     -> "g:h"
"g"       -> "http://a/b/c/g"
"./g"     -> "http://a/b/c/g"
"g/"      -> "http://a/b/c/g/"
"/g"      -> "http://a/g"
"//g"     -> "http://g"
"?y"      -> "http://a/b/c/d;p?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#s"
"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/c/"
".."      -> "http://a/b/"
"../"     -> "http://a/b/"
"../g"    -> "http://a/b/g"
"../.."   -> "http://a/"
"../../"  -> "http://a/"
"../../g" -> "http://a/g"

العلاقات بالنسبة لفضاءات أسماء XML

في XML، فضاء الاسم هي مجال مجرد يمكن تعيين مجموعة من أسماء العناصر والسمات إليه. اسم فضاء الاسم هو سلسلة أحرف يجب أن تلتزم ببنية URI العامة.[37] ومع ذلك، لا يعتبر الاسم عموماً URI ،[38] لأن URI تحدد المواصفات القرار ليس فقط على المكونات المعجمية، ولكن أيضاً على الاستخدام المقصود. لا يعني اسم فضاء الاسم بالضرورة أياً من دلالات مخططات URI؛ على سبيل المثال، اسم فضاء الاسم الذي يبدأ بـ http: قد لا يكون له دلالة على استخدام HTTP.

في الأصل، يمكن أن يتطابق اسم فضاء الاسم مع بناء جملة أي مرجع URI غير فارغ، ولكن استخدام مراجع URI النسبية تم إهماله بواسطة W3C. [39] تسمح مواصفات W3C منفصلة لفضاءات الأسماء في XML 1.1 لمراجع معرف الموارد الدولي (IRI) لتكون بمثابة أساس لأسماء فضاء الاسم بالإضافة إلى مراجع URI.[40]

انظر أيضاً

ملاحظات

  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[23]
  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.[25]
  4. ^ Historic RFC 1866 (obsoleted by RFC 2854) encourages CGI authors to support ';' in addition to '&'.[27]

المراجع

  1. ^ DuCharme, Bob (2013-07-03). Learning SPARQL. O'Reilly Media, Inc. pp. 20–23. ISBN 9781449371470.
  2. ^ W3C. "Universal Resource Identifiers in WWW". W3.Org. Internet Engineering Task Force (IETF). Retrieved 5 December 2020.{{cite web}}: CS1 maint: numeric names: authors list (link)
  3. ^ Palmer, Sean. "The Early History of HTML". infomesh.net. Retrieved 6 December 2020.
  4. ^ "W3 Naming Schemes". www.w3.org. 1992. Retrieved 6 December 2020.
  5. ^ Berners-Lee, Tim (June 1994). "Universal Resource Identifiers in WWW". Network Working Group. Retrieved 6 December 2020.
  6. ^ Berners-Lee, Tim (December 1994). "Request for Comments: 1738: Uniform Resource Locators (URL)". tools.ietf.org/html. Retrieved 6 December 2020.
  7. ^ Moats, R. (May 1997). "Request for Comments: 2141: URN Syntax". tools.ietf.org. Retrieved 6 December 2020.
  8. ^ Berners-Lee, Tim (August 1998). "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax". tools.ietf.org. Retrieved 6 December 2020.
  9. ^ أ ب RFC 2396 (1998).
  10. ^ Hinden, R. (December 1999). "RFC 2732:Format for Literal IPv6 Addresses in URL's". tools.ietf.org. Retrieved 6 December 2020.
  11. ^ Berners-Lee, Tim (January 2005). "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax". tools.ietf.org. Retrieved 6 December 2020.
  12. ^ Fielding, R. (June 1999). "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1". tools.ietf.org. Retrieved 6 December 2020.
  13. ^ Raman, T.V. (1 November 2006). "On Linking Alternative Representations To Enable Discovery And Publishing". www.w3.org. Retrieved 6 December 2020.
  14. ^ Mealling, M. (August 2002). "RFC 3305: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names". tools.ietf.org. Retrieved 6 December 2020.
  15. ^ Fielding, Roy (18 Jun 2005). "[httpRange-14] Resolved". lists.w3.org. Retrieved 6 December 2020.
  16. ^ Sauermann, Leo (December 2008). "Cool URIs for the Semantic Web". www.w3.org. Retrieved 6 December 2020.
  17. ^ URI Planning Interest Group, W3C/IETF (September 2001). "URIs, URLs, and URNs: Clarifications and Recommendations 1.0". www.w3.org. W3C/IETF. Retrieved 8 December 2020.{{cite web}}: CS1 maint: numeric names: authors list (link)
  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, section 3 (2005).
  23. ^ IETF (2015).
  24. ^ أ ب RFC 3986 (2005), §3.2.2.
  25. ^ Lawrence (2014).
  26. ^ RFC 2396 (1998), §3.3.
  27. ^ RFC 1866 (1995), §8.2.1.
  28. ^ RFC 3986 (2005), §2.
  29. ^ RFC 3986 (2005), §2.2.
  30. ^ أ ب RFC 3986 (2005), §3.3.
  31. ^ RFC 3986 (2005), §3.4.
  32. ^ RFC 3986 (2005), §4.1.
  33. ^ RFC 3986 (2005), §4.2.
  34. ^ RFC 3986 (2005), §4.4.
  35. ^ RFC 3986 (2005), §5.1.
  36. ^ RFC 3986 (2005), §5.4.
  37. ^ Morrison (2006).
  38. ^ Harold (2004).
  39. ^ W3C (2009).
  40. ^ W3C (2006).

للاستزادة


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

وصلا خارجية

تمّ الاسترجاع من "https://www.marefa.org/w/index.php?title=معرف_الموارد_الموحد&oldid=2304439"