35. Схема функционирования документальной аипс

46. Универсальный адрес информационных ресурсов ( url)

Единый указатель ресурсов (англ. URL —единообразный локатор (определитель местонахождения) ресурса. Ранее назывался Universal Resource Locator — универсальный локатор ресурса. URL — это стандартизированный способ записи адреса ресурса в сети Интернет.

URL был изобретён Тимом Бернерсом-Ли в 1990 году в стенах Европейского совета по ядерным исследованиям в Женеве, Швейцария. URL стал фундаментальной инновацией в Интернете. Сейчас URL применяется для обозначения адресов почти всех ресурсов Интернета. Сейчас URL позиционируется как часть более общей системы идентификации ресурсов URI, сам термин URL постепенно уступает место более широкому термину URI.

Изначально локатор URL был разработан как система для максимально естественного указания на местонахождения ресурсов в сети. Локатор должен был быть легко расширяемым и использовать лишь ограниченный набор ASCII‐символов (к примеру, пробел никогда не применяется в URL). В связи с этим, возникла следующая традиционная форма записи URL:

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

В этой записи: схема -схема обращения к ресурсу; в большинстве случаев имеется в виду сетевой протокол; логин-имя пользователя, используемое для доступа к ресурсу; пароль -пароль указанного пользователя; хост -полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста в форме четырёх групп десятичных чисел, разделённых точками; числа — целые в интервале от 0 до 255.; порт -порт хоста для подключения; URL-путь -уточняющая информация о месте нахождения ресурса; зависит от протокола.; параметры -строка запроса с передаваемыми на сервер (методом GET) параметрами. Разделитель параметров — знак &.

В составе URL некоторые из указанных компонентов являются необязательными, в зависимости от контекста использования. Например, если нужно сослаться на файл того же узла Интернет, к которому относится HTML-файл, содержащий гиперссылку с данным URL, то можно не указывать протокол и доменное имя узла. Если при этом целевой файл ссылки содержится на том же диске и в той же папке, что и файл, содержащий URL, то можно также не указывать полный путь. Если подразумевается начало HTML-файла, то не указывается якорь. Наконец, если имеется в виду якорная точка в том же HTML-файле, то можно не указывать имя файла и все предшествующие ему компоненты URL.

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

ftp — Протокол передачи файлов FTP

http — Протокол передачи гипертекста HTTP

rtmp — Real Time Messaging Protocol проприетарный протокол потоковой передачи данных, в основном используется для передачи потокового видео и аудиопотоков с веб-камер через интернет.

rtsp — Потоковый протокол реального времени и тд…..

Появление адресов URL стало существенным нововведением в Интернете. Однако с момента его изобретения и по сей день стандарт URL обладает серьёзным недостатком — в нём можно использовать только ограниченный набор символов, даже меньший, нежели в ASCII: латинские буквы, цифры и лишь некоторые знаки препинания. Если мы захотим использовать в URL символы кириллицы, или иероглифы, или, скажем, специфические символы французского языка, то нужные нам символы должны быть перекодированы особым образом.

Ещё один кардинальный недостаток URL состоит в отсутствии гибкости. Ресурсы во Всемирной паутине и Интернете перемещаются, а ссылки в виде URL остаются, указывая на уже отсутствующие ресурсы. Это особенно болезненно для электронных библиотек, каталогов и энциклопедий. Для решения этой проблемы были предложены постоянные локаторы PURL (англ. Persistent Uniform Resource Locator). В сущности это те же URL, но они указывают не на конкретное место расположения ресурса, а на запись в базе данных PURL, где, в свою очередь, записан уже конкретный URL‐адрес ресурса. При обращении к PURL сервер находит нужную запись в этой базе данных и перенаправляет запрос уже на конкретное местоположение ресурса. Если адрес ресурса меняется, то нет нужды исправлять все бесчисленные ссылки на него — достаточно лишь изменить запись в БД. В настоящий момент эта идея не стандартизирована и не имеет широкого распространения.