Что значит url: Что такое URL адрес и как с ним работать

Что такое url адрес и как его найти?

Всем привет! Теперь довольно часто мы сталкиваемся с таким понятием, как «url адрес». Но не всегда понимаем о чем идет речь. А ведь это составляющая интернета, без которых невозможна его работа. В этой статье речь и пойдет о том, что такое этот самый url адрес, как его найти, и что он из себя представляет.

Любая страничка в интернете имеет свой уникальный адрес, который необходимо набрать, что бы посетить ее или же переслать товарищу, если хотим поделиться найденной информацией. По сути, URL является параметром такого атрибута, как «href», при помощи которого создаются различные гиперссылки

URL строится аналогично адресу нашего места пребывания: улица, дом, квартира, этаж. Например, протокол HTTPS – это улица, номером дома может служить название сайта, а вот путь непосредственно к определенной странице сайта можно обозначить как квартиру. Аналогичным образом определяются и URL изображения или файла – это то место, где они располагаются.

Аббревиатура URL (Universal Resource Locator) означает – универсальный указатель ресурса. Т.е. – это и есть тот самый адрес сервера, на котором находится искомый ресурс. URL обладает определенной структурой, но об этом чуть позже.

Как это ни странно, но не все пользователи представляют себе, где взять этот самый URL-адрес. А здесь все зависит от того, какой именно URL нам необходимо найти. Если это адрес сайта, то его мы берем в адресной строке браузера.

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

Например, мы просматриваем в ВК записи и наткнулись на интересную картинку. Нам захотелось поделиться ею, отправив ее адрес друзьям (пусть даже не в ВК). Нажав правой кнопкой мыши на картинке откроется окно, где находим «копировать URL картинки».

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

https://sun9-21.userapi.com/c834404/v834404790/1825ec/FVRB1Gcp7zw.jpg

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

Самое интересное, понятие URL появилось в 1990 году в Женеве. «Изобретателем» этого термина стал Тим Бернерс-Ли. Первоначально URL нужен был для обозначения отдельных файлов, их расположения в мировой сети. Впоследствии его стали использовать для обозначения уже всех ресурсов интернета.

Что значит url ссылка на изображение, сайт, канал или видео?

Итак, что такое URL ссылка уже мы определились. Это адрес или ресурса, или файлов в интернете, их место расположение. При помощи URL можно определить, где находится тот или иной объект.

Просматривая на Яндексе картинки, вы можете спокойно найти ее ссылку, нажав правой кнопкой мыши. В открывшемся меню выбираем или «копировать адрес ссылки», или сохранить ее.

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

У каналов, например Ютуб, так же имеются свои адреса. Выяснить его довольно просто. Для начала вы входите в свой аккаунт на сайте youtube.com. Затем, в правом верхнем углу находите значок своего профиля, обычно это или ваше фото, или какая-либо аватарка. Нажав на нее, вы переходите на свою страничку, которая и является URL с идентификатором канала.

Например, youtube.com/channel/UCUZHFZ9jIKrLroW8LcyJEQQ. Это и есть стандартный адрес любого канала, а вот символы, которые идут в конце ссылки являются уникальным идентификатором. У каждого автора канала он свой.

Таким образом, любой URL-адрес любого объекта, будь то сайт или же картинка, видео, аккаунт в ВК или одноклассниках, отображается в адресной строке браузера. Скопировав его, вы сможете или сохранить эту ссылку, или отправить ее своим знакомым.

Какова структура url адреса или запроса?

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

<способ>://<логин>:<пароль>@<хост>:<порт>/< путь>?<параметры>

Что входит в эту структуру? Первая составляющая – это <способ>. Он обозначает, в первую очередь, сетевой протокол или же доступ к интернет ресурсу. Следующая составляющая – это <логин>:<пароль>. Она определяет те параметры, с помощью которых осуществляется доступ к данному ресурсу.

Затем идет <хост>. Это название хоста в системе DNS. Кроме этого, данный параметр может обозначаться еще и как IP-адрес хоста. Следующий параметр – <порт>. Этот параметр имеет отношение к хосту.

Параметр <путь>, в нем заключены сведения о доступе к интернет ресурсу. Данный параметр устанавливается с помощью сетевого протокола. И, наконец, последнее – <параметры>. Это те параметры страницы, которые отвечают за файлы, размещенные внутри определенного ресурса.

Сейчас основополагающим является такой параметр, как URI. Это Uniform Resource Identifier, что означает «Унифицированный идентификатор ресурса». Именно с его помощью можно идентифицировать любой ресурс в интернете. Это и сам сайт, и его файлы. Сюда же входит и адрес вашего электронного почтового ящика.

Этот самый URI состоит URL, который является Унифицированным Указателем Ресурса и URN (Uniform Resource Name), что переводится как Унифицированное Наименование Ресурса.

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

Если говорить об истории создания этих понятий – то это все тот же 1990 год. Правда, развитие  в этом направлении не стоит на месте, в 1998 году выходит уже новая версия URI. Хотя мы и до сих пор используем термин URL, однако еще в 2002 году появилось сообщение, что он устарел и надо использовать вместо него термин URI.

Таким образом, URI – это сегодня наиболее общая система идентификации. Она может включать в себя как оба идентификатора URN и URL, так и каждый из них по отдельности.

Что такое url blacklist

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

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

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

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

Успехов всем!

Автор публикации

0 Комментарии: 1Публикации: 179Регистрация: 02-12-2017

URL адрес — что это такое и зачем он нужен

11 мая, 2020

Автор: Maksim

URL — Uniform Resource Locator является важным элементом всемирной паутины, который позволяет нам ориентироваться на страницах сайтов в интернете.

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

