تعیین کننده هویت منابع یکشکل

از ویکیپدیا، دانشنامه آزاد
پرش به ناوبری پرش به جستجو
شناسه منبع یکنواخت (URI)
مخففURI
دامنهشبکه جهانی وب

یک شناسه منبع یکنواخت ( URI ) یک توالی منحصر به فرد از کاراکترها است که یک منبع منطقی یا فیزیکی را که توسط فناوری های وب استفاده می شود، شناسایی می کند. URI ها ممکن است برای شناسایی هر چیزی، از جمله اشیاء دنیای واقعی، مانند افراد و مکان ها، مفاهیم، ​​یا منابع اطلاعاتی مانند صفحات وب و کتاب ها استفاده شوند. برخی از URI ها ابزاری برای مکان یابی و بازیابی منابع اطلاعاتی در یک شبکه (چه در اینترنت یا در یک شبکه خصوصی دیگر، مانند یک سیستم فایل کامپیوتری یا یک اینترانت ) ارائه می کنند. اینها منبع یابهای یکنواخت هستند(URL). یک URL مکان منبع را ارائه می دهد. یک URI منبع را با نام در مکان یا URL مشخص شده شناسایی می کند. سایر URI ها فقط یک نام منحصر به فرد ارائه می دهند، بدون اینکه وسیله ای برای مکان یابی یا بازیابی منبع یا اطلاعات مربوط به آن وجود داشته باشد، اینها نام های یکسان منبع (URN) هستند. فناوری های وب که از URI استفاده می کنند به مرورگرهای وب محدود نمی شوند. URI ها برای شناسایی هر چیزی که با استفاده از چارچوب توصیف منبع (RDF) توصیف شده است، استفاده می شود، به عنوان مثال، مفاهیمی که بخشی از یک هستی شناسی هستند که با استفاده از زبان هستی شناسی وب (OWL) تعریف شده اند، و افرادی که با استفاده از واژگان دوست یک دوست توصیف می شوند، هر کدام از آنها استفاده می کنند. یک URI فردی داشته باشید.

تاریخچه

مفهوم

URI ها و URL ها دارای سابقه مشترک هستند. در سال 1990، پیشنهادات تیم برنرز لی برای فرامتن به طور ضمنی ایده URL را به عنوان یک رشته کوتاه معرفی کرد که نشان دهنده منبعی است که هدف یک ابر پیوند است. [1] در آن زمان، مردم از آن به عنوان "نام ابرمتن" [2] یا "نام سند" یاد می کردند.

در طول سه سال و نیم بعدی، با توسعه فناوری‌های اصلی وب جهانی HTML، HTTP و مرورگرهای وب، نیاز به تمایز رشته‌ای که آدرسی برای یک منبع ارائه می‌کند از رشته‌ای که صرفاً یک منبع را نام می‌برد، پدیدار شد. اگرچه هنوز به طور رسمی تعریف نشده است، اما عبارت Uniform Resource Locator به نمایندگی از اولی و بحث برانگیزتر Uniform Resource Name به نمایندگی از دومی آمده است. در ژوئیه 1992 گزارش برنرز لی در مورد IETF "UDI (شناسه های سند جهانی) BOF " آدرس های اینترنتی (به عنوان مکان یاب منبع یکنواخت)، URN ها (در ابتدا به عنوان شماره های منبع منحصر به فرد) و نیاز به ایجاد یک گروه کاری جدید را ذکر می کند. [3] در نوامبر 1992 IETF"گروه کاری URI" برای اولین بار تشکیل جلسه داد. [4]

در طول بحث در مورد تعریف URL ها و URN ها، آشکار شد که مفاهیم تجسم یافته توسط این دو اصطلاح صرفا جنبه هایی از مفهوم اساسی و فراگیر شناسایی منبع هستند . در ژوئن 1994، IETF اولین درخواست برنرز لی برای نظرات را منتشر کرد که وجود URL ها و URN ها را تایید می کرد. مهمتر از همه، یک نحو رسمی برای شناسه‌های منابع جهانی (یعنی رشته‌های URL مانندی که نحو و معنای دقیق آنها به طرح‌های آنها بستگی دارد) تعریف کرد. علاوه بر این، RFC  1630 تلاش کرد تا نحو طرح‌های URL را که در آن زمان استفاده می‌شد، خلاصه کند. تصدیق کرد - اما استاندارد نکرد- وجود URL های نسبی و شناسه های قطعه. [5]

