Url адрес - что это такое, из каких частей состоит, как выглядит, его структура

Авторизация

В URL также можно включить логин и пароль.
Браузер кодирует эти данные в формат Base64 и посылает в виде заголовка.
Base64 используется только для того, чтобы можно было передавать запрещенные в заголовках символы. Он никак не скрывает логин и пароль.
Это было проблемой, особенно до распространения SSL. Любой человек, который следит за вашим соединением, мог с легкостью увидеть пароль. Предлагали много альтернатив, в том числе Kerberos, который был и остается популярным протоколом безопасности.
Как и с другими примерами нашей истории, простую базовую авторизацию было проще всего реализовать разработчикам браузеров (Mosaic). Так базовая авторизация стала первым и единственным решением до тех пор, пока разработчики не получили инструменты для создания собственных систем аутентификации.

URI and URL

The difference between them is straightforward after knowing their definitions:

Uniform Resource Identifier (URI) − a sequence of characters that allows the complete identification of any abstract or physical resource
Uniform Resource Locator (URL) − a subset of URI that, in addition to identifying where a resource is available, describes the primary mechanism to access it

Now we can conclude that every URL is a URI, but the opposite is not true, as we’ll see later.

2.1. Syntax

Every URI, regardless if it’s a URL or not, follows a particular form:

Where each part is described as follows:

scheme − for URLs, is the name of the protocol used to access the resource, for other URIs, is a name that refers to a specification for assigning identifiers within that scheme
authority − an optional part comprised of user authentication information, a host and an optional port
path − it serves to identify a resource within the scope of its scheme and authority
query − additional data that, along with the path, serves to identify a resource. For URLs, this is the query string
fragment − an optional identifier to a specific part of the resource

To easily identify if a particular URI is also a URL, we can check its scheme. Every URL has to start with any of these schemes: ftp, http, https, gopher, mailto, news, nntp, telnet, wais, file, or prospero. If it doesn’t start with it, then it’s not a URL.

Now that we know the syntax, let’s look at some examples. Here is a list of URIs, where only the first three are URLs:

Зачем нужна нормализация URL-ов

Нормализация — это процесс модификации и стандартизации URL-адресов. Она помогает устранить дубликаты и предотвратить индексацию дублированных страниц поисковиками. Идея в том, чтобы все URL-ы были оформлены универсально. Например:

Ссылку на «/contacts.html» можно подвести под формат http://www.website.com/contacts.html
Ссылку HTTP://WWW.WEBSITE.COM/contacts.html следует нормализовать до http://www.website.com/contacts.html
Ссылку с косой чертой (/) https://www.example.com/trip/ можно переформатировать под URL без завершающей косой черты: https://www.example.com/trip
URL с двойной косой чертой http://www.example.com//path можно привести в порядок, используя одну косую черту: http://www.example.compath

Вебмастера также используют редиректы (перенаправления) для нормализации URL-ов и предотвращения дублей страниц, которые могут возникать из-за:

ссылки с www и без префикса
HTTP и HTTPS

Как устроен URL

Структура URL была впервые определена сэром Тимом Бернерсом-Ли — парнем, который создал Интернет и первый веб-браузер — в 1994 году. URL-адреса по существу объединяют идею доменных имен с идеей использования пути к файлу для идентификации конкретного структура папок и файлов. Таким образом, это похоже на использование пути типа C: \ Documents \ Personal \ myfile.txt в Windows, но с некоторыми дополнительными вещами в начале, чтобы помочь найти нужный сервер в Интернете, где этот путь существует, и протокол, используемый для доступа к Информация.

URL состоит из нескольких разных частей. Взять, к примеру, базовый URL-адрес, подобный показанному на рисунке ниже.

Этот простой URL разбит на два основных компонента: схема и полномочия.

Протоколы URL

