uri(7)

الاسم
uri, url, urn - معرّف الموارد الموحد (URI)، بما في ذلك URL أو URN

موجز
URI = [ absoluteURI | relativeURI ] [ "#" fragment ]

absoluteURI = scheme .RB " : " ( hierarchical_part | opaque_part )

relativeURI = ( net_path | absolute_path | relative_path ) [ "?" query ]

scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" | "file" | "ftp" | "man" | "info" | "whatis" | "ldap" | "wais" | ...

hierarchical_part = ( net_path | absolute_path ) [ "?" query ]

net_path = "//" authority [ absolute_path ]

absolute_path = "/" path_segments

relative_path = relative_segment [ absolute_path ]

الوصف
معرّف الموارد الموحد (URI) هو سلسلة قصيرة من الأحرف تحدد مورداً مجرداً أو مادياً (مثل صفحة ويب). محدد موقع الموارد الموحد (URL) هو URI يحدد مورداً من خلال آلية الوصول الرئيسية له (مثل "موقعه" الشبكي)، بدلاً من الاسم أو أي سمة أخرى لذلك المورد. اسم المورد الموحد (URN) هو URI يجب أن يبقى فريداً عالمياً ودائماً حتى عندما يتوقف المورد عن الوجود أو يصبح غير متاح.

URIs هي الطريقة القياسية لتسمية وجهات روابط النص الفائق لأدوات مثل متصفحات الويب. السلسلة "http://www.kernel.org" هي URL (وبالتالي هي أيضًا URI). يستخدم العديد من الأشخاص مصطلح URL بشكل فضفاض كمرادف لـ URI (رغم أن URLs تقنياً هي مجموعة فرعية من URIs).

يمكن أن تكون URIs مطلقة أو نسبية. المعرف المطلق يشير إلى مورد مستقل عن السياق، بينما المعرف النسبي يشير إلى مورد بوصف الفرق عن السياق الحالي. ضمن مرجع مسار نسبي، لمقاطع المسار الكاملة "." و ".." معانٍ خاصة: "مستوى التسلسل الهرمي الحالي" و "المستوى فوق هذا المستوى الهرمي"، على التوالي، تماماً كما في أنظمة شبيهة UNIX. لا يمكن استخدام مقطع مسار يحتوي على حرف نقطتين كمقطع أول لمسار URI نسبي (مثل "this:that")، لأنه سيُخلط به كاسم مخطط؛ اسبق هذه المقاطع بـ ./ (مثل "./this:that"). لاحظ أن أحفاد MS-DOS (مثل Microsoft Windows) يستبدلون نقطتين اسم الجهاز بالشريط العمودي ("|") في URIs، لذا "C:" تصبح "C|".

معرّف الجزء، إذا تم تضمينه، يشير إلى جزء مسمى معين (جزء) من المورد؛ النص بعد '#' يحدد الجزء. URI يبدأ بـ '#' يشير إلى ذلك الجزء في المورد الحالي.

  الاستخدام
هناك العديد من مخططات URI المختلفة، لكل منها قواعد ومعانٍ إضافية محددة، لكنها صُممت عمداً لتكون متشابهة قدر الإمكان. على سبيل المثال، تسمح العديد من مخططات URL بأن تكون السلطة بالتنسيق التالي، المسمى هنا ip_server (الأقواس المربعة تظهر ما هو اختياري):

ip_server = [user [ : password ] @ ] host [ : port]

يسمح هذا التنسيق بإدراج اسم مستخدم، أو مستخدم مع كلمة مرور، و/أو رقم منفذ اختيارياً. host هو اسم الكمبيوتر المضيف، إما اسمه كما يحدده DNS أو عنوان IP (أرقام مفصولة بنقاط). وبالتالي فإن URI <http://fred:fredpassword@example.com:8080/> يسجل الدخول إلى خادم ويب على المضيف example.com كـ fred (باستخدام fredpassword) باستخدام المنفذ 8080. تجنب تضمين كلمة مرور في URI إن أمكن بسبب المخاطر الأمنية العديدة لكتابة كلمة مرور. إذا قدم URL اسم مستخدم بدون كلمة مرور، وطلب الخادم البعيد كلمة مرور، فيجب على البرنامج المفسر لـ URL طلبها من المستخدم.