В прошлом материале мы рассмотрели, что такое гипертекст, сегодня мы продолжим тему работы всемирной паутины и разберемся с тем, что это такое УРЛ.

Что такое URL адрес

URL (Урл, Uniform Resource Locator) — это унифицированный указатель веб-ресурса. При помощи которого можно указать на странице вебсайта или документа местонахождение определенного ресурса/сайта или файла при помощи ссылки. Он фиксирует местонахождение — адрес.

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

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

Структура URL адреса

Обычный URL адрес состоит из нескольких частей и разделяются между собой слешами:

1. Протокол: http, https, ftp и т.д. Пишется первым, в начале и указывает по какому протоколу следует обращаться к ресурсу.
2. Доменное имя: адрес ресурса, пишется в середине
3. Полный путь к контенту:

папки и название файла. Пишется в конце, если ссылка ведет просто не на главную страницу.

https:// — протокол сайта
anisim.org — доменное имя
url-adres-chto-eto — название папки/файла в которой находится контент

полностью выглядит так: https://anisim.org/articles/url-adres-chto-eto/

Но, бывают и куда более сложные схемы. Например, с GET параметрами. Полная схема УРЛ на картинке ниже.

Писать URL можно буквами с цифрами. Разрешены только определенные символы, вот некоторые из них: % () ! $ ~ — ‘ _ * +. Все можно посмотреть на сайте W3C — https://www.w3schools.com/tags/ref_urlencode.asp.

URI — что это

URI (Ури, Uniform Resource Identifier) — это унифицированный идентификатор ресурса. При помощи которого можно указать местонахождение ресурса, файла или другого контента при помощи ссылки. Кроме адреса включает в себя еще и местоположение на нем определенного контента / имя. Идентифицирует ресурс, как по его основному адресу, так и по его названию.

На данный момент разницы между URI и URL нет, W3C официально подтвердил, что они взаимозаменяемы и имеют одинаковые понятия, читайте об этом подробнее в следующей главе.

Очень важно об URI — URL — URN

Перед тем, как перейти к следующим главам обязательно прочтите этот материал, т.к. W3C выпустили официальный документ, объясняющий важные моменты по поводу УРЛ.

В W3C решили убрать неразбериху по поводу трактовки этих терминов — URL и URI, и разрешили использовать любой их них, когда имеешь ввиду ссылку на сайт. Т.е. теперь они взаимозаменяемы. Сейчас не нужно строго сегментировать URI на разные типы и все можно называть просто УРЛ. Если вам, кто-то скажет обратное или будет учить другому — дайте им ссылку на официальный документ — https://www.w3.org/TR/uri-clarification/.

URI включает в себя URL и URN, но может быть и совсем без них. К примеру, УРИ данные «data:,Hi%20World». Просто содержит данные и не имеет ни названия, ни местоположения.

Также, любой URI может быть URN при условии, если у него есть свойство названия/имени — даже при условии, если ресурс будет недоступным. Т.е, например, УРИ используемый в HTML для указания его типа: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd. Даже если эта ссылка будет недоступна, URI по-прежнему будет называться XHTML типом документа. Это URN.

И из этого можно сделать вывод, что и URL тоже включает в себя URN. Поэтому, чтобы убрать ВСЮ эту путаницу и приняли решение, что хватит сегментировать URI на типы. Теперь УРЛ и УРИ — это одно и тоже официально и УРН к ним приписывается в тегах ссылки.

URN — что это

URN (Урн, Uniform Resource Name) — это унифицированное имя ресурса. Пишется в УРЛ — urn:данные для идентификации. Но сейчас может быть и простой гиперссылкой. Если гиперссылка имеет свойство имени — это URN.

Как в примере выше веб-ссылка — http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtdимеет имя — «Тип документа XHTML».

В заключение

Как видите все довольно просто. Надеюсь вам был полезен данный материал, и вы узнали для себя много нового и интересного. До новых встреч и стабильного вам серфинга в Веб.

Просто о сложном: что такое URL?

Наверх
  • Рейтинги
  • Обзоры
    • Смартфоны и планшеты
    • Компьютеры и ноутбуки
    • Комплектующие
    • Периферия
    • Фото и видео
    • Аксессуары
    • ТВ и аудио
    • Техника для дома
    • Программы и приложения
  • Новости
  • Советы
    • Покупка
    • Эксплуатация
    • Ремонт
  • Подборки
    • Смартфоны и планшеты
    • Компьютеры
    • Аксессуары
    • ТВ и аудио
    • Фото и видео
    • Программы и приложения
    • Техника для дома

Мой URL — это не ваш URL / Хабр

Когда давным-давно в 1996 году я приступил к работе над программой httpget, предшественницей проекта Curl, я написал свой первый синтаксический анализатор URL. Как раз тогда этот универсальный адрес получил название URL: Uniform Resource Locator (единый указатель ресурсов). Его спецификация была опубликована IETF в 1994 году. Аббревиатура «URL» была затем использована как источник вдохновения для названия инструмента и проекта Curl.

Термин «URL» был позднее изменён; его стали называть URI (Uniform Resource Identifier — единый идентификатор ресурсов), согласно спецификации, опубликованной в 2005 году, однако основное сохранилось: синтаксис для строки, задающей онлайн-ресурс и указывающей протокол для получения этого ресурса. Мы требуем, чтобы curl принимал указатели URL, как определено данной спецификацией RFC 3986. Ниже я расскажу, почему на самом деле это не совсем так.

Был ещё родственный RFC, описывающий IRI: Internationalized Resource Identifier (международный идентификатор ресурсов). IRI, по существу, то же самое, что URI, но IRI позволяют использовать символы, не входящие в ASCII.