Первая часть URL — это протокол, по которому нужно производить соединение. Самый распространенный протокол это http. Это простой протокол для передачи документов, который Тим Бернерс-Ли разработал специально для сети. Это был не единственный вариант. Некоторые считали, что нужно использовать Gopher. Gopher был разработан специально для отправки структурированных данных, по аналогии со структурой файлового дерева.
Например, при запросе на /Cars можно получить такой ответ:

1Chevy Camaro             /Archives/cars/cc     gopher.cars.com     70
iThe Camero is a classic  fake                  (NULL)              0
iAmerican Muscle car      fake                  (NULL)              0
1Ferrari 451              /Factbook/ferrari/451  gopher.ferrari.net 70

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

Первым популярным протоколом был FTP. Его создали в 1971 году для получения списков и скачивания файлов на удаленных машинах. Gopher был логическим продолжением этой идеи, так как он предлагал похожий листинг, но также включал механизмы получения мета-информации о записях. Это означает, что его можно было использовать и для других задач, вроде ленты новостей или простой базы данных. Однако, ему не хватало свободы и простоты, которые характеризуют HTTP и HTML.

Главное меню протокола Gopher

HTTP — это очень простой протокол, особенно по сравнению с альтернативами вроде FTP или даже HTTP/2, популярность которого сегодня растет. Во-первых, HTTP полностью текстовый, в нем не используются бинарные элементы (которые могли бы значительно улучшить производительность). Тим Бернерс-Ли правильно решил, что текстовый формат позволит поколениям программистов легче разрабатывать и отлаживать приложения, использующие HTTP.Формально, длина URL не ограничена, но браузеры имеют ограничения по длине URL. Не рекомендуется использовать URL длиной более 2048 символов, так как Microsoft Internet Explorer имеет именно такое ограничение.

HTTP также не делает никаких допущений по поводу содержания. Несмотря на то, что он был разработан специально для передачи HTML, он позволяет указать тип содержания (с помощью MIME Content-Type, который был новым изобретением в свое время). Сам протокол довольно прост.

Запрос:

GET /index.html HTTP/1.1
Host: www.example.com

Возможный ответ:

 HTTP/1.1 200 OK
 Date: Mon, 23 May 2005 22:38:34 GMT
 Content-Type: text/html; charset=utf-8
 Content-Encoding: UTF-8
 Content-Length: 138
 Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
 Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
 ETag: "3f80f-1b6-3e1cb03b"
 Accept-Ranges: bytes
 Connection: close

 <html>
   <head>
     <title>An Example Page</title>
   </head>
   <body>
     Hello World, this is a very simple HTML document.
   </body>
 </html>

В основе сети лежит IP, протокол интернета. IP отвечает за передачу маленького пакета данных (около 1500 байтов) от одного компьютера другому. Поверх этого — TCP, который отвечает за передачу более крупных блоков данных вроде целых документов или файлов. TCP осуществляет гарантированную доставку с помощью множества IP-пакетов. Поверх этого живет протокол вроде HTTP или FTP, который указывает, какой формат данных использовать для пересылки с помощью TCP (или UDP или другого протокола) чтобы передать осмысленные и понятные данные.
Можно сделать свой протокол, если захочется, собирая байты из сообщений TCP как угодно. Единственное требование заключается в том, чтобы получатель говорил на том же языке. Поэтому принято стандартизировать эти протоколы.

Формирование оптимальной структуры URL для разных типов страниц

Страница раздела/категории. Здесь всё просто, так как после домена сразу идет страница раздела/категории: https://site.ua/category1/.
Страница подкатегории. Рассмотрим два часто используемых варианта:

повторять структуру сайта: https://site.ua/category1/subcategory1/subcategory2/subcategory3/;

убирать промежуточные папки в URL-адресе: https://site.ua/category1/subcategory3/;

Страница карточки товара.

всё также сохранять иерархию страниц, добавляя в URL карточку товара: https://site.ua/category1/subcategory1/subcategory2/product/

Преимущества:

можно показать поисковым роботам структуру сайта и его содержание, что положительно скажется на индексации;
можно отслеживать трафик в аналитике, так как видно, с какого раздела/категории пришел пользователь;
пользователи сразу понимают, в каком разделе сайта они находятся — им проще ориентироваться по сайту.