فيما يلي بعض المخططات الأكثر شيوعاً المستخدمة في أنظمة شبيهة UNIX والتي تفهمها العديد من الأدوات. لاحظ أن العديد من الأدوات التي تستخدم URIs لديها أيضًا مخططات داخلية أو مخططات متخصصة؛ راجع توثيق تلك الأدوات للحصول على معلومات حول تلك المخططات.

http - خادم الويب (HTTP)

http://ip_server/path
http://ip_server/path?query

هذا عنوان URL يصل إلى خادم ويب (HTTP). المنفذ المبدئي هو 80. إذا أشار المسار إلى دليل، سيختار خادم الويب ما يعيده؛ عادةً إذا كان هناك ملف باسم "index.html" أو "index.htm"، يُعاد محتواه؛ وإلا، تُنشأ قائمة بالملفات في الدليل الحالي (مع روابط مناسبة) وتُعاد. مثال هو <http://lwn.net>.

يمكن تقديم استعلام بتنسيق "isindex" القديم، الذي يتكون من كلمة أو عبارة ولا يتضمن علامة يساوي (=). يمكن أيضًا أن يكون الاستعلام بتنسيق "GET" الأطول، الذي يحتوي على إدخال استعلام واحد أو أكثر بالصيغة key=value مفصولة بحرف العطف (&). لاحظ أن key يمكن تكراره أكثر من مرة، على الرغم من أن الأمر يعود لخادم الويب وبرامج تطبيقاته لتحديد ما إذا كان هناك أي معنى لذلك. هناك تفاعل مؤسف مع HTML/XML/SGML وتنسيق استعلام GET؛ عندما تُدمج عناوين URI هذه التي تحتوي على أكثر من مفتاح في مستندات SGML/XML (بما في ذلك HTML)، يجب إعادة كتابة حرف العطف (&) كـ &amp;. لاحظ أنه ليست كل الاستعلامات تستخدم هذا التنسيق؛ قد تكون النماذج الأكبر طويلة جدًا لتخزينها كعنوان URI، لذا تستخدم آلية تفاعل مختلفة (تسمى POST) لا تتضمن البيانات في عنوان URI. انظر مواصفات واجهة البوابة المشتركة على http://www.w3.org/CGI لمزيد من المعلومات.

ftp - بروتوكول نقل الملفات (FTP)

ftp://ip_server/path

هذا عنوان URL يصل إلى ملف عبر بروتوكول نقل الملفات (FTP). المنفذ المبدئي (للتحكم) هو 21. إذا لم يُدرج اسم مستخدم، يُقدم اسم المستخدم "anonymous"، وفي هذه الحالة يقدم العديد من العملاء عنوان البريد الإلكتروني للطالب ككلمة مرور. مثال هو <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

gopher - خادم Gopher

gopher://ip_server/gophertype selector
gopher://ip_server/gophertype selector%09search
gopher://ip_server/gophertype selector%09search%09gopher+_string

المنفذ المبدئي لـ gopher هو 70. gophertype هو حقل مكون من حرف واحد للدلالة على نوع Gopher للمورد الذي يشير إليه عنوان URL. قد يكون المسار بأكمله فارغًا أيضًا، وفي هذه الحالة يكون الفاصل "/" اختياريًا أيضًا، ويكون gophertype مبدئيًا "1".

selector هو سلسلة محدد Gopher. في بروتوكول Gopher، سلاسل محدد Gopher هي تسلسل من الثمانيات التي قد تحتوي على أي ثمانيات باستثناء 09 سداسي عشري (US-ASCII HT أو علامة تبويب)، 0A سداسي عشري (حرف US-ASCII LF)، و0D (حرف US-ASCII CR).

mailto - عنوان بريد إلكتروني