Консорциум WHATWG позднее создал свою собственную спецификацию URL, в основном, сведя вместе форматы и идеи от URI и IRI с сильным упором на браузеры (что неудивительно). Одна из объявленных ими целей — «Модернизировать RFC 3986 и RFC 3987 в соответствии с современными реализациями и постепенно вывести их из употребления». Они хотят вернуться к использованию термина «URL», справедливо заявляя, что термины URI и IRI просто запутывают ситуацию и что люди так и не поняли их (или часто даже не знают, что эти термины существуют).

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

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

Вдобавок ко всем этим стандартам и спецификациям, в интерфейсе всех браузеров есть адресная строка (которую часто называют и по-другому), которая позволяет пользователям вводить какие угодно забавные строки и преобразовывает их в URL. Если ввести «http://localhost/%41» в адресную строку, то участок с процентом будет преобразован в «A» (поскольку 41 в шестнадцатеричном исчислении является заглавной буквой A в ASCII), но если ввести «http://localhost/A A«, то фактически в исходящий HTTP-запрос GET будет отправлено «/A%20A» (с пробелом в URL-кодировке). Я говорю об этом, так как люди часто думают, что всё, что можно ввести в эту строку — и есть URL.

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

Так что же такое URL?

Или более конкретно — как мы пишем их? Какой синтаксис используем?

Думаю, одна из самых больших ошибок в спецификации WHATWG (и в ней причина, почему я выступаю против этой спецификации в её текущей форме с твёрдым убеждением, что они неправы) состоит в том, что они полагают, будто только им позволено работать с URL и давать им определение; они ограничивают свое представление об URL исключительно браузерами, HTML и адресными строками. Конечно, WHATWG создан большими компаниями, представляющими браузеры, которые использует почти каждый, а в этих браузерах широко работают указатели URL, но сами URL — явление значительно большее.

Представление об URL, существующее у WHATWG, не слишком широко принимается за пределами браузеров.

Двоеточие-слэш-слэш

Если спросить пользователей — обычных людей без какого-либо особого знания протоколов или сети — о том, что такое URL, то что они ответят? Последовательность «://» (двоеточие-слэш-слэш) была бы в начале списка ответов; несколько лет назад, когда браузеры показывали URL более полно, это было бы еще заметнее. Увидев эту последовательность, мы сразу понимаем, что перед нами именно URL.

Однако давайте отойдём от пользователей и оглядимся — в мире существуют почтовые клиенты, эмуляторы терминалов, текстовые редакторы, Perl-скрипты и многое-многое другое, что способно распознавать URL и работать с ними. Например, открыть URL в браузере, превратить в активную ссылку в сгенерированном HTML и так далее. Огромное количество названных скриптов и программ будет использовать именно последовательность «двоеточие-слэш-слэш» как главный признак.

Спецификация WHATWG говорит, что должен быть как минимум один слэш и что парсер при этом обязан принимать какое угодно количество слэшей. Это значит, что «http:/example.com» и «http:///////////////example.com» — полностью подходящие варианты. RFC 3986 и многие другие с этим не согласны. Ну, действительно, большинство из людей, с которыми я спорил последние несколько дней, даже те, кто работает в вебе, говорит, думает и убеждено, что URL имеет два слэша. Просто посмотрите внимательнее на скриншот результата поиска картинок в Гугл по запросу «URL» выше в этой статье.

Мы просто знаем, что у URL есть два слэша (хотя, да, URL типа file: обычно имеют три слэша, но давайте пока проигнорируем это). Не один. Не три. Два. Но WHATWG с этим не согласен.

«Есть хоть одна настоящая причина принимать более двух слэшей для не-файловых URL?» (спрашиваю я раздраженно у членов WHATWG)

«Факт в том, что это делают все браузеры.»

Спецификация говорит это, потому что браузеры реализовали её именно так.

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

В проекте Curl мы как раз недавно начали обсуждать, как обращаться с указателями URL, имеющими число слэшей, отличное от двух, потому что, оказывается, уже есть серверы, передающие обратно такие URL в заголовке “Location:”, и некоторые браузеры без возражений принимают их. Curl — нет, так же как и большинство из множества других библиотек и инструментов командной строки. Кого нам поддержать?

Пробелы

Символ пробела (код 32 в ASCII, шестнадцатеричный код 0x20) не может быть частью URL. Если требуется отправить его, то следует использовать URL-кодировку, как это делают с любым другим недопустимым символом, который надо сделать частью URL. URL-кодировка — это байтовое значение в шестнадцатеричном исчислении со знаком процента перед ним. Таким образом, «%20» означает пробел. Это также означает, что синтаксический анализатор, например, сканирующий текст на предмет указателей URL, узнаёт, что достиг конца URL, когда он обнаруживает недопустимый символ. Например, пробел.

Браузеры обычно преобразовывают все %20 в своих адресных строках в символ пробела, чтобы ссылки выглядели прилично. При копировании адреса в буфер и вставке его в текстовый редактор мы видим пробелы как %20, что и требуется.

Я не уверен, в этом ли причина, но браузеры также принимают пробелы как часть URL, получая, например, переадресацию в HTTP-ответе. Такие URL передаются от сервера к клиенту в заголовке «Location:». Браузеры без проблем допускают пробелы в них URL, кодируя их в виде %20 и отправляя следующий запрос. Это заставляет curl принимать пробелы в перенаправляемых «URL».

Не-ASCII