Недостатки:

длинный URL уменьшает вес ключевых слов в веб-адресе;
в некоторых CMS-системах нет возможности создавать дополнительные разделы/подкатегории;
велика вероятность появления дублей страниц. Например, один товар может находиться в двух категориях. Это приводит к появлению дублей страниц. Например iPhone XS может находиться сразу в нескольких разделах: https://site.com.ua/smarfony/iphonexs/; https://site.com.ua/smarfony/apple/iphonexs/.

Ещё вариант — не привязывать карточку товара к определенной категории и хранить всё в корне сайта: https://site.ua/product/.

Преимущества:

товары не закреплены за страницами определенных категорий, что исключает возможность появления дублей страниц;
увеличение веса ключевых слов в URL на определённом разделе;
оптимальная длина веб-адреса, за счет исключения промежуточных категорий/подкатегорий.

Недостатки:

не в каждой системе управления контентом есть возможность убирать ненужные для URL папки;
нет возможности отслеживать трафик в аналитике: так товар не будет закреплен за конкретным разделом/категорией.

Второй рекомендую в том случае, когда товар может относиться к разным категориям. Товары не будут закреплены за категориями и таким образом можно решить проблему появления дублей страниц.

О том, как формировать структуру URL для страниц фильтров, можно прочитать в блоге.

Что представляют собой части или элементы «унифицированного указателя ресурса»? Примеры

В Uniform Resource Locator, как и во всех вычислениях, есть четко определенные и подробные части . Каждый из них выполняет важную функцию в схеме, в которой вы ничего не можете извлечь из этой структуры, поскольку каждая из этих частей соединяется со следующей.

Далее мы подробно рассмотрим, что представляет собой каждый из этих разделов в структуре, и назовем его в том порядке, в котором они указаны в URL:

HTTP (протокол передачи гипертекста)

Между сервером, на котором размещен веб-сайт, который мы хотим видеть, и браузером, который у нас есть, существует протокол связи, в котором определены правила , так что между нашим браузером и этим Сервер может эффективно общаться друг с другом.

Вы заметили, что в некоторых URL-адресах появляется «https», то есть в конце добавляется «s». Это означает, что протокол, с которым мы работаем, безопасен .

Бары наклонены вправо

