URL адрес

Uniform Resource Locator (от англ. Uniform the Resource Locator, съкратете URL адреса [. ˌ j u ː ɑ ː r an e l ]) - система от унифицирани електронни ресурси или единен определящ местоположение на ресурс ( файл ) ^[1] .

Използва се като стандарт за запис на връзки към обекти в Интернет ( хипертекстови връзки в "World Wide Web" www ).

Съкращението "URL" се използва за обозначаване на имейл адреса в съответствие с GOST R 7.0.5-2008.

История

URL е изобретен от Тим ​​Бернерс-Лий през 1990 г. в стените на Европейския съвет за ядрени изследвания ( фр. Conseil Européen pour la Recherche Nucléaire, ЦЕРН ) в Женева , Швейцария . URL адресът се превърна в основна иновация в Интернет. Първоначално URL адресът е имал за цел да посочи местоположението на ресурсите (най -често файловете) в световната мрежа . В наши дни URL адресите се използват за препращане към адресите на почти всички ресурси в Интернет. Стандартът за URL е заложен в RFC 3986 . В днешно време URL адресите се продават като част от по -обща система за идентификация на URI ресурси, като самият термин URL постепенно отстъпва на по -широкия термин URI . Стандартът за URL адреси се управлява от IETF и неговите филиали.

През 2009 г. Тим Бернерс-Ли предположи, че двойната наклонена черта // в началото на URL адрес е излишна след уточняване на мрежов протокол ^{[2] [3]} .

URL структура

URL адресът е проектиран като система за посочване на местоположението на ресурсите в мрежата възможно най -естествено. Локаторът трябва да бъде лесно разширяем и да използва само ограничен набор от ASCII знаци (например URL никога не използва интервал ). В тази връзка възникна следната традиционна форма на URL нотация:

<схема>:[//[<логин>[:<пароль>]@]<хост>[:<порт>]][/<URL‐путь>][?<параметры>][#<якорь>]

В този запис:

схема

схема за достъп до ресурса; в повечето случаи имаме предвид мрежовия протокол

Влизам

потребителското име, използвано за достъп до ресурса

парола

парола на посочения потребител

домакин

напълно квалифицирано име на домейн на хоста в DNS системата или IP адрес на хоста под формата на четири групи десетични числа, разделени с точки; числата са цели числа в диапазона от 0 до 255.

пристанище

хостпорт за връзка

URL адрес

изясняване на информацията за местоположението на ресурса; зависи от протокола.

настроики

низ за заявка с параметри, предадени на сървъра ( използвайки метода GET ). Започва с герой ? , разделител на параметри - знак & . Пример ?параметр_1=значение_1&параметр_2=значение_2&параметр3=значение_3

котва

идентификатор на котва (английски) руски. предшестван от # . Котвата може да бъде заглавието в документа или атрибута id (английски) на руски. елемент. Използвайки такава връзка, браузърът ще отвори страницата и ще премести прозореца към посочения елемент. Например връзка към този раздел на статията: https://ru.wikipedia.org/wiki/URL#Структура_URL .

URL схеми (протоколи)

В този раздел липсват връзки към източници на информация . Информацията трябва да бъде проверима , в противен случай може да бъде поставена под въпрос и изтрита. Можете да редактирате тази статия, като добавите връзки към авторитетни източници . Тази марка е поставена на 8 септември 2016 г.

Общоприетите URL схеми (протоколи) включват:

• ftp - FTP протокол за прехвърляне на файлове
• http - HTTP протокол за прехвърляне на хипертекст
• rtmp е патентован протокол за съобщения в реално време, използван главно за стрийминг на видео и аудио от уеб камери през интернет.
• rtsp е протокол за стрийминг в реално време.
• https е специална реализация на HTTP протокола, който използва криптиране (обикновено SSL или TLS )
• gopher - Gopher протокол
• mailto - имейл адрес
• новини - Usenet новини
• nntp - Usenet новини през NNTP
• irc - IRC протокол
• smb - SMB / CIFS протокол
• prospero - Услуга за справочници на Prospero
• telnet - връзка към интерактивна Telnet сесия
• wais - системна база данни WAIS
• xmpp - XMPP протокол (част от Jabber )
• файл - името на локалния файл
• данни - директни данни ( Данни: URL )
• тел - обаждане до посочения телефонен номер

Екзотични схеми на URL адреси:

• afs - глобалното име на файла във файловата система на Андрю
• cid - идентификатор на съдържанието за MIME части
• идентификатор в средата на съобщението за имейл
• пощенски сървър - достъп до данни от пощенски сървъри
• nfs е името на файла в мрежовата файлова система на NFS
• tn3270 - емулира интерактивна Telnet 3270 сесия
• z39.50 - Достъп до услугите ANSI Z39.50
• skype - Skype протокол
• smsto - отворете SMS редактора в някои мобилни телефони
• ed2k - P2P мрежа за споделяне на файлове на eDonkey
• market - Android market
• steam - Steam протокол
• bitcoin - Биткойн криптовалута
• ob - OpenBazaar
• tg - Telegram

URL схеми в браузъри:

• view -source - преглед на изходния код на посочената уеб страница в различни браузъри.
• Различните браузъри използват различни ключови думи за достъп до услуги и страници за услуги:
  • хром в браузъра Google Chrome и други браузъри в двигателя на Chromium ^[4] ;
  • около във Firefox и други браузъри Gecko ;
  • опера в Опера ;
  • браузър в браузъра Yandex .

URL кодиране

Стандартът URL използва US- ASCII набор от символи . Това има сериозен недостатък, тъй като са разрешени само латински букви, цифри и няколко препинателни знака. Всички други знаци трябва да бъдат прекодирани. Така например, на кирилица букви, букви с диакритични знаци , лигатури , йероглифи трябва да се рекодират. Кодирането за транскодиране е описано в RFC 3986 и се нарича URL-кодиране, кодиране с URL адрес или процентно кодиране .

Пример за кодиране може да се види в рускоезичната Уикипедия , която използва руския език в URL адреса. Например ред като:

 https://ru.wikipedia.org/wiki/Wikipedia

кодиран като:

 https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F

Изпълнение

Преобразуването се осъществява на два етапа: първо, всеки кириличен знак се кодира в UTF-8 в последователност от два байта, а след това всеки байт от тази последователност се записва в шестнадесетична нотация , предшествана от знак за процент (%):

 B → D0 и 92 →% D0% 92
и → D0 и B8 →% D0% B8
k → D0 и BA →% D0% BA
и → D0 и B8 →% D0% B8 и т.н.

Всички други знаци в URI са кодирани.

Запазените знаци се кодират, както следва:

Кодирането на параметри в Internet Explorer и стария Firefox е малко по -различно ^[8] .

В някои случаи URL адресът се формира с помощта на кодиране Base58 ^[9] .

IRI стандарт

Тъй като буквите на всички азбуки, с изключение на основната латинска азбука , претърпяват такава трансформация, URL адресът с думите на по -голямата част от езиците може да стане нечетлив за човек.

Всичко това е в противоречие с принципа на интернационализма , провъзгласен от всички водещи организации в Интернет , включително W3C и ISOC . Този проблем е призован да реши стандарт IRI ( англ. Internacionalized the Resource the Identifier) - международни идентификатори на ресурси, които не биха представлявали проблем да се използват символи на Unicode и които следователно не нарушават правата на други езици . Трудно е да се каже предварително дали IRIs някога ще заменят толкова широко използвани URL адреси (и URI като цяло).

Ограничение на дължината

Формално дължината на URL адреса не е ограничена, но браузърите имат ограничения за дължината на URL адреса. Не се препоръчва използването на URL адреси, по -дълги от 2048 знака, тъй като Microsoft Internet Explorer има това ограничение ^[10] .

Инициатива PURL

Друг основен недостатък на URL адресите е липсата на гъвкавост. Ресурсите в световната мрежа и интернет се движат, но URL връзките остават, сочещи към липсващи ресурси. Това е особено болезнено за цифровите библиотеки, каталози и енциклопедии. За решаване на този проблем са предложени постоянни локатори PURL ( англ. Persistent Uniform the Resource Locator). По същество това са едни и същи URL адреси, но те не сочат към конкретно местоположение на ресурса, а към запис в базата данни PURL, където от своя страна конкретният URL адрес на ресурса вече е записан. При достъп до PURL сървърът намира необходимия запис в тази база данни и пренасочва заявката към определено местоположение на ресурс. Ако адресът на ресурса се промени, няма нужда да коригирате всички безброй връзки към него - просто трябва да промените записа в базата данни. В момента тази идея не е стандартизирана и не е широко приета.

Вижте също

• URN
• XRI
• Дълги имена на домейни
• Четем от човека URL адрес
• Нормализиране на URL

Бележки (редактиране)

Връзки

• RFC 3986
• URL кодиране