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

تشترك معرّفات الموارد الموحدة (URIs) وعناوين المواقع الإلكترونية (URLs) في تاريخ مشترك. ففي عام 1990، قدّم تيم بيرنرز لي مقترحاته للنص التشعبي، والتي تضمنت ضمنيًا فكرة عنوان الموقع الإلكتروني (URL) كسلسلة نصية قصيرة تمثل موردًا هو هدف الرابط التشعبي . ^{[ 2 ]} في ذلك الوقت، كان الناس يشيرون إليه باسم "اسم النص التشعبي" ^{[ 3 ]} أو "اسم المستند".

على مدى السنوات الثلاث والنصف التالية، ومع تطور التقنيات الأساسية للشبكة العنكبوتية العالمية ، وهي HTML و HTTP ومتصفحات الويب ، برزت الحاجة إلى التمييز بين سلسلة نصية تُقدّم عنوانًا لمورد ما، وسلسلة نصية تُشير فقط إلى اسم هذا المورد. ورغم عدم وجود تعريف رسمي لها آنذاك، فقد أصبح مصطلح "محدد موقع الموارد الموحد" (URL ) يُستخدم للدلالة على النوع الأول، بينما أصبح مصطلح "اسم المورد الموحد " ( URN )، الأكثر إثارة للجدل، يُستخدم للدلالة على النوع الثاني. في يوليو 1992، أشار تقرير بيرنرز لي حول "مجموعة عمل مُعرّفات المستندات العالمية (UDI) " التابعة لفرقة عمل هندسة الإنترنت (IETF) إلى عناوين URL (كمحددات مواقع موارد موحدة)، وURN (كأرقام موارد فريدة في الأصل)، وإلى ضرورة تشكيل فريق عمل جديد. ^{[ 4 ]} وفي نوفمبر 1992، اجتمعت "مجموعة عمل مُعرّفات المستندات العالمية" التابعة لفرقة عمل هندسة الإنترنت (IETF) لأول مرة. ^{[ 5 ]}

خلال النقاش الدائر حول تعريف عناوين URL ومعرّفات الموارد الموحدة (URNs)، اتضح أن المفاهيم التي يجسدها هذان المصطلحان ليست سوى جوانب من المفهوم الأساسي والشامل لتحديد الموارد . في يونيو 1994، نشرت فرقة عمل هندسة الإنترنت (IETF) وثيقة RFC 1630 ، وهي أول طلب تعليقات من بيرنرز-لي، والذي أقرّ بوجود عناوين URL ومعرّفات الموارد الموحدة. والأهم من ذلك، أنها حددت صيغة رسمية لمعرّفات الموارد الموحدة (أي سلاسل نصية شبيهة بعناوين URL، والتي تعتمد صيغها ودلالاتها الدقيقة على مخططاتها). كما حاولت تلخيص صيغ مخططات عناوين URL المستخدمة آنذاك. وأقرت الوثيقة - دون توحيدها - بوجود عناوين URL النسبية ومعرّفات الأجزاء. ^{[ 6 ]} 

في ديسمبر 1994، عرّفت RFC 1738 ^{[ 7 ]} رسميًا عناوين URL النسبية والمطلقة، وحسّنت بنية عناوين URL العامة، وحددت كيفية تحويل عناوين URL النسبية إلى صيغة مطلقة، وسردت بشكل أفضل مخططات عناوين URL المستخدمة آنذاك. أما تعريف وبنية URNs المتفق عليهما، فقد انتظرا حتى نشر IETF RFC 2141 ^{[ 8 ]} في مايو 1997.  

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