Необходимо уточнить, что две полосы должны быть наклонены вправо (//) , поскольку в противном случае они не будут работать, и связь между браузером и сервером не будет найдена. Они служат для уведомления нас об адресе, который мы хотим, чтобы сервер связывался с нашим компьютером.

Субдомен

Наиболее распространенным среди поддоменов является www ( W orld W ide W eb). это набор протоколов, которые используются для организации в компьютерной системе. Существуют адреса, в которых этот поддомен не отображается, что не создает никаких проблем при взаимодействии с сервером.

Index.html

Теперь пришло время сообщить серверу , какой файл мы хотим видеть или с которым мы взаимодействуем (вот что обычно называют доменом веб-сайта). Его также можно записать как « default.html » или « index.htm ».

Расширение TLD является последней частью домена, и нам показано, что это за URL. В качестве примеров можно привести общие расширения верхнего уровня, такие как «.com » или « .net », вы можете найти географические расширения « .es . »(Из Испании) или« ru »(из России) или связаны с образованием« .edu ».

Эта часть URL-адреса сообщает серверу, какую часть страницы мы хотим видеть на наших экранах.

Tag

Он связан с символом « # » и служит для указания определенного порядка на странице каталога, которую мы попросили увидеть сервер.

Мы надеемся, что этот пост помог вам, и не стесняйтесь, когда вы видите эти фразы синим цветом, которые выглядят вне контекста того, что мы читаем

Поддерживаемые схемы

HTTPS: схема HTTPS () поддерживается для всех URI перенаправления на базе протокола HTTP.

HTTP: схема HTTP () поддерживается только для URI перенаправления localhost и используется исключительно на этапах локальной разработки и тестирования приложения.

Пример URI перенаправления	Срок действия
	Допустимо
	Допустимо
	Допустимо
	Недопустимо
	Допустимо
	Допустимо

Исключения для localhost

В соответствии с разделами RFC 8252 и , для URI перенаправления с замыканием на себя (localhost) действуют два особых правила:

Схемы URI допустимы, поскольку перенаправление никогда не покидает устройство. Таким образом, приемлемыми являются оба этих URI:
Из-за временного характера диапазонов портов, часто используемых собственными приложениями, компонент порта (например, или ) при сопоставлении URI перенаправления игнорируется. В результате все эти URI считаются эквивалентными:

С точки зрения разработки это означает несколько моментов:

Не регистрируйте несколько URI перенаправления, если в них различается только порт

Сервер входа будет произвольным образом выбирать один из них и использовать связанные с этим URI параметры (например, в зависимости от того, относится ли это перенаправление к типу , , или ).
Это особенно важно, если вы планируете использовать в одном зарегистрированном приложении разные потоки проверки подлинности (например, и выдачу кода авторизации, и неявный поток). Чтобы связать с каждым URI перенаправления правильные параметры ответа, сервер входа должен иметь возможность различать эти URI, что невозможно, если различается только порт.

Чтобы зарегистрировать несколько URI перенаправления по адресу localhost для тестирования различных потоков в процессе разработки, используйте для них разный компонент пути

Например, не эквивалентно .

IPv6-адрес замыкания на себя () в настоящее время не поддерживается.

Выбор 127.0.0.1 вместо localhost

Чтобы работу приложения не нарушали неправильно настроенные брандмауэры или переименованные сетевые интерфейсы, используйте в URI перенаправления IP-адрес замыкания на себя в виде вместо . Например, .

При этом текстовое поле URI перенаправления на портал Azure нельзя использовать для добавления URI замыкания на себя со схемой :

Чтобы добавить URI перенаправления, использующий схему с -адресом замыкания на себя, в настоящее время необходимо изменить атрибут .

Пути, Запросы и Фрагменты

Есть три дополнительных части URL, которые вы можете увидеть после авторитетной части: пути, запросы и фрагменты. Вот как это работает.

Путь

Раздел авторизации URL-адреса приводит ваш браузер (или любое другое приложение) к нужному серверу в сети. Следующий путь, который работает точно так же, как путь в Windows, macOS или Linux, приводит вас к нужной папке или файлу на этом сервере. Путь предваряется косой чертой, и между каждым каталогом и подкаталогом есть косая черта, например:

  www.example.com/folder/subfolder/filename.html

Последний фрагмент — это имя файла, который открывается при доступе к сайту. Хотя вы можете не видеть его в адресной строке, это не значит, что его там нет. Некоторые языки, используемые для создания веб-страниц, скрывают имя файла и расширение, которое вы просматриваете. Это облегчает запоминание и ввод URL-адреса и делает его более понятным.

запрос

Часть запроса URL используется для идентификации вещей, которые не являются частью структуры строгого пути. Чаще всего вы увидите, что они используются, когда вы выполняете поиск или когда веб-страница доставляет данные через форму. Разделу запроса предшествует знак вопроса и он идет после пути (или после имени хоста, если путь не указан).

В качестве примера возьмем следующий URL, который мы искали в Amazon по ключевым словам «wi-fi extender»:

  https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=wi-fi+extender

Форма поиска передавала информацию поисковику Amazon. После знака вопроса видно, что в запросе есть две части: URL-адрес для поиска (это часть «url = search-alias% 3Daps & field») и ключевые слова, которые мы ввели (это «ключевые слова = wi-fi +»). удлинитель »).

Это довольно простой пример, и вы часто будете видеть URL с дополнительными (и более сложными) переменными. Например, вот URL, когда мы искали в Google ключевое слово «»:

  https://www.google.com/search?q=&rlz=1C1GCEA_enUS751US751&oq=&aqs=chrome..69i57j69i60l4j0.1839j1j4&sourceid=chrome&ie=UTF-8