Поддержка в URL языков, включающих символы, не входящие в ASCII, конечно, важно, особенно для незападных сообществ, и я согласен, что спецификация IRI никогда не была достаточно хороша. Я лично далёко не эксперт в интернационализации, поэтому я руководствуюсь тем, что слышал от других. Но, конечно, пользователи нелатинских алфавитов и систем печати должны иметь возможность записывать свои «интернет-адреса» в ресурсы и использовать их как ссылки.

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

Для международных доменных имён имя преобразуется в кодировку punycode так, чтобы оно могло быть прочитано обычными серверами DNS, которые ничего не знают об именах в кодировке, отличной от ASCII. Идентификаторы URI не имеют IDN-имён; IRI и URL по версии WHATWG — имеют. Сurl поддерживает IDN-имена хостов.

WHATWG заявляет, что URL могут использовать UTF-8, тогда как URI — только ASCII. Curl не воспринимает не-ASCII-символы в части адреса, задающей путь, но кодирует их процентом в исходящих запросах; это порождает “интересные» побочные эффекты, когда не-ASCII-символы представлены в коде, отличном от UTF-8, что является, например, стандартным для Windows.

Подобно тому, что я написал выше, это приводит к серверам, отправляющим назад не-ASCII-коды в HTTP-заголовках, которые браузеры охотно принимают, и не-браузерам тоже приходится работать с ними.

Стандарта URL не существует

Я не пытался представить полный список проблем или несоответствий — здесь просто некоторая подборка трудностей, с которыми я недавно столкнулся. «URL», выданный в одном месте, конечно, совсем необязательно будет принят или понят в другом месте как «URL».

В наши дни даже curl уже не следует строго ни одной опубликованной спецификации — мы медленно деградируем в угоду “веб-совместимости”.

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

Что такое url адрес.

url адрес

Любой документ в сети Интернет имеет свой адрес. Его имеют веб-страницы, аудио, видео-файлы и любые другие документы, которые могут храниться на компьютере.

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

Этому адресу присвоили название URL (англ. URL — Uniform Resource Locator) единый указатель ресурсов.

Произошло это относительно недавно в 1990 году.

Давайте разберемся, каким образом, согласно этому стандарту нужно указывать адреса к веб-ресурсам.

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

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

Давайте разберемся, что обозначает каждый параметр, который здесь указывается:

Схема – это тот протокол передачи данных, по которому, мы хотим обратиться к ресурсу.

логин и пароль — имя пользователя и пароль, используемые для доступа к ресурсу. Далеко не всегда эти параметры будут использоваться. Например, для доступа к какой-либо веб-странице, по протоколу http – как правило, эти данные не указывают.

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

хост – доменное имя или IP-адрес (ссылки) того ресурса, к которому нужно обратиться.

Порт – уникальный номер, который выделяется тому приложению, которое будет обрабатывать ваш запрос. При работе по протоколу http, чаще всего задается автоматически и равен 80 или 8080.

URL — путь – здесь мы указываем уточняющую информацию о местонахождении ресурса. Зависит от используемого протокола. В случае с протоколом HTTP задается путь с указанием каталогов и подкаталогов, где лежит ресурс.

параметры  — строка запроса с передаваемыми на сервер методом GET параметрами.

Разделитель параметров — знак &.

Пример: ?параметр_1=значение_1&параметр_2=значение_2&параметр3=значение_3

якорь – уникальная строка, набор букв И(ИЛИ) цифр, которая ссылается на определенную уникальную область (раздел) того веб-документа, который вы собираетесь открыть.

Т.е. переходя по url адресу с якорем можно сделать так, чтобы документ открылся не с самого начала, а с конкретного места или раздела.

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

Когда вы хотите просто посмотреть какую-то страницу в Интернете, с помощью своего браузер, то структура url адреса выглядит намного проще:

<схема>:// <хост>/<URL‐путь>

Например, это может быть записано в виде:

http://yandex.ru

Это сделано для того, чтобы упростить жизнь простым рядовым пользователям.  

Что такое URL адрес сайта (страницы) – Что значит (означает) URL адрес

URL (УРЛ, от англ. Uniform Resource Locator ) — указатель размещения сайта в интернете. URL-адрес содержит доменное имя и указание пути к странице, включая название файла этой страницы.

Тим Бернерс-Ли (участник Европейского совета по ядерно-военным проблемам в Женеве) в 1990 году изобрел URL, который на тот период являлся просто адресом размещения файлов в системе.

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

Как много значит URL-адрес сайта в SEO?

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

Яндекс рекомендует делать адреса страниц информативными. Например, https://site.ru/download/prais-list-remont-kvartir.pdf может сказать поисковому роботу, что по данному адресу можно скачать прайс-лист в формате PDF и, скорее всего, эта страница релевантная запросу «прайс-лист на ремонт квартир». Но это не значит, что для качественного продвижения сайта необходимо делать все URL-адреса в виде набора ключевых слов, так как это также может отрицательно сказаться на результатах раскрутки.

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

Выделение URL-адреса в поисковой выдаче

URI — сложно о простом (Часть 1) / Хабр

Привет хабр!

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

«Пфф, ссылки они и в Африке ссылки, чего тут разбираться?» — скажете вы, тогда я задам вопрос:

Что есть что и куда нас приведет?


Если вы не знаете однозначного ответа или вам просто интересно и если вы не боитесь огромного количества трехбуквенных аббревиатур — милости прошу под кат.

Перед тем как начать хотел бы обозначить, что есть пост на схожую тему, в котором все обозначено проще и немного понятнее. Целью же этого поста, я ставлю более глубокое изучение вопроса и сбор информации об URI в одном месте, дабы «не потерять». Ну, почти в одном месте, статья будет разделена на две части
А для удобства бахнем оглавление, которое работает не без особенностей URI, которую мы рассмотрим попозжа, в этой статье.