في ديسمبر 1999، قدمت المواصفة RFC 2732 ^{[ 10 ]} تحديثًا طفيفًا للمواصفة RFC 2396 ، مما سمح لمعرفات الموارد الموحدة (URIs) باستيعاب عناوين IPv6 . وقد أدى اكتشاف عدد من أوجه القصور في المواصفتين إلى جهد مجتمعي، نسقه روي فيلدينغ ، أحد مؤلفي RFC 2396 ، والذي تُوِّج بنشر المواصفة IETF RFC 3986 ^{[ 1 ]} في يناير 2005. ورغم أنها ألغت المعيار السابق، إلا أنها لم تجعل تفاصيل مخططات عناوين URL الحالية قديمة؛ إذ لا تزال المواصفة RFC 1738 تحكم هذه المخططات إلا في الحالات التي يتم فيها استبدالها. فعلى سبيل المثال، تُحسِّن المواصفة IETF RFC 2616 ^{[ 11 ]} المخطط. وفي الوقت نفسه، نشرت IETF محتوى RFC 3986 كمعيار كامل STD 66، مما يعكس اعتماد الصيغة العامة لمعرفات الموارد الموحدة (URI) كبروتوكول إنترنت رسمي.   http

في عام 2001، نشرت مجموعة الهندسة المعمارية التقنية التابعة لاتحاد شبكة الويب العالمية (W3C) دليلاً لأفضل الممارسات وعناوين URI القياسية لنشر نسخ متعددة من مورد معين. ^{[ 12 ]} على سبيل المثال، قد يختلف المحتوى باختلاف اللغة أو الحجم لمراعاة سعة أو إعدادات الجهاز المستخدم للوصول إلى ذلك المحتوى.

في أغسطس 2002، أشارت وثيقة IETF RFC 3305 ^{[ 13 ]} إلى أن مصطلح "URL" قد تلاشى تقريبًا حتى أصبح شبه منسي، على الرغم من استخدامه الواسع النطاق، ولا يُستخدم إلا كتذكير بأن بعض معرّفات الموارد الموحدة (URIs) تعمل كعناوين من خلال مخططات تُشير إلى إمكانية الوصول إلى الشبكة، بغض النظر عن أي استخدام فعلي من هذا القبيل. وكما توضح المعايير القائمة على معرّفات الموارد الموحدة، مثل إطار وصف الموارد (Resource Description Framework) ، فإن تحديد الموارد لا يُشير بالضرورة إلى استرجاع تمثيلات الموارد عبر الإنترنت، ولا يُشير بالضرورة إلى موارد قائمة على الشبكة على الإطلاق. 

يستخدم الويب الدلالي نظام معرّف الموارد الموحد (URI) لبروتوكول HTTP لتحديد كلٍّ من المستندات والمفاهيم لأغراض عملية، وهو تمييزٌ أثار بعض اللبس حول كيفية التمييز بينهما. نشرت مجموعة العمل المعنية بالويب الدلالي (TAG) رسالةً إلكترونيةً عام 2005 تتضمن حلاً لهذه المشكلة، عُرف لاحقًا باسم حل httpRange-14 . ^{[ 14 ]} ثم نشر اتحاد شبكة الويب العالمية (W3C) مذكرةً لمجموعة الاهتمام بعنوان "معرّفات موارد موحدة رائعة للويب الدلالي"، شرحت فيها استخدام التفاوض على المحتوى ورمز استجابة HTTP 303 لإعادة التوجيه بمزيد من التفصيل. ^{[ 15 ]}

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

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

يُشبه مُعرّف الموارد الموحد (URN) اسم الشخص، بينما يُشبه عنوان URL عنوانه. بعبارة أخرى، يُحدد مُعرّف الموارد الموحد (URN) عنصرًا ما، بينما يُوفر عنوان URL طريقةً للعثور عليه.

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

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

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

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

يُفضّل توحيد المصطلحات باستخدام URL. فمصطلحي URI وIRI (معرّف الموارد الدولي) مُربكان. عمليًا، تُستخدم خوارزمية واحدة لكليهما، لذا فإنّ التمييز بينهما لا يُفيد أحدًا. كما أنّ مصطلح URL يحظى بشعبية كبيرة في نتائج البحث. ^{[ 18 ]}

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