Как видите, там есть другая информация. В этом случае вы можете видеть, что есть дополнительная информация, указывающая язык поиска, используемый нами браузер (Chrome) и даже номер версии браузера.

Фрагмент

Последний компонент URL, который вы можете увидеть, называется фрагментом. Фрагменту предшествует знак хеша (#), который используется для указания определенного местоположения на веб-странице. При кодировании веб-страницы дизайнеры могут создавать привязки для определенного текста, такого как заголовки. Когда в конце URL-адреса используется правильный фрагмент, ваш браузер загрузит страницу, а затем перейдет к этой привязке. Якоря и URL-адреса с фрагментами часто используются для создания таблиц содержимого на веб-страницах, чтобы упростить навигацию.

Вот пример. Страница Википедии в эпоху Возрождения является довольно длинным документом и разбита на 11 разделов, каждый из которых состоит из нескольких подразделов. Но у каждого заголовка на странице есть привязка, и оглавление в верхней части статьи содержит ссылки, которые позволяют переходить к различным разделам. Эти ссылки работают путем включения фрагментов.

Вы также можете использовать эти фрагменты непосредственно в адресной строке или в качестве общих ссылок. Скажем, например, вы хотели показать кому-то раздел этой страницы, который охватывает Россию. Вы можете просто отправить им эту ссылку:

  https://en.wikipedia.org/wiki/Renaissance#Russia

Та часть «#Russia» в конце URL-адреса переходит прямо в этот раздел после загрузки страницы.

Итак, у вас есть это — больше, чем вы, вероятно, когда-либо хотели знать о том, как работают URL-адреса.

Изображение предоставлено: Павел Хорази / Shutterstock

Использует

URL-адреса были созданы, чтобы указать веб-браузерам с помощью нотации (отсюда и прилагательное «униформа»), как получить доступ ко всем ресурсам Интернета .

Гиперссылки

Каждая гиперссылка в сети состоит из URL-адреса указанного ресурса, вставленного с определенным синтаксисом в исходный документ (или в программу, или в пользовательский интерфейс), который содержит его, чтобы указать местоположение другого ресурса (документа) или фрагмент ресурса (целевой якорь в этом другом документе, который также может быть самим собой). При активации гиперссылки веб-браузер может отображать свой URL-адрес в строке состояния (см. «Адресную строку» ниже).

Гиперссылка также может быть построена за пределами самого документа, в базе данных, ссылаясь на все пары (исходный URL, целевой URL) между активируемой зоной исходного документа и целевым якорем в документе (который может быть таким же, как исходный документ, содержащий активируемую зону).

Гиперссылку также можно создать в обратном порядке, вставив URL-адрес исходной зоны в целевой документ.

Адресная строка

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

Если среда позволяет, можно также найти URL-адрес, соответствующий ссылке, наведя указатель мыши на изображение или соответствующий текст. Затем URL-адрес может быть представлен в строке состояния или информационном пузыре.

В последних версиях некоторых браузеров, таких как Google Chrome , в адресной строке больше не отображается фактический полный URL-адрес. Протокол (например, http или https) или префикс «www» можно скрыть, потому что он неявный.

История навигации

Веб-браузеры хранят историю посещенных URL-адресов. Это позволяет им распознавать и отличным образом представлять гиперссылки на уже использованные ресурсы.

Любимые страницы

Веб-браузеру нужно только сохранить URL-адрес ресурса, чтобы создать список избранного (или ). Когда заголовок ресурса существует, браузеры также сохраняют его, что позволяет отображать заголовок страницы, а не ее URL-адрес.

Форматы URL

Транслитерация

Для обозначения названий статей обычно используют транслитерацию. Такие адреса легко читаются и понятны для восприятия пользователей.

По такому адресу сразу можно судить, какое содержимое вы увидите на странице. Поисковые системы легко распознают в подобных адресах ключевые слова, что также оказывает положительное влияние на SEO. Если в URL используется транслитерация, становится четко видна структура сайта и, чтобы попасть в нужный раздел, пользователь просто может стереть в адресной строке часть адреса.

Латиница

Латинские URL представляют собой адреса, переведенные на английский язык. Например, вместо «/novosti/» в адресе будет значиться «/news/».

Такой формат УРЛ часто используется для обозначения веб-страниц категорий и рубрик. Этот вариант считается универсальным, так как легко воспринимается пользователями и без труда обрабатывается поисковыми роботами.

Кириллические URL

Такой формат URL чаще всего применяют в кириллических доменах или когда часть адреса не очень длинная.

К их преимуществам относятся:

удобство и простота запоминания;
достаточное количество свободных доменов из-за невысокой популярности кириллицы;
возможность использования ключевых слов в УРЛ.

Однако кириллические URL имеют существенный недостаток: при копировании такого адреса и вставки его в сообщение для отправки кому-либо или вставки в текстовый редактор, вы получите непонятный набор знаков, наподобие:

https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0

Это объясняется тем, что запись URL-адресов возможна только определенными символами из разрешенного набора, а символы кириллицы в него не входят. Поэтому адрес, в котором используется кириллица, шифруется, хотя при этом ссылка все равно будет работать.

К минусам кириллических УРЛов можно отнести и трудность для восприятия зарубежными пользователями, привыкшими к латинским символам, а также сложности при чтении адресов этого формата поисковыми роботами (такие URL приходится переводить в понятный для робота вид).

Дальнейшее чтение [ править ]

Гарольд, Эллиотт Расти (2004). XML 1.1 Библия (Третье изд.). Wiley Publishing . п. 291. ISBN. 978-0-7645-4986-1.
Хансен, Тони; Харди, Тед (июнь 2015 г.). Талер, Дэйв (ред.). «Рекомендации и процедуры регистрации для схем URI» . Страницы запроса комментариев (RFC) Ietf — Тест . Инженерная группа Интернета . ISSN 2070-1721 .
Моррисон, Майкл Уэйн (2006). «Час 5: Использование пространств имен ». Самс научитесь XML . Самс Паблишинг . п. 91.
Группа интересов по планированию URI, W3C / IETF (21 сентября 2001 г.). «URI, URL-адреса и URN: пояснения и рекомендации 1.0» . Проверено 27 июля 2009 .
«О связывании альтернативных представлений для открытия и публикации» . Консорциум World Wide Web . 2006 . Проверено 3 апреля 2012 .
Брей, Тим ; Холландер, Дэйв; Обыватель, Андрей; Тобин, Ричард, ред. (16 августа 2006 г.). «Пространства имен в XML 1.1 (второе издание)» . Консорциум World Wide Web . 2.2 Использование URI в качестве имен пространств имен . Проверено 31 августа 2015 .
Айерс, Дэнни; Фёлькель, Макс (2008-12-03). Зауэрманн, Лео; Cyganiak, Ричард (ред.). «Классные URI для семантической сети» . Консорциум World Wide Web . Проверено 3 апреля 2012 .
Брей, Тим ; Холландер, Дэйв; Обыватель, Андрей; Тобин, Ричард; Томпсон, Генри С., ред. (2009-12-08). «Пространства имен в XML 1.0 (третье издание)» . Консорциум World Wide Web . 2.2 Использование URI в качестве имен пространств имен . Проверено 31 августа 2015 .
Бернерс-Ли, Тим ; Коннолли, Дэниел «Дэн» (ноябрь 1995 г.). «Язык разметки гипертекста — 2.0» . Инженерная группа Интернета . Проверено 13 сентября 2015 .
Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (август 1998). Универсальные идентификаторы ресурсов (URI): общий синтаксис . Инженерная группа Интернета . DOI : 10,17487 / RFC2396 . RFC 2396 . Проверено 31 августа 2015 .
Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (январь 2005 г.). Универсальные идентификаторы ресурсов (URI): общий синтаксис . Инженерная группа Интернета . DOI : 10,17487 / RFC3986 . RFC 3986 . Проверено 31 августа 2015 .
Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (январь 2005 г.). Унифицированные идентификаторы ресурсов (URI): Общий синтаксис, раздел 3, Компоненты синтаксиса . Инженерная группа Интернета . DOI : 10,17487 / RFC3986 . RFC 3986 . Проверено 31 августа 2015 .
Лоуренс, Эрик (2014-03-06). «Арканы браузера: литералы IP в URL-адресах» . IEInternals . Microsoft . Проверено 25 апреля 2016 .

3 ответа

URL — Единый указатель ресурсов

Содержит информацию о том, как извлечь ресурс из своего местоположения. Например:

(относительный URL-адрес, полезен только в контексте другого URL-адреса)

URL-адреса всегда начинаются с протокола () и обычно содержат информацию, такую как имя сетевого хоста () и часто путь к документу (). URL-адреса могут содержать параметры запроса и идентификаторы фрагментов.

URN — Единое имя ресурса

Определяет ресурс уникальным и постоянным именем. Обычно он начинается с префикса Например:

, чтобы идентифицировать книгу по ее номеру ISBN.
глобально уникальный идентификатор
— пространство имен XML, которое идентифицирует документ как тип книги.

URN могут идентифицировать идеи и концепции. Они не ограничиваются идентификацией документов. Когда URN действительно представляет документ, его можно преобразовать в URL-адрес с помощью «resolver». Затем документ можно загрузить с URL-адреса.

URI — Единый идентификатор ресурса

URI включают URL, URN и другие способы идентификации ресурса.

Примером URI, который не является ни URL-адресом, ни URN, будет URI данных таких как . Это не URL или URN, потому что URI содержит данные. Он не называет его и не указывает, как его найти по сети.

Существуют также единые ссылки ресурсов (URC), которые указывают на метаданные о документе, а не на сам документ. Примером URC будет идентификатор для просмотра исходного кода веб-страницы: . URC — это другой тип URI, который не является ни URL, ни URN.

Я слышал, что больше не должен указывать URL-адрес, почему?

Спецификация W3 для HTML говорит, что может содержать URI, а не только URL-адрес. Вы должны иметь возможность вводить URN, например . Затем ваш браузер будет разрешать этот URN URL-адресу и загружать книгу для вас.

Но разве W3C теперь не говорит, что URL-адреса и URI — это одно и то же?

Да. W3C понял, что в этом есть путаница. Они выпустили документ по разъяснению URI , в котором говорится, что теперь можно использовать термины URL и URI взаимозаменяемо (для обозначения URI). Теперь нецелесообразно строго сегментировать URI для разных типов, таких как URL, URN и URC.

Может ли URI быть как URL, так и URN?

Определение URN теперь более слабое, чем указано выше. последние RFC на URI говорит, что любой URI теперь может быть URN (независимо от того, начинается с ), если у него есть «свойства имени». То есть: он глобально уникален и настойчив, даже когда ресурс перестает существовать или становится недоступным. Пример: URI, используемые в доктринах HTML, такие как . Этот URI будет продолжать называть переходный тип документа HTML4, даже если страница на веб-сайте w3.org была удалена.

Я думаю, что эти статьи достаточно хорошо объясняют. Чтобы ответить на ваш вопрос — все этого URL-адреса:

Каждый бит его — и т. д. имеет свое собственное имя:

http: это схема
www — это субдомен
bernzilla.com — это домен
com — это домен верхнего уровня или TLD
(там может быть папка или путь, например, /dir/item.php, но нет)
item.php — это страница или имя файла с расширением php
id = 100 — строка запроса

Я вижу, что, учитывая эту диаграмму из Википедии, почему вы спрашиваете. Эта диаграмма говорит, что существует два типа URI — URL и URN, а нечеткий бит в середине — это то, что может быть и то и другое.

Неверно, что указанный вами URL-адрес состоит из URL-адреса и части URN.

— это URL и URI.

В основном URI — это надмножество URL-адресов и URN. Также существует некоторое совпадение между URL-адресами и URN.

Таким образом, любой URL-адрес является URI, любой URN является URI, но не каждый URI является URL-адресом.

Пути, запросы и фрагменты

Есть три дополнительные части URL-адреса, которые Вы можете увидеть после части полномочий: пути, запросы и фрагменты. Вот как они работают.

Путь

Раздел полномочий URL-адреса получает Ваш браузер (или любое другое приложение) на нужный сервер в сети. Следующий путь, который работает так же, как путь в Windows, macOS или Linux, попадает в нужную папку или файл на этом сервере. Пути предшествует косая черта, и между каждым каталогом и подкаталогом есть косая черта, например:

www.example.com/folder/subfolder/filename.html

Последняя часть — это имя файла, который открывается при доступе к веб-сайту. Хотя Вы не видите его в адресной строке, это не значит, что его нет. Некоторые языки, используемые для создания веб-страниц, скрывают имя файла и расширение, которое Вы просматриваете. Это упрощает запоминание и ввод URL-адреса и дает ему более чистый вид.

Запрос

Часть запроса URL-адреса используется для идентификации вещей, которые не являются частью строгой структуры пути. Чаще всего Вы увидите, что они используются при выполнении поиска или когда веб-страница передает данные через форму. Перед частью запроса предшествует знак вопроса и приходит после пути (или после имени хоста, если путь не включен).

В качестве примера возьмем этот URL-адрес, который был представлен, когда мы искали на aliexpress по ключевому слову «wi-fi»:

https://ru.aliexpress.com/wholesale?SearchText=wifi

Форма поиска передала информацию поисковой системе aliexpress. После вопросительного знака Вы можете увидеть, что в запросе есть две части: URL-адрес для поиска (это часть «wholesale?») и ключевые слова, которые мы набрали (это «SearchText=wifi»).

Это довольно простой пример, и Вы часто увидите URL-адреса с дополнительными (и более сложными) переменными. Например, вот URL, когда мы искали в Google по ключевому слову «guidepc»:

https://www.google.ru/search?q=guidepc&oq=guidepc&aqs=chrome..69i57j69i60l5.359j0j7&sourceid=chrome&ie=UTF-8

Как Вы можете видеть, там есть какая-то другая информация. В этом случае Вы можете увидеть, что есть дополнительная информация, указывающая язык поиска, браузер, который мы использовали (Chrome), и даже номер версии браузера.

Фрагмент

Конечный компонент URL-адреса, который Вы можете увидеть, называется фрагментом. Фрагменту предшествует хэш-метка (#) и используется для указания определенного местоположения на веб-странице. При кодировании веб-страницы разработчики могут создавать привязки для определенного текста, например заголовки. Когда соответствующий фрагмент используется в конце URL-адреса, Ваш браузер загрузит страницу, а затем перейдет к этому якорю. Якоря и URL-адреса с фрагментами часто используются для создания таблиц контента на веб-страницах, чтобы упростить навигацию.

Вот пример. Страница Википедии о ренессансе — довольно длинный документ, и он разбит примерно на 14 разделов, каждый из которых имеет несколько подразделов. Но каждый заголовок на странице содержит привязку, а оглавление в верхней части статьи содержит ссылки, которые позволяют перейти к различным разделам. Эти ссылки работают, включая фрагменты.

Вы также можете использовать эти фрагменты непосредственно в своей адресной строке или в качестве разделяемых ссылок. Скажем, например, Вы хотели показать кому-то раздел этой страницы, который содержим информацию о науке. Вы можете просто отправить им эту ссылку:

https://ru.wikipedia.org/wiki/Возрождение#Наука

Часть «#Наука» в конце URL-адреса перемещается прямо в этот раздел после загрузки страницы.

Итак, теперь Вы знаете больше, чем когда-либо хотели узнать о том, как работают URL-адреса.