ОГЛАВЛЕНИЕ

  1. URI
    1.1. Синтаксис
    1.2. Компоненты URI
  2. URL
    2.1. Структура
  3. URN
    3.1. Структура

Ознакомление


1. URI


Унифицированный Идентификатор Ресурса, в простонародье — URI
Самое свежее описание того, чем же все-таки являются эти пресловутые URI датируется январем аж 2005-го, а именно RFC3986, написанный самим Тимом Бёнесом-Ли, родоначальника всеми нами любимого тырнета.
Резюмируя п.1.1 можно сформулировать определение:

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

  • перейдя по http://example.com — мы попадем на http-сервер ресурса идентифицируемого как example.com
  • в то же время ftp://example.com — приведет наc на ftp-сервер того же самого ресурса
  • или например http://localhost/ — URI идентифицирующий саму машину откуда производится доступ

В современном интернете, чаще всего используется две разновидности URIURL и URN.
Основное различие между ними — в задачах:
  • URLUniform Resource Locator, помогает найти какой либо ресурс
  • URNUniform Resource Name, помогает этот ресурс идентифицировать

Упрощая: URL — отвечает на вопрос: «Где и как найти что-то?», URN — отвечает на вопрос: «Как это что-то идентифицировать».
Парочка интересностей про URIМногие из вас замечали, что на разных ресурсах ссылки называют то URL, то URI и, вероятно, становилось интересно — какой же из вариантов правильный?
Дело в том, что URL увидел свет и был документирован в 1990 году, в то время как URI был документирован лишь в 1994 году. И вплоть до 2002 года, до выхода RFC3305, уместными были оба варианта именования, что, порой вносило путаницу.
В п.2 RFC3305 сообщается об устаревании такого термина как URL, применимо к ссылкам, и что отныне верным будет именование URI, с того момента, во всех документах W3C использует термин URI. Исходя из этого, применяя термин URL к соответствующим ссылкам, вы не делаете смысловой ошибки, но делаете ее с точки зрения правильного именования.

Так же примечателен тот момент, что вплоть до выхода RFC2396, в 1997 году, URI расшифровывался как Universal Resource Identifier, что можно увидеть в RFC1630

Обобщая всевозможные варианты, URI имеет следующий вид:

Забегая вперед, стоит отметить, что не все три компоненты являются строго обязательными. Для того чтобы ссылка считалась URI необходимо наличие:

  • либо scheme+authority+path,
  • либо sheme+path,
  • либо только path.
1.1. Синтаксис

Согласно п.2 RFC3986:
URI составлен из ограниченного набора символов, состоящих из цифр, букв и нескольких графических символов, все эти символы вписываются в кодировку US-ASCII (ASCII). Зарезервированное подмножество символов может использоваться, чтобы разграничить компоненты синтаксиса в URI, в то время как остающиеся символы: не зарезервированный набор и включая те зарезервированные символы, которые не действуют как разделители в данной компоненте URI, определяют данные идентификации каждого компонента.

Зарезервированные символы
Зарезервированные символы делятся на два типа:
  • gen-delims, они же «главные разделители», т.е. символы, разделяющие URI на крупные компоненты.
     ":", "/", "?", "#", "[", "]", "@"
  • sub-delims, они же «под разделители» — символы, которые разделяют текущую крупную компоненту, на более мелкие составляющие, для каждой компоненты они свои, вот список самых распространенных:
     "!", "$", "&", "'", "(", ")", "*", "+", ",", ";", "="

Не зарезервированные символы
Исходя из предыдущего пункта, не зарезервированные символы — символы, не входящие в gen-delims, а так же не значимые для данной компоненты sub-delims. Но в общем случае это:
ALPHA, DIGIT, "-", ".", "_", "~"
Для данного случая, согласно ABNF:
ALPHA — любая буква верхнего и нижнего регистров кодировки ASCII (в regExp [A-Za-z])
DIGIT — любая цифра (в regExp [0-9])
HEXDIG — шестнадцатиричная цифра (в regExp [0-9A-F])

Процентное кодирование
В случае, если используются символы выходящие за пределы кодировки ASCII используется механизм т.н. «Процентного кодирования«. Так же он применяется для передачи зарезервированных символов в составе данных. Зарезервированные символы, по правилам, не участвуют в процентном кодировании.
Процентно-кодированный символ представляет из себя символьный триплет, состоящий из знака «%» и следующих за ним двух шестнадцатиричных чисел:
pct-encoded = "%" HEXDIG HEXDIG
Т.о., %20, например, означает пробел.
1.2. Компоненты URI