اصلاح

در دسامبر 1994، RFC 1738 به طور رسمی URL های نسبی و مطلق را تعریف کرد، نحو کلی URL را اصلاح کرد، نحوه حل و فصل URL های نسبی را به شکل مطلق تعریف کرد و طرح های URL را بهتر برشمرد. [6] تعریف و نحو مورد توافق URN ها باید تا انتشار IETF RFC 2141 [7] در می 1997 صبر می کرد.  

انتشار IETF RFC 2396 [8] در آگوست 1998 باعث شد که نحو URI به یک مشخصات جداگانه تبدیل شود [9] و بیشتر بخش‌های RFC 1630 و 1738 مربوط به URIها و URLها به طور کلی توسط IETF بازبینی و گسترش داده شد . RFC جدید معنی "U" را در "URI" به "Uniform" از "Universal" تغییر داد.

در دسامبر 1999، RFC 2732 [10] یک به روز رسانی جزئی برای RFC 2396 ارائه کرد که به URI ها اجازه داد آدرس های IPv6 را در خود جای دهند. تعدادی از کاستی‌های کشف‌شده در دو مشخصات منجر به تلاش‌های جامعه شد، با هماهنگی روی فیلدینگ ، نویسنده RFC 2396، که با انتشار IETF RFC 3986 [11] در ژانویه 2005 به اوج رسید. در حالی که استاندارد قبلی منسوخ شده بود، این کار را انجام نداد. جزئیات طرح های URL موجود را منسوخ می کند. RFC 1738 همچنان بر چنین طرح‌هایی حاکم است، مگر در مواردی که جایگزین شود. به عنوان مثال، IETF RFC 2616 [12] ، آن را اصلاح می کند httpطرح. به طور همزمان، IETF محتوای RFC 3986 را به عنوان استاندارد کامل STD 66 منتشر کرد که منعکس کننده ایجاد نحو عمومی URI به عنوان یک پروتکل رسمی اینترنتی است.

در سال 2001، گروه معماری فنی W3C (TAG) راهنمای بهترین شیوه ها و URI های متعارف برای انتشار نسخه های متعدد از یک منبع معین را منتشر کرد. [13] برای مثال، محتوا ممکن است بر اساس زبان یا اندازه متفاوت باشد تا ظرفیت یا تنظیمات دستگاه مورد استفاده برای دسترسی به آن محتوا تنظیم شود.

در آگوست 2002، IETF RFC 3305 [14] اشاره کرد که اصطلاح "URL"، علیرغم استفاده گسترده عمومی، تقریباً منسوخ شده است، و تنها به عنوان یادآوری است که برخی از URI ها با داشتن طرح هایی که دلالت بر دسترسی به شبکه دارند، صرف نظر از این، به عنوان آدرس عمل می کنند. از هر گونه استفاده واقعی همانطور که استانداردهای مبتنی بر URI مانند چارچوب توصیف منابع آشکار می‌سازند، شناسایی منبع نیازی به بازیابی بازنمایی منابع از طریق اینترنت ندارد و اصلاً نیازی به منابع مبتنی بر شبکه ندارد.  

وب معنایی از طرح HTTP URI برای شناسایی اسناد و مفاهیم در دنیای واقعی استفاده می کند، تمایزی که باعث سردرگمی در مورد نحوه تشخیص این دو شده است. TAG در سال 2005 ایمیلی در مورد چگونگی حل این مشکل منتشر کرد که به وضوح httpRange-14 معروف شد . [15] W3C متعاقباً یک یادداشت گروه مورد علاقه با عنوان Cool URIs for the Semantic Web منتشر کرد که استفاده از مذاکره محتوا و کد پاسخ HTTP 303 را برای تغییر مسیرها با جزئیات بیشتری توضیح می‌داد. [16]

طراحی

URL ها و URN ها

یک نام منبع یکنواخت (URN) یک URI است که یک منبع را با نام در یک فضای نام خاص شناسایی می کند. یک URN ممکن است برای صحبت در مورد یک منبع بدون اشاره به مکان یا نحوه دسترسی به آن استفاده شود. برای مثال، در سیستم شماره کتاب استاندارد بین‌المللی (ISBN)، ISBN 0-486-27557-4 نسخه خاصی از نمایشنامه شکسپیر رومئو و ژولیت را مشخص می‌کند. URN برای آن نسخه urn:isbn:0-486-27557-4 خواهد بود. با این حال، هیچ اطلاعاتی در مورد اینکه کجا می توان نسخه ای از آن کتاب را پیدا کرد، ارائه نمی دهد.