mailto:email-address

هذا عنوان بريد إلكتروني، عادةً بالصيغة name@hostname. انظر mailaddr(7) لمزيد من المعلومات حول التنسيق الصحيح لعنوان البريد الإلكتروني. لاحظ أن أي حرف % يجب إعادة كتابته كـ %25. مثال هو <mailto:dwheeler@dwheeler.com>.

news - مجموعة أخبار أو رسالة أخبار

news:newsgroup-name
news:message-id

newsgroup-name هو اسم هرمي مفصول بنقاط، مثل "comp.infosystems.www.misc". إذا كان <newsgroup-name> هو "*" (كما في <news:*>)، يُستخدم للإشارة إلى "جميع مجموعات الأخبار المتاحة". مثال هو <news:comp.lang.ada>.

message-id يتوافق مع Message-ID لـ IETF RFC 1036, (http://www.ietf.org/rfc/rfc1036.txt) بدون "<" و">" المحيطين؛ يأخذ الصيغة unique@full_domain_name. يمكن تمييز معرف الرسالة عن اسم مجموعة الأخبار بوجود الحرف "@".

telnet - تسجيل دخول Telnet

telnet://ip_server/

مخطط عنوان URL لـ Telnet يُستخدم لتعيين خدمات نصية تفاعلية يمكن الوصول إليها عبر بروتوكول Telnet. يمكن حذف الحرف "/" النهائي. المنفذ المبدئي هو 23. مثال هو <telnet://melvyl.ucop.edu/>.

file - ملف عادي

file://ip_server/path_segments
file:مقاطع_المسار

يمثل هذا ملفًا أو دليلاً يمكن الوصول إليه محليًا. كحالة خاصة، يمكن أن تكون خادم_IP السلسلة "localhost" أو السلسلة الفارغة؛ يُفسر هذا على أنه "الجهاز الذي يُفسر منه عنوان URL". إذا كان المسار يؤدي إلى دليل، يجب على العارض عرض محتويات الدليل مع روابط لكل عنصر بداخله؛ لا تفعل كل العارضات هذا حاليًا. تدعم KDE الملفات المُنشأة عبر عنوان URL <file:/cgi-bin>. إذا لم يُعثر على الملف المُعطى، قد يرغب كُتّاب المتصفح في محاولة توسيع اسم الملف عبر التوسيع العام لأسماء الملفات (انظر glob(7) وglob(3)).

التنسيق الثاني (مثل <file:/etc/passwd>) هو تنسيق صحيح للإشارة إلى ملف محلي. ومع ذلك، لم تسمح المعايير القديمة بهذا التنسيق، ولا تتعرف بعض البرامج عليه كـ URI. بناء جملة أكثر قابلية للنقل هو استخدام سلسلة فارغة كاسم الخادم، على سبيل المثال <file:///etc/passwd>؛ هذا النموذج يفعل الشيء نفسه ويسهل التعرف عليه بواسطة مطابقات الأنماط والبرامج القديمة كـ URI. لاحظ أنه إذا كنت تقصد حقًا "البدء من الموقع الحالي"، فلا تحدد المخطط على الإطلاق؛ استخدم عنوانًا نسبيًا مثل <../test.txt>، والذي له أثر جانبي كونه مستقلاً عن المخطط. مثال على هذا المخطط هو <file:///etc/passwd>.

man - توثيق صفحات الدليل

man:اسم-الأمر
man:اسم-الأمر(القسم)

يشير هذا إلى صفحات الدليل المرجعية المحلية عبر الإنترنت (man). يمكن أن يتبع اسم الأمر اختياريًا قوس ورقم القسم؛ انظر man(7) لمزيد من المعلومات حول معنى أرقام الأقسام. مخطط URI هذا فريد للأنظمة الشبيهة بـ UNIX (مثل Linux) وغير مسجل حاليًا من قبل IETF. مثال هو <man:ls(1)>.

info - توثيق صفحات المعلومات

info:اسم-الملف-الافتراضي
info:اسم-الملف-الافتراضي#اسم-العقدة
info:(اسم-الملف-الافتراضي)
info:(اسم-الملف-الافتراضي)اسم-العقدة

يشير هذا المخطط إلى صفحات المعلومات المرجعية عبر الإنترنت (المُنشأة من ملفات texinfo)، وهو تنسيق توثيق تستخدمه برامج مثل أدوات GNU. مخطط URI هذا فريد للأنظمة الشبيهة بـ UNIX (مثل Linux) وغير مسجل حاليًا من قبل IETF. وقت كتابة هذا، يختلف GNOME وKDE في بناء جملة URI ولا يقبلان بناء جملة الآخر. التنسيقان الأولان هما تنسيق GNOME؛ في أسماء العقد، تُكتب كل المسافات كشرطات سفلية. التنسيقان الثانيان هما تنسيق KDE؛ يجب كتابة المسافات في أسماء العقد كمسافات، على الرغم من أن هذا محظور بمعايير URI. يُؤمل أن تفهم معظم الأدوات في المستقبل كل هذه التنسيقات وتقبل دائمًا الشرطات السفلية بدلاً من المسافات في أسماء العقد. في كل من GNOME وKDE، إذا استُخدم النموذج بدون اسم العقدة، يُفترض أن اسم العقدة هو "Top". أمثلة على تنسيق GNOME هي <info:gcc> و<info:gcc#G++_and_GCC>. أمثلة على تنسيق KDE هي <info:(gcc)> و<info:(gcc)G++ and GCC>.

whatis - بحث التوثيق

whatis:سلسلة

يبحث هذا المخطط في قاعدة بيانات الأوصاف القصيرة (ذات السطر الواحد) للأوامر ويعيد قائمة بالأوصاف التي تحتوي على تلك السلسلة. تُعاد فقط مطابقات الكلمات الكاملة. انظر whatis(1). مخطط URI هذا فريد للأنظمة الشبيهة بـ UNIX (مثل Linux) وغير مسجل حاليًا من قبل IETF.

ghelp - توثيق المساعدة في GNOME

ghelp:اسم-التطبيق

يقوم هذا بتحميل مساعدة GNOME للتطبيق المُعطى. لاحظ أنه لا يوجد الكثير من التوثيق حاليًا بهذا التنسيق.

ldap - بروتوكول الوصول إلى الدليل الخفيف

ldap://منفذ_المضيف
ldap://منفذ_المضيف/
ldap://منفذ_المضيف/dn
ldap://منفذ_المضيف/dn?سمات
ldap://منفذ_المضيف/dn?سمات?نطاق
ldap://hostport/dn?attributes?scope?filter
ldap://hostport/dn?attributes?scope?filter?extensions

يدعم هذا المخطط الاستعلامات إلى بروتوكول الوصول الخفيف للأدلة (LDAP)، وهو بروتوكول لاستعلام مجموعة من الخوادم عن معلومات منظمة هرميًا (مثل الأشخاص وموارد الحوسبة). انظر RFC 2255 (http://www.ietf.org/rfc/rfc2255.txt) لمزيد من المعلومات حول مخطط URL الخاص بـ LDAP. مكونات هذا URL هي:

hostport
    خادم LDAP المراد الاستعلام عنه، مكتوبًا كاسم مضيف متبوعًا اختياريًا بنقطتين ورقم المنفذ. المنفذ المبدئي لـ LDAP هو منفذ TCP 389. إذا كان فارغًا، يحدد العميل أي خادم LDAP سيستخدم.

dn  الاسم المميز لـ LDAP، الذي يحدد الكائن الأساسي لبحث LDAP (انظر RFC 2253 (http://www.ietf.org/rfc/rfc2253.txt) القسم 3).

سمات
    قائمة مفصولة بفواصل من السمات المراد إرجاعها؛ انظر RFC 2251 القسم 4.1.5. إذا حُذفت، يجب إرجاع جميع السمات.

scope
    يحدد نطاق البحث، والذي يمكن أن يكون أحد "base" (للبحث عن كائن أساسي)، أو "one" (للبحث على مستوى واحد)، أو "sub" (للبحث في شجرة فرعية). إذا حُذف النطاق، يُفترض "base".

filter
    يحدد مرشح البحث (مجموعة فرعية من الإدخالات المراد إرجاعها). إذا حُذف، يجب إرجاع جميع الإدخالات. انظر RFC 2254 (http://www.ietf.org/rfc/rfc2254.txt) القسم 4.

extensions
    قائمة مفصولة بفواصل من أزواج type=value، حيث يمكن حذف الجزء =value للخيارات التي لا تتطلبه. الامتداد المسبوق بـ '!' هو حرج (يجب دعمه ليكون صالحًا)، وإلا فهو غير حرج (اختياري).

استعلامات LDAP أسهل في الشرح بالمثال. إليك استعلام يطلب من ldap.itd.umich.edu معلومات عن جامعة ميشيغان في الولايات المتحدة:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

للحصول فقط على سمة عنوانها البريدي، اطلب:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

لسؤال host.com على المنفذ 6666 عن معلومات الشخص ذي الاسم الشائع (cn) "Babs Jensen" في جامعة ميشيغان، اطلب:

ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)

wais - خوادم المعلومات الواسعة النطاق

wais://hostport/database
wais://hostport/database?search
wais://hostport/database/wtype/wpath

يعين هذا المخطط قاعدة بيانات WAIS أو بحثًا أو مستندًا (انظر IETF RFC 1625 (http://www.ietf.org/rfc/rfc1625.txt) لمزيد من المعلومات حول WAIS). Hostport هو اسم المضيف، متبوعًا اختياريًا بنقطتين ورقم المنفذ (رقم المنفذ المبدئي هو 210).

يعين الشكل الأول قاعدة بيانات WAIS للبحث. يعين الشكل الثاني بحثًا معينًا لقاعدة بيانات WAIS database. يعين الشكل الثالث مستندًا معينًا داخل قاعدة بيانات WAIS ليتم استرجاعه. wtype هو تعيين WAIS لنوع الكائن، و wpath هو معرف مستند WAIS.

مخططات أخرى

هناك العديد من أنظمة URI الأخرى. تدعم معظم الأدوات التي تقبل عناوين URI مجموعة من عناوين URI الداخلية (على سبيل المثال، يستخدم Mozilla نظام about: للمعلومات الداخلية، ويستخدم متصفح المساعدة في GNOME نظام toc: للوصول إلى مواقع انطلاق متنوعة). هناك العديد من الأنظمة التي تم تعريفها ولكنها لا تستخدم على نطاق واسع في الوقت الحالي (مثل prospero). تم إهمال نظام nntp: لصالح نظام news:. يجب دعم URNs بواسطة نظام urn:، مع مساحة اسم هرمية (على سبيل المثال، urn:ietf:... من شأنه تحديد وثائق IETF)؛ في الوقت الحالي، لا يتم تطبيق URNs على نطاق واسع. لا تدعم جميع الأدوات جميع الأنظمة.

  ترميز المحارف
تستخدم URIs عددًا محدودًا من المحارف بحيث يمكن كتابتها واستخدامها في مجموعة متنوعة من المواقف.

المحارف التالية محجوزة، أي قد تظهر في URI ولكن استخدامها مقصور على غرضها المحجوز (يجب تخطي البيانات المتضاربة قبل تشكيل URI):

        ; / ? : @ & = + $ ,

قد تُضمَّن المحارف غير المحجوزة في URI. تتضمن المحارف غير المحجوزة الأحرف اللاتينية الكبيرة والصغيرة، والأرقام العشرية، والمجموعة المحدودة التالية من علامات الترقيم والرموز:

        - _ . ! ~ * ' ( )

يجب تخطي جميع المحارف الأخرى. يُرمَّز الثُماني المُتخطى كثلاثية محارف، تتكون من حرف النسبة المئوية "%" متبوعًا برقمين سداسي عشريين يمثلان رمز الثماني (يمكنك استخدام أحرف كبيرة أو صغيرة للأرقام السداسية العشرية). على سبيل المثال، يجب تخطي المسافة الفارغة كـ "%20"، وحرف الجدولة كـ "%09"، و"&" كـ "%26". لأن حرف النسبة المئوية "%" دائمًا له الغرض المحجوز لكونه مؤشر التخطي، يجب تخطيه كـ "%25". من الممارسات الشائعة تخطي أحرف المسافة كرمز الجمع (+) في نص الاستعلام؛ هذه الممارسة ليست محددة بشكل موحد في RFCs ذات الصلة (التي توصي بـ %20 بدلاً من ذلك) ولكن يجب أن تكون أي أداة تقبل URIs مع نص استعلام مستعدة لها. يُظهر URI دائمًا في شكله "المُتخطى".

يمكن تهريب الأحرف غير المحجوزة دون تغيير دلالة عنوان URI، ولكن لا ينبغي القيام بذلك ما لم يتم استخدام عنوان URI في سياق لا يسمح بظهور الحرف غير المهرب. على سبيل المثال، يُستخدم ”%7e“ أحيانًا بدلاً من ”~“ في مسار عنوان URL لـ HTTP، لكن كلاهما متكافئان في سياق عناوين URL لـ HTTP.

بالنسبة لـ URIs التي يجب أن تتعامل مع أحرف خارج مجموعة أحرف US ASCII، توصي مواصفات HTML 4.01 (القسم B.2) وIETF RFC 3986 (الفقرة الأخيرة من القسم 2.5) بالنهج التالي:

(1) ترجمة تسلسلات الأحرف إلى UTF-8 (IETF RFC 3629)—انظر utf-8(7)—ثم

(2) استخدام آلية تخطي URI، أي استخدام ترميز %HH للثمانيات غير الآمنة.

  كتابة URI
عند الكتابة، يجب وضع URIs داخل علامتي اقتباس مزدوجتين (مثلًا، "http://www.kernel.org")، أو محاطة بأقواس زاوية (مثلًا، <http://lwn.net>)، أو وضعها في سطر بمفردها. تحذير لمن يستخدمون علامات الاقتباس المزدوجة: لا تنقل علامات الترقيم الدخيلة (مثل النقطة التي تنهي الجملة أو الفاصلة في قائمة) داخل URI، لأن هذا سيغير قيمة URI. بدلاً من ذلك، استخدم الأقواس الزاوية، أو انتقل إلى نظام اقتباس لا يتضمن أبدًا أحرفًا دخيلة داخل علامات الاقتباس. هذا النظام الأخير، المسمى نظام الاقتباس 'الجديد' أو 'المنطقي' بواسطة "قواعد هارت" و"قاموس أكسفورد للكتاب والمحررين"، هو الممارسة المفضلة في بريطانيا العظمى وفي لغات أوروبية مختلفة. اقترحت المستندات الأقدم إدراج البادئة "URL:" قبل URI مباشرة، لكن هذا الشكل لم ينتشر أبدًا.

صُممت صياغة URI لتكون غير غامضة. ومع ذلك، مع شيوع URIs، استخدمت وسائل الإعلام التقليدية (التلفزيون، الراديو، الصحف، اللوحات الإعلانية، إلخ) بشكل متزايد مراجع URI مختصرة تتكون فقط من أجزاء السلطة والمسار للمورد المحدد (مثلًا، <www.w3.org/Addressing>). هذه المراجع مخصصة أساسًا للتفسير البشري وليس الآلي، مع افتراض أن الاستدلالات القائمة على السياق كافية لإكمال URI (مثلًا، أسماء المضيف التي تبدأ بـ "www" من المرجح أن يكون لها بادئة URI "http://" وأسماء المضيف التي تبدأ بـ "ftp" من المرجح أن يكون لها بادئة "ftp://"). تحل العديد من تطبيقات العميل هذه المراجع بشكل استدلالي. قد تتغير هذه الاستدلالات بمرور الوقت، خاصة عند تقديم مخططات جديدة. نظرًا لأن URI المختصر له نفس صياغة مسار URL النسبي، لا يمكن استخدام مراجع URI المختصرة حيث يُسمح بـ URIs النسبية، ويمكن استخدامها فقط عندما لا توجد قاعدة محددة (مثل مربعات الحوار). لا تستخدم URIs مختصرة كروابط نص تشعبي داخل مستند؛ استخدم التنسيق القياسي كما هو موصوف هنا.

المعايير
(IETF RFC 2396) (http://www.ietf.org/rfc/rfc2396.txt), (HTML 4.0) (http://www.w3.org/TR/REC-html40).

ملاحظات
يجب أن تكون أي أداة تقبل URIs (مثلًا، متصفح ويب) على نظام Linux قادرة على التعامل (مباشرة أو غير مباشرة) مع جميع المخططات الموصوفة هنا، بما في ذلك مخططي man: وinfo:. التعامل معها عن طريق استدعاء برنامج آخر مقبول ومشجع في الواقع.

تقنيًا، الجزء ليس جزءًا من URI.

للحصول على معلومات حول كيفية تضمين عناوين URI (بما في ذلك عناوين URL) في تنسيق بيانات ما، انظر الوثائق الخاصة بهذا التنسيق. يستخدم HTML التنسيق <A HREF="uri"> text </A>. أما ملفات Texinfo فتستخدم التنسيق @uref{uri}. يحتوي كل من Man و mdoc على ماكرو UR الذي تمت إضافته مؤخرًا، أو ما عليك سوى تضمين عنوان URI في النص (يجب أن يتمكن العارضون من اكتشاف :// كجزء من عنوان URI).

تختلف بيئتا سطح المكتب GNOME وKDE حاليًا في URIs التي يقبلانها، خاصة في متصفحات المساعدة الخاصة بهما. لسرد صفحات الدليل، يستخدم GNOME <toc:man> بينما يستخدم KDE <man:(index)>، ولسرد صفحات المعلومات، يستخدم GNOME <toc:info> بينما يستخدم KDE <info:(dir)> (يفضل مؤلف صفحة الدليل هذه نهج KDE هنا، على الرغم من أن تنسيقًا أكثر انتظامًا سيكون أفضل). بشكل عام، يستخدم KDE <file:/cgi-bin/> كبادئة لمجموعة من الملفات المُنشأة. يفضل KDE الوثائق بتنسيق HTML، التي يتم الوصول إليها عبر <file:/cgi-bin/helpindex>. يفضل GNOME مخطط ghelp لتخزين وإيجاد الوثائق. لا يتعامل أي من المتصفحين مع مراجع file: للأدلة في وقت كتابة هذا، مما يجعل من الصعب الإشارة إلى دليل كامل باستخدام URI قابل للتصفح. كما هو مذكور أعلاه، تختلف هذه البيئات في كيفية تعاملها مع مخطط info:، ربما يكون الاختلاف الأكثر أهمية. من المتوقع أن تتقارب GNOME وKDE إلى تنسيقات URI شائعة، وسيصف إصدار مستقبلي من صفحة الدليل هذه النتيجة المتقاربة. الجهود للمساعدة في هذا التقارب مشجعة.

  الأمن
لا يشكل عنوان URI في حد ذاته تهديدًا أمنيًا. ولا يوجد ضمان عام بأن عنوان URL، الذي كان في وقت ما يشير إلى مورد معين، سيظل يفعل ذلك. كما لا يوجد أي ضمان بأن عنوان URL لن يشير إلى مورد مختلف في وقت لاحق؛ ولا يمكن الحصول على مثل هذا الضمان إلا من الشخص (الأشخاص) الذي يتحكم في مساحة الاسم تلك والمورد المعني.

من الممكن أحيانًا إنشاء عنوان URL بحيث تؤدي محاولة تنفيذ عملية تبدو غير ضارة، مثل استرداد كيان مرتبط بالمورد، إلى حدوث عملية عن بُعد قد تكون ضارة في الواقع. وعادةً ما يتم إنشاء عنوان URL غير الآمن عن طريق تحديد رقم منفذ غير ذلك المخصص لبروتوكول الشبكة المعني. يتصل العميل دون قصد بموقع يعمل في الواقع ببروتوكول مختلف . يحتوي محتوى عنوان URL على تعليمات تؤدي، عند تفسيرها وفقًا لهذا البروتوكول الآخر، إلى إجراء غير متوقع . ومن الأمثلة على ذلك استخدام عنوان URL لـ gopher لإرسال رسالة غير مقصودة أو منتحلة عبر خادم SMTP.

يجب استخدام الحذر عند استخدام أي URL يحدد رقم منفذ غير المبدئي للبروتوكول، خاصة عندما يكون رقمًا ضمن المساحة المحجوزة.

يجب توخي الحذر عندما يحتوي URI على محددات مُهربة لبروتوكول معين (على سبيل المثال، أحرف CR و LF لبروتوكولات telnet) بحيث لا يتم إلغاء ترميزها قبل الإرسال. قد ينتهك هذا البروتوكول، لكنه يتجنب احتمالية استخدام هذه الأحرف لمحاكاة عملية أو معلمة إضافية في ذلك البروتوكول، مما قد يؤدي إلى تنفيذ عملية عن بعد غير متوقعة وربما ضارة.

من الواضح أنه من غير الحكمة استخدام URI يحتوي على كلمة مرور يُقصد بها أن تكون سرية. على وجه الخصوص، يُوصى بشدة بعدم استخدام كلمة مرور ضمن مكون "userinfo" في URI إلا في تلك الحالات النادرة التي يُقصد فيها أن تكون معلمة "password" عامة.

العلل
قد تُوضع الوثائق في مواقع متنوعة، لذا لا يوجد حالياً مخطط URI جيد للوثائق العامة عبر الإنترنت بتنسيقات عشوائية. المراجع بالصيغة <file:///usr/doc/ZZZ> لا تعمل، لأن التوزيعات المختلفة ومتطلبات التثبيت المحلية قد تضع الملفات في أدلة مختلفة (قد تكون في /usr/doc، أو /usr/local/doc، أو /usr/share، أو مكان آخر). أيضًا، الدليل ZZZ يتغير عادةً عندما يتغير الإصدار (على الرغم من أن مطابقة أسماء الملفات قد تتغلب على هذا جزئياً). أخيراً، استخدام مخطط file: لا يدعم بسهولة الأشخاص الذين يحملون الوثائق ديناميكياً من الإنترنت (بدلاً من تحميل الملفات على نظام ملفات محلي). قد يُضاف مخطط URI مستقبلي (مثل "userdoc:") للسماح للبرامج بتضمين إشارات متبادلة لوثائق أكثر تفصيلاً دون الحاجة إلى معرفة الموقع الدقيق لتلك الوثائق. بدلاً من ذلك، قد يحدد إصدار مستقبلي من مواصفات نظام الملفات مواقع الملفات بشكل كافٍ بحيث يتمكن مخطط file: من تحديد موقع الوثائق.

العديد من البرامج وتنسيقات الملفات لا تتضمن طريقة لدمج أو تنفيذ روابط باستخدام URIs.

العديد من البرامج لا تستطيع التعامل مع جميع تنسيقات URI المختلفة هذه؛ يجب أن تكون هناك آلية قياسية لتحميل URI عشوائي تكتشف آلياً بيئة المستخدمين (مثل النص أو الرسوميات، بيئة سطح المكتب، تفضيلات المستخدم المحلية، والأدوات المنفذة حالياً) وتستدعي الأداة الصحيحة لأي URI.

انظر أيضًا
lynx(1)، man2html(1)، mailaddr(7)، utf-8(7)

IETF RFC 2255 (http://www.ietf.org/rfc/rfc2255.txt)

ترجمة
تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 (https://www.gnu.org/licenses/gpl-3.0.html) أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.