Следующий список содержит описания крупных компонент, составляющих URI:
  • Scheme (схема)
    Каждый URI начинается с имени схемы, которое относится к спецификации для присвоения идентификаторов в этой схеме. Также, синтаксис URI — объединенная и расширяемая система именования, причем, спецификация каждой схемы может далее ограничить синтаксис и семантику идентификаторов, использующих эту схему.
    Название схемы обязательно начинается с буквы и далее может быть продолжено любым количеством разрешенных символов.
    Разрешенные символы для схемы:
    ALPHA, DIGIT, "+", "-", "."
  • Authority (честно говоря, не знаю как перевести слово на русский, без потери смысла)
    Компонента authority начинается с двойного слеша(//) и заканчивается следующим слешем(/), знаком вопроса(?) или октоторпом(#)(да-да, «решеточка» зовется именно так=)) или концом URI
    Authority состоит из:
    [ userinfo "@" ] host [ ":" port ]
    где в квадратных скобках опциональные компоненты
    Каждую из подкомпонент, отдельно, мы рассмотрим чуть позже, в разделе посвященном URL.
  • Path (Путь)
    Компонента пути содержит данные, обычно, организованные в иерархической форме, которые, вместе с данными в неиерархическом компоненте запроса (Query), служит, чтобы идентифицировать ресурс в рамках схемы URI и authority (если таковая компонента указана).
    Путь начинается со слеша(/) и заканчивается знаком вопроса(?), октоторпом(#) или концом URI
    Разрешенные символы для пути:
    Не зарезервированные, процентно-кодированные, sub-delims, ":", "@"
  • Query (Запрос)
    Компонента запроса содержит данные, организованные в неиерархической форме, которые, вместе с данными в иерархическом компоненте пути (Path), служит, чтобы идентифицировать ресурс в рамках схемы URI и authority (если таковая компонента указана).
    Запрос начинается с первого знака вопроса(?) и заканчивается октоторпом(#) или концом URI
    Разрешенные символы для запроса:
    Не зарезервированные, процентно-кодированные, sub-delims, ":", "@", "/", "?"
    В запросе чаще всего передаются данные в формате key=value (ключ=значение), значение рекомендуется передавать в процентно-кодированном виде, обусловлено это тем, что в значении может встретиться символ «&», который используется для разделения пар ключ-значение, в результате появления такого артефакта дальнейшая последовательность пар ключ-значение может быть нарушена.
  • Fragment (Фрагмент)
    Компонента фрагмент позволяет осуществить косвенную идентификацию вторичного ресурса по отношению к первому.
    Семантика фрагмента никак не ограничена, фрагмент начинается октоторпом(#) и заканчивается концом URI, при этом может состоять из абсолютно любого набора символов.
    Примером применения фрагментов является оглавление данной статьи. Оно состоит из относительных ссылок
    <a href="#someanchor"></a>
    а по статье, в определенных местах, раскиданы т.н. «якоря» — теги
    <anchor>someanchor</anchor>

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

    <anchor>
    на экране.

На этом, пожалуй, знакомство с URI можно закончить и начать углубляться в отдельные подвиды URI, а именно

2. URL


Стандарт URL документирован в RFC1738.
Из п.2:
URL используются, чтобы определить местоположение ресурсов, обеспечивая абстрактную идентификацию расположения ресурса. Определив местоположение ресурса, система может выполнить множество операций на ресурсе, которые могут быть характеризованы такими словами как ‘доступ’, ‘обновление’, ‘замена’, ‘поиск атрибутов’. В целом только метод доступа должен быть определен для любой схемы URL.
Т. о.: URL призван решить широкий ряд задач, начиная с получения и заканчивая изменением данных на ресурсе, а обязательным параметром для получения доступа — является метод, т. е. любой полноценный (абсолютный) URL можно свести к виду:
<scheme>:<часть свойственная этой схеме>

2.1. Структура

В целом, URL имеет схожую структуру, для всех схем, хотя для каждой отдельно взятой схемы, структура может отличаться от общего шаблона.
Графически ее можно выразить в следующем виде:

И вот, примерно на этом моменте, можно рассмотреть различия между абсолютными (absolute) и относительными (relative) URL, данные определения распространяются не только на URL, но и на URI в целом.

  • Относительная ссылка использует иерархический синтаксис, чтобы выразить ссылку URI относительно пространства имен другого иерархического URI.
    Относительные ссылки так же делятся на несколько подвидов:
    • Ссылка сетевого пути
      Имеет вид:
      //<authority> <path> [<query>] [<fragment>]
      Такой тип ссылок применяется не часто, смысл заключается в переходе по указанной ссылке с применением текущей схемы.
      Т. е.: находясь, например на http://example.com и перейдя по ссылке //domain.com — мы попадем на http://domain.com
      А в случае если перейдем по той же ссылке с ftp://example.com, то попадем на ftp://domain.com
    • Ссылка абсолютного пути
      Имеет вид:
      /<path> [<query>] [<fragment>]
      На этот раз мы останемся в пределах текущего хоста, но попадем по пути path в любом случае, по какому бы пути мы сейчас не находились.
      Т. е.: даже находясь на http://example.com/just/some/long/path и перейдя по ссылке /path, мы попадем на http://example.com/path
    • Ссылка относительного пути
      Имеет вид:
      <path> [<query>] [<fragment>]
      Теперь же, мы будем перемещаться в пределах текущего положения.
      Т. е.: находясь на http://example.com/just/some/long/path и перейдя по ссылке path, мы попадем на http://example.com/just/some/long/path/path
    • Ссылка того же документа
      Фактически это ссылки, состоящие только из фрагментарной части URI, либо же ссылки, у которых все компоненты за исключением фрагментарной совпадают с исходной.
      Т.е. #fragment и http://habrahabr.ru/topic/232385/#fragment являются ссылками того же документа.

  • Абсолютная ссылка — ссылка вида
    <scheme> <authority> [<path>] [<query>] [<fragment>]
    Применяя абсолютные ссылки, мы будем попадать на нужный нам ресурс вне зависимости от того, откуда мы переходим.
    Т. е.: находись мы на http://example.com/just/some/long/path или же на ftp://example.com, перейдя по http://domain.com/path, мы в любом случае попадем на http://domain.com/path

После того, как мы разобрались с тем, что же такое относительные и абсолютные пути — можно отвечать на вопрос заданный в начале поста:
  • http://example.com — откроет http://example.com
  • www.example.com — по-идее должен открыть http://habrahabr.ru/topic/232385/www.example.com, но хабр сам исправляет ссылку, хотя по стандартам www.example.com — ссылка относительного пути
  • //www.example.com — откроет www.example.com со схемой с которой вы просматриваете текущую страницу, т.е. скорее всего будет открыт http://example.com
  • mailto:[email protected] — здесь уже вступают в силу настройки браузера, он предложит вам открыть эту ссылку при помощи почтовой программы и отправить электронное письмо адресату [email protected], а так, это абсолютный URL со схемой mailto

Мы уже рассмотрели крупные компоненты, а теперь давайте углубимся в детали построения URL.
  • Scheme — как говорилось ранее: схема определяет метод доступа к ресурсу. Список актуальных схем можно посмотреть тут.
  • Userinfo — под-компонент authority, использующийся для авторизации пользователя на ресурсе. Состоит из username и необязательного password, от остальной части authority отделяется символом «@«. Не смотря на то, что параметр password указан в спецификации, его использование крайне не рекомендуется, т. к. фактически производится передача пароля к учетной записи username, в незашифрованном виде.
    Разрешенные символы:
    Не зарезервированные, процентно-кодированные, sub-delims, ":"

    Пример можно привести следующий:
    На локалке есть папка test, на которую стоит доступ по паре логин-пароль. То есть, перейдя по http://localhost/test/, я увижу следующее:
    А если я перейду по ссылке http://admin:[email protected]/test/, то процедура авторизации произойдет автоматически, с данными указанными в блоке userinfo:
  • Host — компонент authority, использующийся для определения целевого узла (или ресурса, если угодно, но понятие «узел» будет более точным), который может находиться как в сети интернет, так и вне её, в зависимости от указанной схемы. Данная компонента не чувствительна к регистру.
    Хост может представлять из себя либо IP-адрес, либо регистрационное имя (reg-name) и, опционально, следующий за ними порт(port).
    Предусматривается как поддержка существующих форматов IP-адресов (IPv4, IPv6), так и всевозможных будущих, которые будут описаны впоследствии.
    Регистрационное имя — привычные нам, т. н. доменные имена — последовательность символов, обычно предназначенных для поиска в локально определенном узле или реестре имени службы, хотя специфичная для схемы семантика URI может потребовать, чтобы вместо этого использовался определенный реестр (или фиксированная таблица имен).
    Наиболее распространенный механизм реестра имен — Система Доменных Имен (DNS).
    Доменное имя, используемое для поиска в DNS, состоит из доменных меток, разделенных при помощи «.», каждая доменная метка может содержать следующие символы:
    Не зарезервированные, процентно-кодированные, sub-delims
    Синтаксис регистрационного имени позволяет использование процентно-кодированных символов, для представления не-ASCII символов, в едином порядке, не зависящем от технологии разрешения имен. Символы, не входящие в ASCII, должны быть сначала закодированы в UTF-8, а затем каждый октет UTF-8 последовательности должен быть процентно закодирован.
    В случае, если регистрационное имя с не-ASCII символами представляет собой многоязычное доменное имя, разрешаемое через DNS, оно должно быть преобразовано в кодировку IDNA (RFC3490) до поиска имени и, как следствие, регистраторами доменных имен такие регистрационные имена должны предоставляться в кодировке IDNA.
    Port (Порт) — десятичный номер порта, отделяется от hostname одним двоеточием «:», может состоять только из цифр. Схема может определять порт по-умолчанию, который будет использоваться в случае если порт не указан. Например, для схемы HTTP порт по-умолчанию — 80, что соответствует зарезервированному под неё порту 80/TCP. Тип порта, так же как и назначенный номер порта, определяется схемой.
  • Компоненты Запрос и Фрагмент полностью описаны ранее.

3. URN


Стандарт URN документирован в RFC2141.
Из п.1:
Унифицированные имена ресурсов (URN) предназначены, чтобы служить постоянными, независимыми от расположения, идентификаторами ресурсов и разработаны для упрощения отображения других пространств имен (которые совместно используют свойства URN) в URN-пространство. Таким образом, синтаксис URN обеспечивает средство закодировать символьные данные в форме, которая может быть отправлена посредством существующих протоколов, записана при помощи большинства клавиатур, и т.д.
Т. е., в отличие от URL, который ссылается на како-то место, где хранится документ, URN ссылается на сам документ, и при перемещении документа в другое место ссылка не изменится.
В силу того, что URN концептуально отличается от URL, то и система разрешения имен у него другая — DDDS, которая преобразует URN в URL, по которым можно найти ресурс/объект или что бы то ни было, на что ссылается URN.
3.1. Структура

URN имеет следующий вид:
"urn:" <NID> ":" <NSS>

  • «urn:» — обязательная, регистронезависимая часть URN
  • NID — Namespace Identifier, данная компонента определяет синтаксическую интерпретацию компоненты NSS.
    Минимальная длина — 2 символа, максимальная — 32, разрешенные символы:
    латинские буквы, цифры, "-"
    NID должен начинаться только с буквы или цифры.
    Так же, слово «urn» для NID является зарезервированным, дабы избежать неоднозначности при определении URN в целом.
    Список официально зарегистрированных NID можно посмотреть тут
  • NSS — Namespace Specific String, эта компонента служит непосредственно для передачи каких-либо данных.
    Разрешенные символы:
    латинские буквы, цифры, процентно-кодированные, "(", ")", "+", ",", "-", ".", ":", "=", "@", ";", "$", "_", "!", "*", "'"
    Зарезервированные символы:
    "%", "/", "?", "#"
    Запрещенные символы должны быть процентно-кодированы. Если указанный символ встретится в явном виде, его позиция будет считаться концом URN:
    октеты 0-32 (0-20 hex), "\", """, "&", "<", ">", "[", "]", "^", "`", "{", "|", "}", "~", октеты 127-255 (7F-FF hex)
Самоидентифицирующийся URN
Такие URN содержат в NID название хэш-функции, а в NSS значение хэша, вычисленного для идентифицируемого объекта. Такие ссылки используются в magnet-ссылках и заголовках p2p-сети Gnutela2.
Например, URN из magnet-ссылки с одного торрент-трекера:
magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d...

С теорией все, во второй части рассмотрим, что можно и что нужно делать с URI, если мы их обрабатываем, а именно — нормализация, разбор и т.д.

За сим откланяюсь, спасибо что читали, надеюсь не было скучно, удачи!

90000 What is the meaning of # in URL and how can I use that? 90001 Stack Overflow 90002 90003 Products 90004 90003 Customers 90004 90003 Use cases 90004 90009 90010 90003 Stack Overflow Public questions and answers 90004 90003 Teams Private questions and answers for your team 90004 90003 Enterprise Private self-hosted questions and answers for your enterprise 90004 90003 Jobs Programming and related technical career opportunities 90004 90003 Talent Hire technical talent 90004 90003 Advertising Reach developers worldwide 90004 90009 .90000 What is a URL? — Learn web development 90001 90002 This article discusses Uniform Resource Locators (URLs), explaining what they are and how they’re structured. 90003 90004 Summary 90005 90002 With Hypertext and HTTP, 90007 90008 URL 90009 90010 is one of the key concepts of the Web. It is the mechanism used by browsers to retrieve any published resource on the web. 90003 90002 90007 URL 90010 stands for 90015 Uniform Resource Locator 90016. A URL is nothing more than the address of a given unique resource on the Web.In theory, each valid URL points to a unique resource. Such resources can be an HTML page, a CSS document, an image, etc. In practice, there are some exceptions, the most common being a URL pointing to a resource that no longer exists or that has moved. As the resource represented by the URL and the URL itself are handled by the Web server, it is up to the owner of the web server to carefully manage that resource and its associated URL. 90003 90004 Active Learning 90005 90002 90015 There is no active learning available yet.Please, consider contributing. 90016 90003 90004 Deeper dive 90005 90026 Basics: anatomy of a URL 90027 90002 Here are some examples of URLs: 90003 90030 https://developer.mozilla.org https://developer.mozilla.org/en-US/docs/Learn/ https://developer.mozilla.org/en-US/search?q=URL 90031 90002 Any of those URLs can be typed into your browser’s address bar to tell it to load the associated page (resource). 90003 90002 A URL is composed of different parts, some mandatory and others optional.Let’s see the most important parts using the following URL: 90003 90030 http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument 90031 90038 90039 90040 90041 90042 http 90043 is the protocol. The first part of the URL indicates which protocol the browser must use. A protocol is a set method for exchanging or transferring data around a computer network. Usually for websites it is the HTTP protocol or its secured version, HTTPS. The Web requires one of these two, but browsers also know how to handle other protocols such as 90042 mailto: 90043 (to open a mail client) or 90042 ftp: 90043 to handle file transfer, so do not be surprised if you see such protocols.90048 90039 90040 90041 90042 www.example.com 90043 is the domain name. It indicates which Web server is being requested. Alternatively, it is possible to directly use an IP address, but because it is less convenient, it is not often used on the Web. 90048 90039 90040 90041 90042: 80 90043 is the port. It indicates the technical «gate» used to access the resources on the web server. It is usually omitted if the web server uses the standard ports of the HTTP protocol (80 for HTTP and 443 for HTTPS) to grant access to its resources.Otherwise it is mandatory. 90048 90039 90040 90041 90042 /path/to/myfile.html 90043 is the path to the resource on the Web server. In the early days of the Web, a path like this represented a physical file location on the Web server. Nowadays, it is mostly an abstraction handled by Web servers without any physical reality. 90048 90039 90040 90041 90042? Key1 = value1 & key2 = value2 90043 are extra parameters provided to the Web server. Those parameters are a list of key / value pairs separated with the 90042 & 90043 symbol.The Web server can use those parameters to do extra stuff before returning the resource. Each Web server has its own rules regarding parameters, and the only reliable way to know if a specific Web server is handling parameters is by asking the Web server owner. 90048 90039 90040 90041 90042 #SomewhereInTheDocument 90043 is an anchor to another part of the resource itself. An anchor represents a sort of «bookmark» inside the resource, giving the browser the directions to show the content located at that «bookmarked» spot.On an HTML document, for example, the browser will scroll to the point where the anchor is defined; on a video or audio document, the browser will try to go to the time the anchor represents. It is worth noting that the part after the 90007 # 90010, also known as the 90015 90007 fragment identifier 90010, is never sent to the server with the request. 90016 90048 90087 90007 Note: 90010 There are some extra parts and some extra rules regarding URLs, but they are not relevant for regular users or Web developers.Do not worry about this, you do not need to know them to build and use fully functional URLs. 90002 You might think of a URL like a regular postal mail address: the 90015 protocol 90016 represents the postal service you want to use, the 90015 domain name 90016 is the city or town, and the 90015 port 90016 is like the zip code; the 90015 path 90016 represents the building where your mail should be delivered; the 90015 parameters 90016 represent extra information such as the number of the apartment in the building; and, finally, the 90015 anchor 90016 represents the actual person to whom you’ve addressed your mail.90003 90026 How to use URLs 90027 90002 Any URL can be typed right inside the browser’s address bar to get to the resource behind it. But this is only the tip of the iceberg! 90003 90002 The HTML language — which will be discussed later on — makes extensive use of URLs: 90003 90110 90111 to create links to other documents with the 90042 90043 element; 90114 90111 to link a document with its related resources through various elements such as 90042 90043 or 90042