یک منبع یاب یکنواخت (URL) یک URI است که ابزار عمل یا به دست آوردن نمایش یک منبع را مشخص می کند، یعنی هم مکانیسم دسترسی اولیه و هم مکان شبکه را مشخص می کند. برای مثال، URL http://example.org/wiki/Main_Pageبه منبعی اشاره می‌کند که به‌عنوان HTML شناخته می‌شود /wiki/Main_Page، که نمایش آن در قالب HTML و کدهای مرتبط، از طریق پروتکل انتقال ابرمتن ( http: ) از میزبان شبکه‌ای که نام دامنه آن است قابل دستیابی است example.org.

یک URN مشابه نام یک شخص است، در حالی که یک URL مشابه آدرس خیابان آنها است. به عبارت دیگر، یک URN یک آیتم را شناسایی می کند و یک URL روشی برای یافتن آن ارائه می دهد.


نشریات فنی، به‌ویژه استانداردهای تولید شده توسط IETF و W3C ، معمولاً دیدگاهی را منعکس می‌کنند که در توصیه W3C در 30 ژوئیه 2001 آمده است، که اولویت عبارت URI را به جای تأیید هرگونه تقسیم رسمی به URL و URN تأیید می‌کند.

URL یک مفهوم مفید اما غیر رسمی است: URL نوعی از URI است که یک منبع را از طریق نمایش مکانیزم دسترسی اولیه آن (مثلاً "موقعیت" شبکه آن)، به جای برخی از ویژگی های دیگر که ممکن است داشته باشد، شناسایی می کند. [17]

به این ترتیب، URL به سادگی یک URI است که اتفاقاً به یک منبع از طریق شبکه اشاره می کند. [a] [18] با این حال، در زمینه های غیر فنی و در نرم افزار برای شبکه جهانی وب، اصطلاح "URL" همچنان به طور گسترده استفاده می شود. علاوه بر این، اصطلاح «آدرس وب» (که هیچ تعریف رسمی ندارد) اغلب در نشریات غیر فنی به عنوان مترادف یک URI که از طرح‌های http یا https استفاده می‌کند، استفاده می‌شود. چنین فرضیاتی می تواند منجر به سردرگمی شود، برای مثال، در مورد فضاهای نام XML که شباهت بصری به URI های قابل حل دارند.