يحتوي معرّف الموارد الموحد (URI) على مخطط يشير إلى مواصفات لتخصيص المعرّفات ضمن ذلك المخطط. وبذلك، يُعدّ بناء جملة معرّف الموارد الموحد نظام تسمية موحدًا وقابلًا للتوسيع، حيث يمكن لمواصفات كل مخطط أن تُقيّد بناء جملة ودلالات المعرّفات التي تستخدم ذلك المخطط. يُعدّ بناء جملة معرّف الموارد الموحد العام مجموعة شاملة لبناء جملة جميع مخططات معرّف الموارد الموحد. وقد تم تعريفه لأول مرة في RFC 2396 ، المنشور في أغسطس 1998، ^{[ 9 ]} وتمّ اعتماده نهائيًا في RFC 3986 ، المنشور في يناير 2005. ^{[ 19 ]}  

يتكون معرّف الموارد الموحد (URI) من مجموعة مسموح بها من أحرف ASCII، تشمل الأحرف المحجوزة (الفواصل العامة: :, /, ?, #, [, ], @; والفواصل الفرعية: !, $, &, ', (, ), *, +, ,, ;, =), ^{[ 1 ] : 13-14،} والأحرف غير المحجوزة ( الأحرف الكبيرة والصغيرة ، والأرقام العشرية , -, ., _, ~), ^{[ 1 ] : 13-14} ، والحرف %. ^{[ 1 ] : 12.} يتم فصل مكونات بناء الجملة والمكونات الفرعية بواسطة فواصل عن الأحرف المحجوزة (فقط عن الأحرف المحجوزة العامة للمكونات)، وتُعرّف البيانات المُمثلة بأحرف غير محجوزة، وأحرف محجوزة لا تعمل كفواصل في المكون والمكون الفرعي على التوالي، ^{[ 1 ] : §2} ، وتشفيرات النسبة المئوية عندما يكون الحرف المقابل خارج المجموعة المسموح بها أو يُستخدم كفاصل للمكون أو داخله. ترميز النسبة المئوية لثمانية أحرف بيانات تعريفية هو تسلسل من ثلاثة أحرف، يتكون من الحرف %متبوعًا برقمين سداسيين عشريين يمثلان القيمة العددية لتلك الثمانية. ^{[ 1 ] : §2.1}

يتكون بناء الجملة العام لـ URI من خمسة مكونات منظمة هرميًا بترتيب تنازلي للأهمية من اليسار إلى اليمين: ^{[ 1 ] : §3}

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

يكون المكون غير مُعرَّف إذا كان له فاصل مرتبط به ولم يظهر هذا الفاصل في معرّف الموارد الموحد (URI)؛ أما مكونا المخطط والمسار فهما مُعرَّفان دائمًا. ^{[ 1 ] : §5.2.1} يكون المكون فارغًا إذا لم يحتوي على أي أحرف؛ أما مكون المخطط فهو دائمًا غير فارغ. ^{[ 1 ] : §3}

يتكون عنصر السلطة من مكونات فرعية :

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

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

يتضمن معرّف الموارد الموحد (URI) ما يلي:

• غير فارغيتكون مُكوّن المخطط: ، متبوعًا بنقطتين رأسيتين (:)، من سلسلة من الأحرف تبدأ بحرف، متبوعة بأي مزيج من الأحرف أو الأرقام أو علامة الجمع (++) أو النقطة (..) أو الواصلة (-)إلا-أن الشكل المتعارف عليه هو الأحرف الصغيرة، ويجب أن تستخدم المستندات التي تحدد المخططات الأحرف الصغيرة. من أمثلة المخططات الشائعة:.يجبhttpتسجيلمخططات URI لدىهيئة الأرقام المخصصة للإنترنت (IANA)، على الرغم من استخدام المخططات غير المسجلة عمليًا. ^{[ 20 ]}httpsftpmailtofiledatairc
• اختياريمكون السلطة مسبوق بشرطتين مائلتين (//)، ويتألف مما يلي:
  • اختيارييُشار إلى مُكوّن معلومات المستخدم الفرعي برمز @@، والذي قد يتألف مناسم المستخدموكلمة مروراختياريةمسبوقة بنقطتين رأسيتينيُنصح بعدم:استخدام هذا التنسيقداخل مُكوّن معلومات المستخدم الفرعي إلا إذا كانت البيانات التي تلي النقطتين الرأسيتين سلسلة فارغة (مما يشير إلى عدم وجود كلمة مرور).username:password:
  • أالمكون الفرعي للمضيف ، والذي يتكون إما من اسم مسجل (بما في ذلك على سبيل المثال لا الحصر اسمالمضيف) أوعنوان IP.يجب أن تكون عناوينIPv4مكتوبة بنظام النقاط العشرية،ويجب وضع عناوينIPv6[]). ^{[ 1 ] : §3.2.2 [ ب ]}
  • اختياريمكون فرعي للمنفذ مسبوق بنقطتين رأسيتين (:)، ويتكون من أرقام عشرية.
• أيتكون مُكوِّن المسار من سلسلة من أجزاء المسار مفصولة بشرطة مائلة (/). يُعرَّف المسار دائمًا لمعرّف الموارد الموحد (URI)، على الرغم من أن المسار المُعرَّف قد يكون فارغًا (طوله صفر). قد يكون الجزء فارغًا أيضًا، مما ينتج عنه شرطتان مائلتان متتاليتان (//) في مُكوِّن المسار. قد يُشابه مُكوِّن المسارمسار نظام الملفات، ولكنه لا يُشير دائمًا إلى وجود علاقة بينهما. إذا تم تعريف مُكوِّن مرجعي، فيجب أن يكون مُكوِّن المسار إما فارغًا أو يبدأ بشرطة مائلة (/). إذا لم يتم تعريف مُكوِّن مرجعي، فلا يمكن أن يبدأ المسار بجزء فارغ - أي بشرطتين مائلتين (//) - لأن الأحرف التالية ستُفسَّر على أنها مُكوِّن مرجعي. ^{[ 9 ] : §3.3}

بحسب الاصطلاح، في عناوين URI من نوع http و https ، يُطلق على الجزء الأخير من المسار اسميُعدّ pathinfo اختياريًا. ويتكون من صفر أو أكثر من أجزاء المسار التي لا تشير إلى اسم مورد فعلي موجود (مثل ملف أو برنامج وحدة نمطية داخلية أو برنامج قابل للتنفيذ) ولكن إلى جزء منطقي (مثل أمر أو جزء مؤهل) يجب تمريره بشكل منفصل إلى الجزء الأول من المسار الذي يُعرّف وحدة نمطية أو برنامجًا قابلًا للتنفيذ يديره خادمويب؛ ويُستخدم هذا غالبًا لتحديد محتوى ديناميكي (مستند، وما إلى ذلك) أو لتخصيصه حسب الطلب (انظر أيضًا:CGIوPATH_INFO، وما إلى ذلك).

مثال:

URI:"http://www.example.com/questions/3456/my-document"

حيث: "/questions"يمثل الجزء الأول من المسار (وحدة تنفيذية أو برنامج) ويمثل "/3456/my-document"الجزء الثاني من المسار المسمى pathinfo ، والذي يتم تمريره إلى الوحدة التنفيذية أو البرنامج المسمى "/questions"لتحديد المستند المطلوب.

قد يُشار أيضًا إلى عنوان URI من نوع http أو https يحتوي على جزء pathinfo بدون جزء query باسم " عنوان URL نظيف "، والذي قد يكون الجزء الأخير منه " slug ".

• اختيارييتكون عنصر الاستعلام، الذي يسبقه علامة استفهام (?)، منسلسلة استعلامعلى بيانات غير هرمية. لا توجد قواعد نحوية محددة بدقة، ولكن جرت العادة على أن يكون عبارة عن سلسلة منأزواج السمات والقيممفصولةبفاصل.
• اختيارييُسبق مُكوّن الجزء بعلامةهاش(##). يحتوي الجزءعلى مُعرّفيُشير إلى مورد ثانوي، مثل عنوان قسم في مقال يُحدّده الجزء المتبقي من مُعرّف الموارد الموحد (URI). عندما يكون المورد الأساسيHTML، غالبًا ما يكون الجزءidسمةًلعنصر مُحدّد، وستقوم متصفحات الويب بتمرير هذا العنصر لعرضه.

يمكن +استخدام الأحرف المحجوزة الخاصة بالمخطط أو التنفيذ ^في المخطط ، ومعلومات المستخدم، والمضيف، والمسار، والاستعلام، والجزء ، كما يمكن ^{استخدام}! الأحرف ^{المحجوزة} الخاصة بالمخطط أو ^{التنفيذ و} ...$&'()*,;=:@/?

يعرض ما يلي أمثلة على عناوين URI ومكوناتها.

معلومات المستخدم المضيف المنفذ ┌──┴───┐ ┌──────┴──────┐ ┌┴─┐ https : //john.doe@www . example.com :1234/forum/questions/?tag=networking&order=newest#top └─┬─┘ └─────────────┬────────────┘ └───────┬───────┘ └────────────┬─────────────┘ └┬┘ scheme authority path query fragment userinfo host port ┌──┴───┐ ┌──────┴──────┐ ┌┴─┐ https://john.doe@www.example.com:1234/forum/questions/?tag=networking&order=newest#:~:text=whatever └─┬─┘ └─────────────┬─────────────┘ └───────┬───────┘ └─────────────┬────────────┘ └───────┬───────┘ جزء من استعلام مسار سلطة المخططldap ://[2001:db8::7]/c=GB?objectClass?one └┬─┘ └─────┬─────┘ └─┬─┘ └──────┬──────┘ scheme authority path querymailto :John.Doe@example.com └─┬──┘ └────┬─────────────┘ scheme pathالأخبار : comp.infosystems.www.servers.unix └┬─┘ └─────────────┬─────────────────┘ scheme path​​الهاتف : +1-816-555-1212 └┬┘ └──────┬──────┘ مسار المخططtelnet ://192.0.2.16:80/ └─┬──┘ └─────┬─────┘ │ scheme authority pathurn : oasis :names:specification: docbook : dtd : xml :4.1.2 └┬┘ └───────────────────────────────────┘ scheme path

تتناسب معرفات الكائنات الرقمية (DOIs ) مع نظام Handle وتتناسب مع نظام URI، كما هو مُيسر بواسطة بناء الجملة المناسب .

يُعتبر مرجع URI إما مرجع URI أو مرجعًا نسبيًا عندما لا يبدأ بمكون مخطط متبوعًا بنقطتين رأسيتين ( :). ^{[ 1 ] : §4.1} لا يمكن استخدام جزء مسار يحتوي على نقطتين رأسيتين (مثلًا، foo:bar) كأول جزء مسار لمرجع نسبي إذا لم يبدأ مكون مساره بشرطة مائلة ( /)، لأنه سيُعتبر خطأً مكون مخطط. يجب أن يسبق هذا الجزء من المسار جزء مسار بنقطة (مثلًا، ./foo:bar). ^{[ 1 ] : §4.2}

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

• في لغة 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 شظية 

يؤدي حلّ مرجع URI مقابل URI أساسي إلى الحصول على URI هدف . وهذا يعني أن URI الأساسي موجود وهو URI مطلق (URI بدون أي جزء منه). يمكن الحصول على URI الأساسي، حسب ترتيب الأولوية، من: ^{[ 1 ] : §5.1}

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

ضمن تمثيل ذي معرّف موارد موحد أساسي محدد جيدًا لـ

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

يتم حل المرجع النسبي إلى عنوان URI المستهدف على النحو التالي: ^{[ 1 ] : §5.4}

"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" 

تعديل عنوان URL هو أسلوب يتم فيه إلحاق أمر بعنوان URL، عادةً في نهايته، بعد رمز "؟" . يُستخدم هذا الأسلوب بكثرة في WebDAV كآلية لإضافة وظائف إلى HTTP . في نظام إدارة الإصدارات، على سبيل المثال، لإضافة أمر "checkout" إلى عنوان URL، يُكتب على النحو التالي: http://editing.com/resource/file.php?command=checkout. يتميز هذا الأسلوب بسهولة استخدامه من قِبل محللات CGI ، كما أنه يعمل كوسيط بين HTTP والمورد الأساسي، في هذه الحالة. ^{[ 24 ]}

في لغة XML ، يُعرَّف نطاق الاسم بأنه مجال مجرد يُمكن إسناد مجموعة من أسماء العناصر والخصائص إليه. اسم نطاق الاسم عبارة عن سلسلة نصية يجب أن تلتزم بصيغة URI العامة. ^{[ 25 ]} ومع ذلك، لا يُعتبر الاسم عمومًا URI، ^{[ 26 ]} لأن مواصفات URI لا تعتمد في تحديده على المكونات المعجمية فحسب، بل أيضًا على الاستخدام المقصود. لا يُشير اسم نطاق الاسم بالضرورة إلى أي من دلالات مخططات URI؛ على سبيل المثال، قد لا يكون لاسم نطاق اسم يبدأ بـ http: أي دلالة على استخدام بروتوكول HTTP .

في الأصل، كان اسم نطاق الاسم يطابق بنية أي مرجع URI غير فارغ، ولكن تم إيقاف استخدام مراجع URI النسبية من قِبل اتحاد شبكة الويب العالمية (W3C). ^{[ 27 ]} يسمح معيار W3C منفصل لنطاقات الأسماء في XML 1.1 باستخدام مراجع مُعرّف الموارد الدولي (IRI) كأساس لأسماء نطاقات الأسماء بالإضافة إلى مراجع URI. ^{[ 28 ]}

• براي، تيم ؛ هولاندر، ديف؛ لايمان، أندرو؛ توبين، ريتشارد، محرران. (16 أغسطس 2006). "مساحات الأسماء في XML 1.1 (الطبعة الثانية)" . اتحاد شبكة الويب العالمية . 2.2 استخدام معرّفات الموارد الموحدة (URIs) كأسماء لمساحات الأسماء . تم الاطلاع عليه بتاريخ 31 أغسطس 2015 .
• براي، تيم ؛ هولاندر، ديف؛ لايمان، أندرو؛ توبين، ريتشارد؛ طومسون، هنري س.، محرران. (8 ديسمبر 2009). "مساحات الأسماء في XML 1.0 (الطبعة الثالثة)" . اتحاد شبكة الويب العالمية . 2.2 استخدام معرّفات الموارد الموحدة (URIs) كأسماء لمساحات الأسماء . تاريخ الاسترجاع: 31 أغسطس 2015 .
• هارولد، إليوت راستي (2004). الكتاب المقدس XML 1.1 (  الطبعة الثالثة). دار نشر وايلي . ص  291. ISBN 978-0-7645-4986-1.
• لورانس، إريك (2014-03-06). "أسرار المتصفح: عناوين IP الحرفية في عناوين URL" . IEInternals . مايكروسوفت . تم الاسترجاع في 25 أبريل 2016 .
• موريسون، مايكل واين (2006). "الساعة الخامسة: استخدام مساحات الأسماء ". سامز، تعلم لغة XML بنفسك . دار نشر سامز . ص  91.
• وايت هيد، إي جيه (1998). "WebDAV: معيار IEFT للتأليف التعاوني على الويب". مجلة IEEE للحوسبة عبر الإنترنت . 2 (5): 34-40 . doi : 10.1109/4236.722228 . ISSN 1941-0131 .