Единый указатель ресурсов (англ.
URL - Uniform Resource Locator) — единообразный локатор (определитель местонахождения) ресурса. На английский манер произносится как [
эо́рл], по-русски чаще говорят [
у-эр-э́л] или [
урла́]. Ранее назывался
Universal Resource Locator — универсальный локатор ресурса. URL — это стандартизированный способ записи адреса ресурса в сети Интернет.
История
URL был изобретён Тимом Бернерсом-Ли в 1990 году в стенах Европейского совета по ядерным исследованиям (фр.
Conseil Européen pour la Recherche Nucléaire, CERN) в Женеве, Швейцария.
URL стал фундаментальной инновацией в Интернете. Изначально URL
предназначался для обозначения мест расположения ресурсов (чаще всего
файлов) во Всемирной паутине. Сейчас URL применяется для обозначения адресов почти всех ресурсов Интернета. Стандарт URL закреплён в документе
RFC 1738, прежняя версия была определена в
RFC 1630. Сейчас URL позиционируется как часть более общей системы идентификации ресурсов URI, сам термин URL постепенно уступает место более широкому термину
URI. Cтандарт URL регулируется организацией IETF и её подразделениями.
Структура URL
Изначально локатор URL был разработан как система для максимально
естественного указания на местонахождения ресурсов в сети. Локатор
должен был быть легко расширяемым и использовать лишь ограниченный
набор ASCII-символов (к примеру, пробелкодировки. В связи с этим, возникла следующая традиционная форма записи URL: никогда не применяется в URL) для представления любой
<схема>://<логин>:<пароль>@<хост>:<порт>/<URL-путь>
В этой записи:
-
схема
-
схема обращения к ресурсу, в большинстве случаев имеется в виду сетевой протокол
-
логин
-
имя пользователя, используемое для доступа к ресурсу
-
пароль
-
пароль, ассоциированный с указанным именем пользователя
-
хост
-
полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста в форме четырёх десятичных чисел, разделённых точками. Числа находятся в интервале от 0 до 255.
-
порт
-
порт хоста для подключения
-
URL-путь
-
уточняющая информация о месте нахождения ресурса (зависит от протокола)
Схемы (протоколы) URL
Общепринятые схемы (протоколы) URL включают:
-
ftp — Протокол передачи файлов FTP
-
http — Протокол передачи гипертекста HTTP
-
gopher — Протокол Gopher
-
mailto — Адрес электронной почты
-
news — Новости Usenet
-
nntp — Новости Usenet через протокол NNTP
-
prospero — Служба каталогов
Prospero Directory Service
-
telnet — Ссылка на интерактивную сессию Telnet
-
wais — База данных системы
WAIS
-
file — Имя локального файла
-
data — Непосредственные данные (Data: URL)
Экзотические схемы URL:
-
afs — Глобальное имя файла в файловой системе
Andrew File System
-
cid — Идентификатор содержимого для частей MIME
-
mid — Идентификатор сообщений для электронной почты
-
mailserver — Доступ к данным с почтовых серверов
-
nfs — Имя файла в сетевой файловой системе NFS
-
tn3270 — Эмуляция интерактивной сессии Telnet 3270
-
z39.50 — Доступ к службам ANSI Z39.50
-
skype — Протокол Skype
-
smsto — Открытие редактора SMS в некоторых мобильных телефонах
Кодирование URL
Появление адресов URL стало существенным нововведением в Интернете.
Однако, с момента его изобретения и по сей день, стандарт URL обладает
серьёзным недостатком — в нём можно использовать только ограниченный
набор символов, даже меньший, нежели
в ASCII: латинские буквы, цифры и лишь некоторые знаки препинания.
В URL также нельзя использовать большинство символов Юникода в чистом их виде. Иными словами, если мы захотим использовать в URL символы кириллицы, или иероглифы, или, скажем, специфические символы французcкого языка, то нам придётся кодировать URL. В русскоязычной Википедии ежедневно приходится видеть пример кодирования URL, поскольку русский язык использует символы кириллицы. Например, строка вида:
http://ru.wikipedia.org/wiki/Микрокредит
кодируется в URL как:
http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0%B8%D1%82
Такое преобразование происходит в два этапа: сначала каждый символ кириллицы кодируется в Юникоде (UTF-8)
в последовательность байтов, а затем каждый байт этой
последовательности, не представляющий из себя в ASCII букву или цифру,
записывается в шестнадцатеричном представлении:
М -> 04 и 1C -> D0 и 9C -> %D0%9C
и -> 04 и 38 -> D0 и B8 -> %D0%B8
к -> 04 и 3A -> D0 и BA -> %D0%BA
р -> 04 и 40 -> D0 и 80 -> %D0%80, и т. д.
Ну и наконец, перед каждым таким шестнадцатеричным кодом байта, согласно спецификации URL, ставится знак процента (%) — отсюда даже возник английский термин «percent-encoding», обозначающий способ кодирования символов в URL и URI.
Иные распространённые, но недопустимые в URL символы кодируются в таком соответствии:
" # $ % & ' * , : ; < > ? [ ^ ` { | } <пробел>
%22 %23 %24 %25 %26 %27 %2a %2c %3a %3b %3c %3e %3f %5b %5e %60 %7b %7c %7d %20
Поскольку такому преобразованию подвергаются буквы всех алфавитов, кроме используемой в английском языке латиницы,
то URL со словами на других языках (даже европейских) утрачивают
способность восприниматься людьми. Это входит в грубое противоречие с
принципом интернационализма, провозглашаемого всеми ведущими организациями Интернета, включая W3C и ISOC. Эту проблему призван решить стандарт IRI (англ.
International Resource Identifier) —
международных идентификаторов ресурсов, в которых можно было бы без
проблем использовать символы Юникода, и которые поэтому не ущемляли бы
права других языков. Хотя заранее сложно сказать, смогут ли когда-либо идентификаторы IRI заменить столь широкоупотребительные URL (и URI в целом).
Инициатива PURL
Ещё один кардинальный недостаток URL состоит в отсутствии гибкости. Ресурсы во Всемирной паутине и Интернете перемещаются, а ссылки
в виде URL остаются, указывая на уже отсутствующие ресурсы. Это
особенно болезненно для электронных библиотек, каталогов и
энциклопедий. Для решения этой проблемы были предложены постоянные
локаторы PURLангл.
Persistent Uniform Resource Locator).
В сущности это те же URL, но они указывают не на конкретное место
расположения ресурса, а на запись в базе данных PURL, где, в свою
очередь, записан уже конкретный URL-адрес ресурса. При обращении к
PURL, сервер находит нужную запись в этой базе данных
и перенаправляет запрос уже на конкретное местоположение ресурса. Если
адрес ресурса меняется, то нет нужды исправлять все бесчисленные ссылки
на него — достаточно лишь изменить запись в БД. К сожалению, это
прекрасное новшество ещё недостаточно популярно и не стандартизировано.
источник: wikipedia.org