مشخصات تولید شده توسط WHATWG URL را به URI ترجیح می دهند و بنابراین API های جدیدتر 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 از مجموعه مجاز کاراکترهای ASCII متشکل از کاراکترهای رزرو شده (عمومی: :, /, ?, #, [, ]و @؛ طرح یا پیاده سازی خاص: !, $, &, ', (, ), *, +, ,, ;, و =) تشکیل شده است، [22] بدون رزرو کاراکترها ( حروف بزرگ و کوچک ، ارقام اعشاری،،،، و ) ، -[ 23 ] و کاراکتر . [24] اجزای نحو و اجزای فرعی با جدا شده اند._~%جداکننده‌ها از کاراکترهای رزرو شده (فقط از کاراکترهای رزرو شده عمومی برای مؤلفه‌ها) و تعریف داده‌های شناسایی نشان‌داده‌شده به‌عنوان کاراکترهای رزرو نشده، کاراکترهای رزرو شده که به‌ترتیب به‌عنوان جداکننده در مؤلفه و زیر مؤلفه عمل نمی‌کنند، [25] و درصد رمزگذاری‌ها زمانی که کاراکتر مربوطه است. خارج از مجموعه مجاز یا به عنوان جداکننده یا در داخل جزء استفاده می شود. رمزگذاری درصدی یک اکتت داده شناسایی ، دنباله ای از سه کاراکتر است که متشکل از کاراکتر %و به دنبال آن دو رقم هگزا دسیمال نشان دهنده مقدار عددی آن اکتت است. [24]


نحو عمومی URI شامل پنج جزء است که به صورت سلسله مراتبی به ترتیب کاهش اهمیت از چپ به راست سازماندهی شده اند: [26]

URI = طرح ":" ["//" مرجع] مسیر ["?" پرس و جو] [قطعه "#"]

اگر یک جزء دارای یک جداکننده مرتبط باشد و جداکننده در URI ظاهر نشود، تعریف نشده است. اجزای طرح و مسیر همیشه تعریف می شوند. [27] یک جزء در صورتی خالی است که هیچ کاراکتری نداشته باشد. جزء طرح همیشه خالی نیست. [26]

مؤلفه اقتدار از اجزای فرعی تشکیل شده است :

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

این در یک نمودار نحوی به صورت زیر نمایش داده می شود:

نمودار نحوی URI

URI شامل:

  • یک غیر خالیجزء طرح به دنبال دو نقطه (:)، متشکل از دنباله ای از کاراکترها که با یک حرف شروع می شود و با هر ترکیبی از حروف، اعداد، به اضافه (+)، نقطه (.) یا خط فاصله (-) همراه می شود. اگرچه طرح‌ها به حروف بزرگ و کوچک حساس نیستند، شکل متعارف آن حروف کوچک است و اسنادی که طرح‌ها را مشخص می‌کنند باید این کار را با حروف کوچک انجام دهند. نمونه هایی از طرح های محبوب عبارتندازhttp,https,ftp,mailto,fileوdata. ircطرح‌های URI باید درسازمان شماره‌های اختصاص داده شده اینترنتی (IANA)ثبت شوند، اگرچه طرح‌های ثبت نشده در عمل استفاده می‌شوند. [ب]
  • یک اختیاریمؤلفه اقتدار// با دو اسلش ( ) که شامل:
    • یک اختیاریجزء فرعی userinfo به دنبال نماد at (@)، که ممکن است شامل یکنام کاربریرمز عبوراختیاری باشد کهقبل از آن یک دونقطه (:) قرار دارد. استفاده از قالبusername:passwordدر زیرمجموعه اطلاعات کاربر به دلایل امنیتی منسوخ شده است. برنامه‌ها نباید هیچ داده‌ای را بعد از اولین کولون (:) موجود در زیرمجموعه اطلاعات کاربر به صورت متن واضح ارائه کنند، مگر اینکه داده‌های بعد از دو نقطه، رشته خالی باشد (که نشان دهنده عدم وجود رمز عبور باشد).
    • آجزء فرعی میزبان ، که از یک نام ثبت شده (شامل نام میزبان اما نه محدود بهنام میزبان) یا یکآدرس IPتشکیل شده است. آدرس‌های IPv4بایدبا نماد اعشاری نقطه‌ایوIPv6باید در پرانتز ([]) قرار گیرند. [29] [ج]
    • یک اختیاریزیر جزء پورت که قبل از آن یک دونقطه (:)، متشکل از ارقام اعشاری قرار دارد.
  • آجزء مسیر ، متشکل از دنباله ای از بخش های مسیر که با یک اسلش (/) از هم جدا شده اند. یک مسیر همیشه برای یک URI تعریف می شود، اگرچه مسیر تعریف شده ممکن است خالی باشد (طول صفر). همچنین ممکن است یک قطعه خالی باشد که منجر به دو اسلش متوالی (//) در جزء مسیر شود. یک جزء مسیر ممکن است دقیقاً شبیه یکمسیر سیستم فایل باشد، اما همیشه به ارتباطی با یکی دلالت نمی کند. اگر یک مؤلفه اقتدار تعریف شده باشد، مؤلفه مسیر یا باید خالی باشد یا با یک اسلش (/) شروع شود. اگر یک مؤلفه مرجع تعریف نشده باشد، مسیر نمی تواند با یک بخش خالی شروع شود - یعنی با دو اسلش (//) - زیرا کاراکترهای زیر به عنوان یک مؤلفه مرجع تفسیر می شوند. [31]
طبق قرارداد، در URI های http و https ، آخرین قسمت یک مسیر نامگذاری می شودpathinfo و اختیاری است. این بخش توسط صفر یا چند بخش مسیر تشکیل شده است که به یک نام منبع فیزیکی موجود (مثلاً یک فایل، یک برنامه ماژول داخلی یا یک برنامه اجرایی) اشاره نمی‌کند، بلکه به یک بخش منطقی (مثلاً یک فرمان یا یک بخش واجد شرایط) اشاره دارد که باید به طور جداگانه به قسمت اول مسیر که یک ماژول اجرایی یا برنامه مدیریت شده توسطوب سرور را. این اغلب برای انتخاب محتوای پویا (یک سند و غیره) یا برای تنظیم آن مطابق درخواست استفاده می شود (همچنین نگاه کنید به:CGIو PATH_INFO و غیره).
مثال:
URI:"http://www.example.com/questions/3456/my-document"
Where: "/questions"اولین قسمت مسیر است (یک ماژول یا برنامه اجرایی) و "/3456/my-document"قسمت دوم مسیر با نام pathinfo است که "/questions"برای انتخاب سند درخواستی به ماژول یا برنامه اجرایی نامگذاری شده ارسال می شود.
یک http یا https URI حاوی یک قسمت pathinfo بدون بخش پرس و جو نیز ممکن است به عنوان یک URL تمیز نامیده شود که آخرین قسمت آن ممکن است یک ' slug ' باشد.
جداکننده پرس و جو مثال
آمپرسند ( &) key1=value1&key2=value2
نقطه ویرگول ( ;) [d] key1=value1;key2=value2
  • یک اختیاریجزء پرس و جو قبل از علامت سوال (?)، متشکل از یکرشته پرس و جواز داده های غیر سلسله مراتبی است. نحو آن به خوبی تعریف نشده است، اما طبق قرارداد اغلب دنباله ای ازجفت های ویژگی-مقدار استکه توسط یکجداکنندهاند.
  • یک اختیاریجزء قطعه قبل ازهش(#). قطعه حاوی یکشناسه قطعه استکه جهت یک منبع ثانویه را فراهم می کند، مانند عنوان بخش در یک مقاله که توسط بقیه URI شناسایی می شود. هنگامی که منبع اصلی یکHTMLاست، قطعه اغلب یکidویژگیاز یک عنصر خاص است و مرورگرهای وب این عنصر را به نمایش می‌گذارند.

نویسه رزرو شده خاص طرح یا پیاده سازی +ممکن است در طرح، اطلاعات کاربر، میزبان، مسیر، پرس و جو و قطعه، و نویسه های رزرو شده خاص طرح یا پیاده سازی !، $, &, ', (, ), *, ,, ;و =ممکن است استفاده شود در اطلاعات کاربر، میزبان، مسیر، پرس و جو و قطعه. علاوه بر این، کاراکتر رزرو شده عمومی :ممکن است در اطلاعات کاربر، مسیر، پرس و جو و قطعه، کاراکترهای رزرو شده عمومی @و /ممکن است در مسیر، پرس و جو و قطعه استفاده شود، و کاراکتر رزرو شده عمومی ?ممکن است در پرس و جو و قطعه استفاده شود. [33]

نمونه های URI

شکل زیر نمونه های URI و اجزای سازنده آنها را نشان می دهد.

                 پورت میزبان       اطلاعات کاربر ┌──┴───┐ ┌──────┴─────
            
  https://[email protected]:123/forum/questions/?tag=networking&order=newest#top
  └¡┬┬┘    └* └******************* الم  
                                                          

  ldap://[2001:db8::7]/c=GB?objectClass?one
  └┬─┘ └─────┬─────┘└─┬─
  پرس و جو مسیر مرجع طرح

  mailto:[email protected]
  └─┬──┘ └────┬─────────
  مسیر طرح

  news:comp.infosystems.www.servers.unix
  └┬─┘ └─────────────┬-
  مسیر طرح

  تلفن: +1-816-555-1212
  └┬┘ └──────┬──────┘
  مسیر طرح

  telnet://192.0.2.16:80/
  └─┬──┘ └─────┬─────┘│
  مسیر اختیارات طرح

  urn:oasis:names:specification:docbook:dtd:xml:4.1.2
  └┬┘ └ └ └ └ └ └ └ └ └ └ └ └ └ └ └ └ └ └ └ └ توانند
  مسیر طرح

DOIها (شناسه‌های دیجیتالی شیء ) در سیستم Handle قرار می‌گیرند و در داخل سیستم URI قرار می‌گیرند، همانطور که توسط نحو مناسب تسهیل می‌شود .

ارجاعات URI

یک مرجع URI یا یک URI یا یک مرجع نسبی است زمانی که با یک جزء طرح و سپس یک دونقطه ( :) شروع نمی شود. [34] یک قطعه مسیر که حاوی یک کاراکتر کولون است (به عنوان مثال، foo:bar) نمی تواند به عنوان اولین بخش مسیر یک مرجع نسبی استفاده شود، اگر جزء مسیر آن با یک اسلش ( /) شروع نشود، زیرا ممکن است با یک جزء طرح اشتباه گرفته شود. قبل از چنین قطعه مسیری باید یک قطعه مسیر نقطه ای قرار گیرد (مثلاً ./foo:bar). [35]

زبان‌های نشانه‌گذاری سند وب اغلب از ارجاعات URI برای اشاره به منابع دیگر، مانند اسناد خارجی یا بخش‌های خاصی از همان سند منطقی استفاده می‌کنند: [36]

  • در 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 پایه را می توان به ترتیب اولویت از: [37] به دست آورد:

  • خود URI مرجع اگر URI باشد.
  • محتوای نمایندگی؛
  • نهادی که نمایندگی را محصور می کند.
  • URI مورد استفاده برای بازیابی واقعی نمایش؛
  • زمینه برنامه

در یک نمایش با یک URI پایه به خوبی تعریف شده از

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

یک مرجع نسبی به URI هدف خود به صورت زیر حل می شود: [38]

"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 munging تکنیکی است که توسط آن یک دستور به URL الحاق می‌شود ، معمولاً در انتها، پس از یک "?" نشانه . معمولاً در WebDAV به عنوان مکانیزمی برای افزودن عملکرد به HTTP استفاده می شود. در یک سیستم نسخه‌سازی، برای مثال، برای افزودن یک دستور «checkout» به URL، به صورت نوشته می‌شود http://editing.com/resource/file.php?command=checkout. این مزیت هم این است که برای تجزیه کننده های CGI آسان است و هم به عنوان یک واسطه بین HTTP و منبع اصلی در این مورد عمل می کند. [39]

ارتباط با فضاهای نام XML

در XML ، فضای نام یک دامنه انتزاعی است که مجموعه‌ای از نام‌های عناصر و ویژگی‌ها را می‌توان به آن اختصاص داد. نام فضای نام یک رشته کاراکتر است که باید به نحو عمومی URI پایبند باشد. [40] با این حال، این نام به طور کلی به عنوان یک URI در نظر گرفته نمی شود، [41] زیرا مشخصات URI تصمیم را نه تنها بر اساس مؤلفه های واژگانی، بلکه بر اساس استفاده مورد نظر آنها نیز قرار می دهد. نام فضای نام لزوماً به معنای معنایی طرح‌های URI نیست. برای مثال، نام فضای نامی که با http: شروع می شود ممکن است هیچ معنایی برای استفاده از HTTP نداشته باشد.

در اصل، نام فضای نام می توانست با نحو هر مرجع URI غیر خالی مطابقت داشته باشد، اما استفاده از مراجع URI نسبی توسط W3C منسوخ شد. [42] یک مشخصه جداگانه W3C برای فضاهای نام در XML 1.1 به ارجاعات شناسه منبع بین المللی (IRI) اجازه می دهد تا علاوه بر ارجاعات URI به عنوان مبنایی برای نام فضای نام نیز عمل کنند. [43]

همچنین ببینید

یادداشت ها

  1. ^ گزارشی که در سال 2002 توسط یک گروه کاری مشترک W3C/IETF منتشر شد، با هدف عادی سازی دیدگاه های متفاوت در IETF و W3C در مورد رابطه بین شرایط و استانداردهای مختلف "UR*". در حالی که به عنوان یک استاندارد کامل توسط هیچ یک از سازمان ها منتشر نشده است، اما مبنایی برای درک مشترک فوق شده است و از آن زمان به بعد استانداردهای زیادی را ارائه کرده است.
  2. ^ رویه‌های ثبت طرح‌های URI جدید در ابتدا در سال 1999 توسط RFC 2717 تعریف شد و اکنون توسطRFC  7595 ، منتشر شده در ژوئن 2015 تعریف شده است. [28] 
  3. ^ برای URI های مربوط به منابع در شبکه جهانی وب، برخی از مرورگرهای وب اجازه می دهند.0بخش هایی از نمادهای اعشاری نقطه ای حذف شوند یا از آدرس های IP اعداد صحیح خام استفاده شود. [30]
  4. ^ Historic RFC 1866 (منسوخ شده توسطRFC  2854 ) نویسندگان CGI را تشویق می کند تا از ';' بعلاوه '&'. [32] 

منابع

  1. ^ پالمر، شان. "تاریخ اولیه HTML" . infomesh.net . بازیابی شده در 2020-12-06 .
  2. «طرح‌های نام‌گذاری W3» . www.w3.org . 1992 . بازیابی شده در 2020-12-06 .
  3. «مجموعه مقالات بیست و چهارمین کارگروه مهندسی اینترنت» (PDF) . پ. 193 . بازیابی شده در 2021-07-27 .
  4. «مجموعه مقالات بیست و پنجمین کارگروه مهندسی اینترنت» (PDF) . پ. 501 . بازیابی شده در 2021-07-27 .
  5. برنرز لی، تیم (ژوئن 1994). "شناسه های منبع جهانی در WWW" . کارگروه شبکه doi : 10.17487/RFC1630 . بازیابی شده در 2020-12-06 . {{cite journal}}: Cite journal requires |journal= (help)
  6. برنرز لی، تیم (دسامبر ۱۹۹۴). "درخواست نظرات: 1738: مکان یاب منبع یکنواخت (URL)" . tools.ietf.org/html . doi : 10.17487/RFC1738 . بازیابی شده در 2020-12-06 .
  7. Moats, R. (مه 1997). "درخواست نظرات: 2141: URN Syntax" . tools.ietf.org . doi : 10.17487/RFC2141 . بازیابی شده در 2020-12-06 .
  8. برنرز لی، تیم (اوت 1998). "RFC 2396: شناسه های منبع یکنواخت (URI): نحو عمومی" . tools.ietf.org . doi : 10.17487/RFC2396 . بازیابی شده در 2020-12-06 .
  9. ^ a b RFC 2396 (1998) .
  10. ^ Hinden, R. (دسامبر 1999). "RFC 2732: فرمت برای آدرس های IPv6 واقعی در URL" . tools.ietf.org . doi : 10.17487/RFC2732 . بازیابی شده در 2020-12-06 .
  11. برنرز لی، تیم (ژانویه 2005). "RFC 3986: شناسه منبع یکسان (URI): نحو عمومی" . tools.ietf.org . doi : 10.17487/RFC3986 . بازیابی شده در 2020-12-06 .
  12. ^ فیلدینگ، آر. (ژوئن 1999). "RFC 2616: پروتکل انتقال ابرمتن -- HTTP/1.1" . tools.ietf.org . doi : 10.17487/RFC2616 . بازیابی شده در 2020-12-06 .
  13. رامان، تلویزیون (01-11-2006). "در ارتباط با نمایندگی های جایگزین برای فعال کردن کشف و انتشار" . www.w3.org . بازیابی شده در 2020-12-06 .
  14. ^ Mealling، M. (اوت 2002). میلینگ، ام. دننبرگ، آر (ویرایش‌ها). "RFC 3305: شناسه های یکنواخت منبع (URI)، URL ها و نام های یکنواخت منابع" . tools.ietf.org . doi : 10.17487/RFC3305 . بازیابی شده در 2020-12-06 .
  15. فیلدینگ، روی (2005-06-18). "[httpRange-14] حل شد" . lists.w3.org _ بازیابی شده در 2020-12-06 .
  16. Sauermann, Leo (دسامبر 2008). "URI های جالب برای وب معنایی" . www.w3.org . بازیابی شده در 2020-12-06 .
  17. ^ URI Planning Interest Group، W3C/IETF (سپتامبر 2001). "URI ها، URL ها و URN ها: توضیحات و توصیه ها 1.0" . www.w3.org . W3C/IETF . بازیابی شده در 08-12-2020 .
  18. گروه مشترک W3C /IETF URI Planning Interest Group (2002) .
  19. ^ "URL Standard: 6.3. URL APIs در جاهای دیگر" .
  20. "URL Standard: Goals" .
  21. ^ RFC 3986 (2005) .
  22. ^ RFC 3986 (2005) ، §2.2.
  23. ^ RFC 3986 (2005) ، §2.3.
  24. ^ a b RFC 3986 (2005) ، §2.1.
  25. ^ RFC 3986 (2005) ، §2.
  26. ^ a b RFC 3986 (2005) ، §3.
  27. ^ RFC 3986 (2005) ، §5.2.1.
  28. ^ IETF (2015) .
  29. ^ RFC 3986 (2005) ، §3.2.2.
  30. لارنس (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. ^ RFC 3986 (2005) ، §5.1.
  38. ^ RFC 3986 (2005) ، §5.4.
  39. ^ وایتهد 1998 ، ص. 38.
  40. موریسون (2006) .
  41. هارولد (2004) .
  42. ^ W3C (2009) .
  43. ^ W3C (2006) .

ادامه مطلب

پیوندهای خارجی