Содержание

Создание URL-адреса страницы — Commerce | Dynamics 365

Обратная связь

Twitter LinkedIn Facebook Адрес электронной почты

  • Статья
  • Чтение занимает 3 мин

Важно!

Dynamics 365 Retail теперь называется Dynamics 365 Commerce — это универсальное многоканальное решение для электронной коммерции, магазинов и центров обработки вызовов. Дополнительные сведения об этих изменениях см. в разделе Microsoft Dynamics 365 Commerce.

В этой статье рассматриваются основные принципы и процедуры создания URL-адресов страниц на сайте.

Полный, или абсолютный URL-адрес, который указывает на страницу сайта, состоит из различных частей. Например, URL-адрес

https://www.contoso.com/en-us/contactus состоит из следующих частей:

  • https://www.contoso.com— протокол HTTP и домен сайта.
  • /en-us — путь к языку сайта.
  • /contactus — относительный URL-адрес страницы Свяжитесь с нами. Относительный URL-адрес также известен как динамический URL-адрес.

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

Динамический URL-адрес страницы существует как отдельная сущность в среде разработки сайта.

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

Создание URL-адреса страницы

Существуют два способа создания URL-адресов страниц:

  • Автоматически при создании страницы
  • Вручную, со страницы URL-адреса

Создание URL-адреса страницы при создании страницы

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

Примечание

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

Создание URL-адреса страницы вручную

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

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

  1. На странице URL-адреса выберите Создать.
  2. Выберите страницу сайта для связи с URL-адресом.
  3. Введите динамический URL-адрес, затем выберите ОК.

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

Обновление URL-адреса страницы

Чтобы обновить целевую страницу URL-адреса страницы, выполните следующие действия.

  1. На странице URL-адреса выберите URL-адрес для обновления.
  2. В правой панели свойств выберите кнопку с многоточием (…) рядом с полем целевой страницы.
  3. В диалоговом окне выберите другую страницу, затем выберите ОК.
  4. Сохраните и опубликуйте URL-адрес.

Перенаправление URL-адреса страницы

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

Чтобы переадресовать URL-адрес на другой URL-адрес, выполните следующие действия.

  1. На странице URL-адреса выберите URL-адрес для обновления.

  2. В области свойств справа выберите Перенаправить.

  3. Выберите место назначения для перенаправления.

    • Чтобы указать на другую страницу сайта, выберите
      Внутренний URL-адрес      , выберите кнопку с многоточием (…), затем выберите URL-адрес для перенаправления.
    • Чтобы указать на страницу на внешнем сайте, выберите Внешний URL-адрес, затем введите полный URL-адрес для этой страницы. Обязательно включите протокол. Например, введите https://domain.com/new/page. Если URL-адрес уже перенаправляется на внутренний URL-адрес, необходимо выбрать Очистить выбор, прежде чем можно будет ввести внешний URL-адрес.

  4. Выберите тип перенаправления:

    • Постоянное перенаправление (301) — выберите этот параметр, если вы знаете, что содержимое постоянно перемещается и не будет возвращено по предыдущему URL-адресу. Поисковые системы присвоят значение оптимизации поисковой системы (SEO) перенаправляющего URL-адреса URL-адресу, на который производится перенаправление, и обновят запись для отображения нового URL-адреса.
    • Временное перенаправление ( 302) — выберите этот параметр для перенаправления трафика без обновления поисковых систем. Этот подход обычно используется, если содержимое скоро вернется к предыдущему URL-адресу.

  5. Когда все готово к реализации перенаправления, сохраните и опубликуйте URL-адрес.

Дополнительные ресурсы

Настройка навигации по сайту

Добавление новой страницы сайта

Настройка доменного имени

Добавление языков на сайт

Примечание

Каковы ваши предпочтения в отношении языка документации? Пройдите краткий опрос (обратите внимание, что этот опрос представлен на английском языке).

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

Обратная связь

Отправить и просмотреть отзыв по

Этот продукт Эта страница

Просмотреть все отзывы по странице

Настройка URL-адресов сервера отчетов (диспетчер конфигурации) — SQL Server Reporting Services (SSRS)

Twitter LinkedIn Facebook Адрес электронной почты

  • Статья
  • Чтение занимает 4 мин

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

  • При установке стандартной конфигурации URL-адреса создаются автоматически при помощи значений по умолчанию.

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

Определение URL-адреса сервера отчетов

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

ЧастьОписание
Имя узлаIP-адрес позволяет однозначно идентифицировать устройство в сети TCP/IP. Это физический IP-адрес каждого сетевого адаптера, установленного в компьютер. Если IP-адрес указывает на заголовок узла, можно указать заголовок узла. Если сервер отчетов развертывается в сети организации, то можно использовать сетевое имя компьютера.
ПортTCP-порт является конечной точкой в устройстве. Сервер отчетов прослушивает запросы, проходящие через определенный порт.
Виртуальный каталогПорт часто используется несколькими веб-службами или приложениями. Поэтому URL-адрес сервера отчетов всегда содержит виртуальный каталог, соответствующий приложению, которое получает запрос. Уникальное имя виртуального каталога необходимо указать для каждого из приложений служб Reporting Services, прослушивающих один и тот же IP-адрес и порт.
Параметры SSLURL-адреса в службах Reporting Services могут быть настроены для использования существующего TLS/SSL-сертификата, установленного на компьютер ранее. Дополнительные сведения см. в разделе Настройка TLS-соединений для сервера отчетов, работающего в собственном режиме.

URL-адреса по умолчанию

При получении доступа к серверу отчетов или веб-порталу посредством соответствующего URL-адреса этот адрес должен содержать имя узла, а не IP-адрес. В сети TCP/IP IP-адрес приводит к имени узла (или сетевому имени компьютера). Если настройка URL-адресов осуществляется при помощи значений по умолчанию, доступ к веб-службе сервера отчетов должен быть возможен при использовании URL-адресов, в которых в качестве имени узла указано имя компьютера или localhost:

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

ЧастьЗначениеОбъяснение
IP-адресВсе назначенныеСлужба доменных имен в рабочей сети извлекает IP-адрес из имени узла в URL-адресе. При условии, что в заданном URL-адресе определен IP-адрес, запрос, отправленный на определенный узел, всегда достигнет пункта назначения.
Порт80Порт 80 — это стандартный порт компьютера для соединений TCP/IP. Поскольку сервер отчетов прослушивает порт 80, указание номера порта в URL-адресе можно опустить. При использовании другого порта его необходимо указать в URL-адресе.
Виртуальный каталогReportServerОбратите внимание, что в обоих URL-адресах в примере содержится имя виртуального каталога. Если определение URL-адреса не настроено соответствующим образом, имя виртуального каталога приложения всегда должно быть указано в URL-адресе.

Примечание

Базовое URL-резервирование позволяет использовать в URL-адресах любые допустимые имена узлов. Программой настройки служб Reporting Services создается резервирование URL-адреса в файле HTTP.SYS, используя синтаксис, допускающий переход к определенному экземпляру сервера отчетов по нескольким вариантам имени узла. Дополнительные сведения о резервировании URL-адреса см. в разделе Сведения о резервировании и регистрации URL-адресов (диспетчер конфигурации сервера отчетов).

Разрешения для URL-адресов сервера отчетов на стороне сервера

Разрешения для каждой конечной точки URL-адреса предоставляются исключительно учетной записи службы сервера отчетов. Только у этой учетной записи имеется право доступа к запросам, направленным к URL-адресам служб Reporting Services. При настройке идентификатора службы в программе установки или в программе настройки служб Reporting Services для этой учетной записи создаются и обрабатываются ограниченные списки управления доступом на уровне пользователей (DACL). Если учетная запись службы изменена, программой настройки служб Reporting Services обновляются все резервирования URL-адресов, чтобы интегрировать новые сведения об учетной записи. Дополнительные сведения см. в разделе Синтаксис резервирования URL-адресов (диспетчер конфигурации сервера отчетов).

Проверка подлинности клиентских запросов, отправленных на URL-адрес сервера отчетов

По умолчанию в конечных точках URL-адресов поддерживается проверка подлинности Windows. Это модуль безопасности, используемый по умолчанию. При реализации пользовательской проверки или поставщика проверки подлинности с помощью форм необходимо изменить параметры проверки подлинности на сервере отчетов. При необходимости параметры проверки подлинности Windows можно также изменить, чтобы они соответствовали подсистеме проверки подлинности, используемой в сети. Дополнительные сведения см. в статье Authentication with the Report Server.

в этом разделе

Настройка URL-адреса (диспетчер конфигурации сервера отчетов)
В этом разделе содержатся инструкции по настройке и изменению резервирования URL-адресов в программе настройки служб Reporting Services.

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

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

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

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

См. также:

Настройка URL-адреса (диспетчер конфигурации сервера отчетов)

URL-адреса Django · HonKit

Мы собираемся сделать нашу первую веб-страничку — домашнюю страницу твоего блога! Но для начала давай чуть ближе познакомимся с URL-адресами в Django.

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

URL — это просто адрес в интернете. Ты можешь увидеть URL каждый раз, когда посещаешь веб-сайт — он отображается в адресной строке твоего браузера (да, 127.0.0.1:8000 — это URL-адрес! И https://djangogirls.org — тоже URL):

Любая страница в Интернете нуждается в собственном URL-адресе. Таким образом ваше приложение точно знает, что показать пользователю, который открывает конкретный URL-адрес. В Django мы используем так называемый URLconf (англ. URL configuration, конфигурация URL). URLconf — это набор шаблонов, которые Django попробует сравнить с полученным URL, чтобы выбрать правильный метод для отображения (view).

Как URL-адреса работают в Django?

Давай откроем файл mysite/urls.py в нашем редакторе и посмотрим, как он выглядит:

mysite/urls.py

"""mysite URL Configuration
[...]
"""
from django.contrib import admin
from django.urls import path
urlpatterns = [
    path('admin/', admin.site.urls),
]

Как можешь заметить, Django уже кое-что разместил здесь для нас.

Строки, расположенные между тройными кавычками (''' или """), называются docstrings — ты можешь добавить их в начале файла, класса или метода для описания их функциональности. Python будет их игнорировать при запуске приложения.

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

mysite/urls.py

    path('admin/', admin. site.urls),

Таким образом, любому URL-адресу, начинающемуся с admin/, Django будет находить соответствующее view (представление). В этом случае мы охватываем большое количество различных URL-адресов, которые явно не прописаны в этом маленьком файле — так он становится более аккуратным и удобочитаемым.

Твой первый URL-адрес в Django!

Пришло время создать твой первый URL-адрес! Мы хотим, чтобы ‘http://127.0.0.1:8000/’ возвращал домашнюю страничку нашего блога со списком записей в нём.

Мы также хотим сохранить файл mysite/urls.py в максимально аккуратном виде, так что мы импортируем URL-адреса для нашего приложения blog в mysite/urls.py.

Вперёд, добавь строку для импорта blog.urls. Обрати внимание, что здесь мы используем функцию include, поэтому тебе придется импортировать её в строке from django.urls....

Файл mysite/urls.py должен выглядеть следующим образом:

mysite/urls. py

from django.contrib import admin
from django.urls import path, include
urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('blog.urls')),
]

Django теперь будет перенаправлять все запросы ‘http://127.0.0.1:8000/’ к blog.urls и искать там дальнейшие инструкции.

blog.urls

Создай новый пустой файл blog/urls.py. Отлично! Добавь в него следующие две строки:

blog/urls.py

from django.urls import path
from . import views

Так мы импортировали функцию path Django и все views (представления) из приложения blog (у нас их пока нет, но через минуту они появятся!)

После этого мы можем добавить наш первый URL-шаблон:

blog/urls.py

urlpatterns = [
    path('', views.post_list, name='post_list'),
]

Как ты можешь заметить, мы связали view под именем post_list с корневым URL-адресом (''). Этот шаблон URL будет соответствовать пустой строке. Это правильно, потому что для обработчиков URL в Django ‘http://127.0.0.1:8000/’ не является частью URL. Этот шаблон скажет Django, что views.post_list — это правильное направление для запроса к твоему веб-сайту по адресу ‘http://127.0.0.1:8000/’.

Последняя часть name='post_list' — это имя URL, которое будет использовано, чтобы идентифицировать его. Оно может быть таким же, как имя представления (англ. view), а может и чем-то совершенно другим. Мы будем использовать именованные URL позднее в проекте, поэтому важно указывать их имена уже сейчас. Мы также должны попытаться сохранить имена URL-адресов уникальными и легко запоминающимися.

Если сейчас ты попытаешься открыть страницу http://127.0.0.1:8000/ в браузере, то увидишь сообщение о том, что веб-страница недоступна. Это произошло потому, что сервер (помнишь, как мы набирали runserver?) перестал обрабатывать запросы. Чтобы понять почему, открой окно своей командной строки.

В твоей командной строке появилось сообщение об ошибке, но не беспокойся — оно, на самом деле, довольно полезно. Ты можешь прочесть, что не существует атрибута с именем ‘postlist’ — _no attribute ‘post_list’. Это название представления, которое Django пытается найти и использовать, но мы же его ещё не создали. В данный момент раздел /admin/ тоже не будет работать. Не беспокойся, мы этим займёмся.

Если хочешь узнать больше о Django URLconfs, посмотри официальную документацию: https://docs.djangoproject.com/en/2.0/topics/http/urls/

Что такое URL? — Определение из Techopedia

Что означает унифицированный указатель ресурса (URL)?

Унифицированный указатель ресурсов (URL), также известный как универсальный указатель ресурсов, представляет собой адрес ресурса в Интернете и протокол, используемый для доступа к нему.

Указывает на местонахождение веб-ресурса, как почтовый адрес указывает, где человек физически живет — из-за этого URL-адрес часто называют «веб-адресом».

URL-адрес содержит следующую информацию:

  • Протокол, используемый для доступа к ресурсу.

  • Расположение сервера (по IP-адресу или доменному имени).

  • Номер порта на сервере (необязательно).

  • Расположение ресурса в структуре каталогов сервера.

  • Идентификатор фрагмента (необязательно).

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

Techopedia объясняет унифицированный указатель ресурсов (URL)

Пользователи, просматривающие Интернет, используют URL-адреса и используют их, вводя или копируя и вставляя их в адресную строку своего веб-браузера.

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

Все URL-адреса представлены в следующем порядке:

  • Имя схемы.

  • Двоеточие и две косые черты.

  • Расположение сервера.

  • Порт (необязательно) и расположение ресурса на сервере.

  • Идентификатор фрагмента (необязательно).

Итак, формат будет выглядеть так:

схема://местоположение:порт/файл-на-сервере.htm?querystring=1

Это выглядит сложнее, чем есть на самом деле. Наиболее распространенными схемами (протоколами) являются HTTP и HTTPS, которые узнает любой www-пользователь. Расположение сервера обычно представляет собой доменное имя, например Google.com.

Учитывая это, следующие URL гораздо проще понять:

http://www.google.com/default.htm

https://www.google.com/default.htm

что на сервере с адресом «google.com» есть файл с именем default.htm. Один использует обычный HTTP, а другой использует безопасную версию этой схемы.

Два распространенных элемента путаницы в URL-адресах:

«www» не всегда является частью технического протокола. Веб-сайты только начали использовать это, чтобы указать, что пользователь использует World Wide Web. Вот почему, если вы переходите на http://google.com, он перенаправляет на http://www.google.com. Однако то, как настраивается доменное имя, зависит от того, как веб-сервер и сетевые администраторы настраивают его в бэкэнде.

Большинство пользователей выходят в Интернет через веб-браузер, который незаметно вставляет порт 80 в HTTP-соединения. Вот почему, если вы перейдете на http://www.google.com:80, вы увидите тот же веб-сайт, как если бы номер порта отсутствовал. Другой сетевой порт все еще может быть указан для подключения к определенному месту назначения. Вы можете добавить пользовательский ввод, параметры запроса или значения к URL-адресу в зависимости от конфигурации веб-сервера, на котором размещен этот конкретный ресурс.

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

http://www.google.com/some-page?search=hello

Это говорит о том, что для использования протокола HTTP для отправить запрос на веб-ресурс (на google.com по порту 80), передав ресурсу список необходимых входных параметров через набор пар ключ/значение. Ключ — это имя переменной («hello»), а значение — ввод («some-page»).

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

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

Например, фрагмент #Examples в этом URL-адресе перенаправляет пользователя в раздел «Примеры» на странице идентификатора фрагмента в Википедии:

https://en.wikipedia.org/wiki/Fragment_identifier#Examples

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

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

Тиму Бернерсу-Ли и рабочей группе Internet Engineering Task Force приписывают разработку URL в 1994 году. Он официально указан в RFC 1738.

Разница между URL и URI

Разница между URI и URL заключается в том, что URI может быть просто именем ( google.com ) или именем в сочетании с протоколом ( https://google.com ), в то время как URL всегда a имя в сочетании с протоколом.

URI подобен адресу сам по себе или адрес с направлениями, в то время как URL всегда адрес с направлениями .

Все URL-адреса являются URI, но не все URI являются URL-адресами.

Другими словами, URI — это идентификаторы, а URL — это идентификаторы , которые также расскажут вам, как добраться до них .

  • google.com … это URI потому что это только имя ресурса
  • https://google. com … это URL потому что это и имя и способ туда добраться
  1. URL URI и URN
  2. Что следует использовать?
  3. Структуры URL
  1. Давайте пройдем тест
  2. Путаница с RFC
  3. Резюме

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

Примеры

Вот еще примеры URI, URN и URL, которые показывают взаимосвязь. Помните, что URI может быть URN или URL, потому что оба являются подтипами URI.

Имена и адреса технически не являются URI в этом примере, но он иллюстрирует разницу между вещью и тем, как найти эту вещь.

URI URN URL
Имя, имя и местоположение, или и то и другое имя или номер Имя/номер с местоположением
Имя, имя и адрес, или оба имени или адрес. //[email protected]
[email protected] [email protected] mailto://[email protected]
[email protected] ftp.google.com ftp://ftp.google.com

URI, URL и URN

  • Унифицированный идентификатор ресурса ( URI ) — это строка символов, однозначно идентифицирующая имя или ресурс в Интернете. URI идентифицирует ресурс по имени, расположению или по тому и другому . URI имеют две специализации, известные как унифицированный указатель ресурса (URL) и унифицированное имя ресурса ( URN ).

  • Унифицированный указатель ресурса ( URL ) — это тип URI, который указывает не только ресурс, , но как связаться с ним в Интернете — например, http:// , ftp:// или mailto:// .

  • Унифицированное имя ресурса ( URN ) — это тип URI , в котором используется конкретная схема именования urn: — например, urn:isbn:0-486-27557-4 или urn: ИСБН: 0-395-36341-1 .

  • Таким образом, URI или URN похожи на ваше имя, а URL — это конкретный подтип URI , это как ваше имя в сочетании с вашим адресом.

Все URL-адреса являются URI, но не все URI являются URL-адресами.

Выше мы узнали, что URI включают в себя как URN, так и URL-адреса, но давайте рассмотрим это более подробно.

  1. A UR I — это идентификатор определенного ресурса. Примеры: Книги, Документы
  2. A UR L — это специальный тип идентификатора , который также сообщает вам, как получить к нему доступ . Примеры: HTTP, FTP, MAILTO
  3. Если протокол ( https , ftp и т. д.) либо присутствует, либо подразумевается для домена, вы должны называть его URL-адресом , даже если это также URI.

Так что мне использовать?

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

Так что правильно?

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

Ответ заключается в том, что это зависит от того, что обсуждается. Если вы говорите об обычном домене веб-сайта, таком как google.com , лучше использовать URL вместо URI, потому что URL более конкретен.

Обычно лучше быть как можно более конкретным, поэтому URL-адрес лучше, чем URI, даже если оба они технически верны.

Если вы разговариваете, например, с кем-то из Сан-Франциско, и они спрашивают вас, где вы живете, вы не станете говорить им, что живете в Сан-Франциско или в Калифорнии. Вы ответили бы своим соседям, потому что это уровень детализации, о котором они просили.

Технически google.com — это URI, точно так же, как технически вы живете в Калифорнии, но google. com также является URL-адресом, и вы также живете в Сан-Франциско.

Другими словами, в 99% повседневных случаев вы должны использовать URL вместо URI, потому что оба варианта технически верны, но URL более конкретен!

Структуры URL-адресов

URL-адреса также имеют свою особую структуру. В этой структуре у вас есть следующие компоненты:

  1. Схема — протокол, который вы используете для взаимодействия.
  2. Власть, которая является целью, к которой вы обращаетесь. Это разбивается на информацию о пользователе, хосте и порте.
  3. Путь, который является ресурсом, который вы запрашиваете на хосте.
  4. Запрос — параметры, используемые в веб-приложении.
  5. Фрагмент, на который нужно перейти на данной странице.

Схемы могут включать: HTTP, HTTPS, FTP, MAILTO, IRC, FILE и т. д. HTTP и HTTPS обычно используются для доступа к интернет-ресурсам, но они также могут указывать на локальные ресурсы (в сети или на компьютере).

Схема ФАЙЛ ссылается на файл, расположенный на локальном компьютере, и ищет файл по указанному пути. Хост также может включать обозначение порта, которое переопределяет порт по умолчанию для указанного протокола. Например:

https://google.com

…перейдет на хост google.com через порт 443 , потому что 443 является портом по умолчанию для HTTPs . Но если вы укажете порт следующим образом:

https://google.com:9023

… клиент попытается подключиться к порту 9023 , используя вместо этого протокол HTTPS.

Наконец, URL-адреса также имеют параметры запроса и идентификаторы фрагментов.

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

https://google.com/search?s=bing

Это приведет к поиску слова «bing» в функции, называемой поиском в Google.

Фрагменты позволяют перейти к определенной части страницы по URL-адресу, например: » на странице с именем results. html .

Проверка некоторых примеров

Хорошо, давайте рассмотрим несколько примеров и посмотрим, сможете ли вы ответить на вопросы.

Это URI, URL или URN?

www.google.com

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

Это URI, URL или URN?

userstats.html

Ответ: Похоже, что это ресурс внутри URL, но поскольку он не выглядит уникальным ресурсом или предваряемым цифрой 9.0109 urn: префикс , это не формальный URN. Так что это не URN, URL или URI.

Путаница с RFC

Более глубокое объяснение (давайте перейдем к техническим аспектам)

Позвольте мне предупредить вас: это один из самых распространенных NerdFights в истории технологий, и это говорит о многом.

Одним из препятствий на пути к сути вещей является то, что соответствующие RFC чрезвычайно запутаны, запутаны и даже противоречивы. Например, RFC 3986 говорит, что URI может быть именем, локатором или и тем, и другим…

Информационный бюллетень UL: поиск закономерностей в шуме…

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

Мой акцент.

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

RFC 3986, раздел 1.1.3

Но чуть дальше тот же RFC говорит…

Мой акцент.

Сам URI предоставляет только удостоверение личности; доступ к ресурсу не гарантируется и не подразумевается наличием URI .

RFC 3986, раздел 1.2.2

И затем, если вы еще не совсем запутались, там также написано…

Мой акцент.

Каждый URI начинается с имени схемы , как определено в Разделе 3.1, что относится к спецификации для присвоения идентификаторов в этом схема.

RFC 3986, раздел 1.1.1

Далее приведены примеры:

Обратите внимание, что все их примеры имеют схемы.

ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/ c=GB?objectClass?one
mailto:[email protected]
news:comp.infosystems.www.servers.unix
тел:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2

Подождите… что?

Эти три противоречия являются источником всего этого многолетнего спора.

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

Неудивительно, что все в замешательстве!

Причина, по которой интернет спорит об этом уже более десяти лет, заключается в том, что RFC написан плохо.

Спасение практических правил от всего этого

Быть первым в результатах поиска по этой теме означает, что у меня много разговоров.

Итак, учитывая тот факт, что RFC вносит путаницу, а не устраняет ее, что — если вообще что-нибудь — мы можем из них использовать?

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

Все бабочки летают, но не все, что летает, является бабочкой.

  1. Унифицированный идентификатор ресурса (URI) предоставляет простые и расширяемые средства для идентификации ресурса (прямо из RFC 3986). Это просто идентификатор; не переусердствуйте.
  2. В большинстве дебатов на эту тему URI является надмножеством, поэтому вопрос заключается только в том, является ли данный URI формально URL-адресом или нет . Все URL-адреса являются URI, но не все URI являются URL-адресами. В общем, если вы видите http(s)://, это URL.
  3. URI технически требуют схемы (см. выше), но RFC также говорит, что они могут быть именем, локатором или и тем, и другим, так что YOLO! Мой совет всем, кто говорит, что для URI нужна или не нужна схема, — показать им эту статью, потому что это единственное, что я знаю о том, что подчеркивает противоречия в RFC.
  4. Фрагменты типа file.htm на самом деле не являются URN , потому что URN должны использовать специальную запись с urn: в начале.
  5. Малоизвестный раздел RFC 3986 на самом деле напрямую говорит о религиозной части аргумента, и, кажется, говорит, что мы должны говорить URI вместо URL .

RFC 3986 датирован 2005 годом, поэтому, по-видимому, они говорят, что URI является предпочтительным термином после этого момента.

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

RFC 3986, раздел 1. 1.3

Так что это поддержка наименования «URI», но, на мой взгляд, это еще большая поддержка тех, кто говорит: «Хватит искать ответы в RFC 15-летней давности». ».

Это похоже на еще один широко читаемый текст в этом смысле.

Противоречивого контента так много, что некоторые выводы частично подтверждаются.

Резюме

Какой беспорядок. Вот TL;DR…

  1. RFC устарели, плохо написаны, и их не стоит обсуждать, пока они не будут обновлены.
  2. URI — это идентификатор.
  3. URL-адрес — это идентификатор, который сообщает вам, как к нему добраться.
  4. Используйте термин, который лучше всего понятен получателю .

Я бы приветствовал новую версию RFC, которая упрощает и проясняет различие с современными примерами.

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

Лучшее, что я могу сказать вам об этих дебатах, это не переоценивать их. Я ни разу за 20 лет не видел ситуации, когда путаница между URI и URL действительно имела значение.

Ирония в том, что RFC должны устранять путаницу, а не добавлять ее.

Таким образом, несмотря на то, что в RFC есть некоторая прямая поддержка того, что «URI» предпочтительнее, а «URL» кажется наиболее точным для полных адресов со схемами http(s) (поскольку он наиболее специфичен), я решил отдать приоритет Принципу. Ясности общения выше, чем у педантичности нюансов.

Мне потребовалось много времени, чтобы добраться до этого момента.

В результате лично я использую «URL» в большинстве случаев потому что это с меньшей вероятностью вызовет путаницу , но если я слышу, что кто-то использует «URI», я часто сразу же переключаюсь на его использование.

Примечания

  1. 20 февраля 2022 г. — Добавлены дополнительные разделы и более подробные объяснения различий в URL-адресах, URI и URN.
  2. 16 января 2022 г. — Обновлено для краткости, удобочитаемости и ясности.
  3. 3 мая 2019 г. — Я сделал крупное обновление статьи, в том числе исправил некоторые ошибки, которые были у меня в предыдущих версиях. А именно у меня были осколки типа file.html показан как URN, что неверно. Эта версия статьи является лучшей версией, особенно потому, что она полностью исследует конфликтующие формулировки в RFC и то, как мало мы должны обращать внимание на такой старый документ. Тем не менее, я определенно читал и следил за обновлениями.
  4. RFC 3986 Ссылка
  5. Статья в Википедии о ссылке URI

RFC 2732 — Формат буквальных IPv6-адресов в URL-адресах 

 [Поиск] [txt|html|pdf|с опечатками|bibtex] [Tracker] [WG] [ Электронная почта] [Diff1] [Diff2] [Nits]
От: draft-ietf-ipngwg-url-literal-04 Предлагаемый стандарт
Устарело: 3986 Имеются опечатки 
 Сетевая рабочая группа Р. Хинден
Запрос комментариев: 2732 Nokia
Категория: Трек стандартов Б. Карпентер
                                                                   IBM
                                                           Л.  Масинтер
                                                                  АТ&Т
                                                         19 декабря99
               Формат буквальных IPv6-адресов в URL-адресах
Статус этого меморандума
   Этот документ определяет протокол отслеживания стандартов Интернета для
   Интернет-сообщество, а также запросы на обсуждение и предложения по
   улучшения. Пожалуйста, обратитесь к текущему выпуску «Интернет
   Стандарты официальных протоколов» (STD 1) для состояния стандартизации
   и статус этого протокола. Распространение этой памятки не ограничено.
Уведомление об авторских правах
   Авторское право (C) The Internet Society (1999). Все права защищены.
Абстрактный
   Этот документ определяет формат буквальных IPv6-адресов в URL-адресах.
   для реализации в браузерах World Wide Web. Этот формат был
   реализовано в версиях IPv6 нескольких широко распространенных браузеров
   включая Microsoft Internet Explorer, Mozilla и Lynx. Это также
   предназначен для использования в версии IPv6 местоположения службы
   протокол. 
   Этот документ включает обновление общего синтаксиса для Uniform.
   Идентификаторы ресурсов, определенные в RFC 2396 [URL]. Он определяет синтаксис
   для адресов IPv6 и позволяет использовать «[» и «]» в URI.
   явно для этой зарезервированной цели.
1. Введение
   Текстовое представление, определенное для буквальных IPv6-адресов в
   [ARCH] не совместим напрямую с URL-адресами. Оба используют «:» и «.»
   символы в качестве разделителей. Этот документ определяет формат
   буквальные адреса IPv6 в URL-адресах для реализации во всемирной паутине
   браузеры. Цель состоит в том, чтобы иметь формат, который позволяет легко «вырезать» и
   операции "вставки" с минимальным редактированием буквального адреса.
Хинден и др. Трек стандартов [Страница 1] 
RFC 2732 Литеральные адреса IPv6 в URL-адресах, декабрь 1999 г.
   Формат, определенный в этом документе, был реализован в протоколе IPv6.
   версии нескольких широко распространенных браузеров, включая Microsoft
   Internet Explorer, Mozilla и Lynx.  Он также предназначен для использования
   в версии IPv6 протокола определения местоположения службы.
1.1 Требования
   Ключевые слова ДОЛЖЕН, НЕ ДОЛЖЕН, ТРЕБУЕТСЯ, ДОЛЖЕН, НЕ ДОЛЖЕН, ДОЛЖЕН,
   НЕ ДОЛЖЕН, РЕКОМЕНДУЕТСЯ, МОЖЕТ и НЕОБЯЗАТЕЛЬНО, если и где они появляются
   в этом документе, должны интерпретироваться, как описано в [КЛЮЧЕВЫЕ СЛОВА].
   Браузеры World Wide Web ДОЛЖНЫ реализовывать формат литералов IPv6.
   в URL-адресах, определенных в этом документе. Другие типы приложений и
   протоколы, использующие URL-адреса, МОГУТ использовать этот формат.
2. Буквенный формат адреса IPv6 в синтаксисе URL
   Чтобы использовать буквальный IPv6-адрес в URL-адресе, буквальный адрес должен быть
   заключенный в символы «[» и «]». Например, следующее
   буквальные адреса IPv6:
      ФЕДК: BA98:7654:3210:ФЕДК:BA98:7654:3210
      1080:0:0:0:8:800:200C:4171
      3ffe:2a00:100:7031::1
      1080::8:800:200К:417А
      ::192.9.5.5
      ::FFFF:129.144.52.38
      2010:836B:4179::836B:4179
   будет представлено, как в следующих примерах URL:
      http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index. html
      http://[1080:0:0:0:8:800:200C:417A]/index.html
      http://[3ffe:2a00:100:7031::1]
      http://[1080::8:800:200C:417A]/foo
      http://[::192.9.5.5]/ipng
      http://[::FFFF:129.144.52.38]:80/index.html
      http://[2010:836B:4179::836B:4179]
3. Изменения в RFC 2396
   Этот документ обновляет общий синтаксис для универсального ресурса.
   Идентификаторы, определенные в RFC 2396 [URL]. Он определяет синтаксис для IPv6.
   адресов и позволяет явно использовать "[" и "]" в URI
   для этой зарезервированной цели.
Хинден и др. Трек стандартов [Страница 2] 
RFC 2732 Литеральные адреса IPv6 в URL-адресах, декабрь 1999 г.
   Следующие изменения в синтаксисе в RFC 2396 сделаны:
   (1) измените нетерминал «хост», чтобы добавить параметр IPv6:
      хост = имя хоста | IPv4-адрес | IPv6ссылка
      ipv6reference = "[" IPv6-адрес "]"
   где IPv6-адрес определяется как в RFC2373 [ARCH].
   (2) Заменить определение «IPv4-адрес» определением RFC 2373, как
   он правильно определяет IPv4-адрес как состоящий не более чем из трех
   десятичных цифр на сегмент. " | "`"
4. Вопросы безопасности
   Использование этого подхода для представления буквальных IPv6-адресов в URL-адресах
   не вносит каких-либо известных новых проблем безопасности.
5. Соображения IANA
   Никто.
Хинден и др. Трек стандартов [Страница 3] 
RFC 2732 Литеральные адреса IPv6 в URL-адресах, декабрь 1999 г.
6. Адреса авторов
   Роберт М. Хинден
   Нокиа
   313 Фэирчайлд Драйв
   Маунтин-Вью, Калифорния 94043
   США
   Телефон: +1 650 625 2004
   Электронная почта:[email protected]
   Интернет: http://www.iprg.nokia.com/~hinden
   Брайан Э. Карпентер
   IBM
   iCAIR, Люкс 150
   1890 Мейпл-авеню
   Эванстон Ил 60201
   США
   Электронная почта: [email protected]
   Ларри Масинтер
   Лаборатории AT&T
   75 Уиллоу Роуд
   Менло-Парк, Калифорния 94025
   Электронная почта: [email protected]
   Интернет: http://larry.masinter.net
7. Ссылки
   [ARCH] Хинден, Р. и С. Диринг, «Адресация IP версии 6.
              Архитектура», RFC 2373, 19 июля.98.
   [STD-PROC] Браднер, С. , Процесс стандартизации Интернета — редакция 3,
              BCP 9, RFC 2026, октябрь 1996 г.
   [URL] Филдинг Р., Масинтер Л. и Т. Бернерс-Ли, "Униформа
              Идентификаторы ресурсов: общий синтаксис», RFC 2396, август
              1998.
Хинден и др. Трек стандартов [Страница 4] 
 RFC 2732 Литеральные адреса IPv6 в URL-адресах, декабрь 1999 г.
8. Полное заявление об авторских правах
 Авторское право (C) Интернет-сообщество (1999). Все права защищены.
 Этот документ и его переводы могут быть скопированы и предоставлены
 другие и производные работы, которые комментируют или иным образом объясняют это
 или содействовать в его реализации, могут быть подготовлены, скопированы, опубликованы
 и распространяется полностью или частично без ограничения каких-либо
 вид, при условии, что приведенное выше уведомление об авторских правах и этот параграф
 включены во все такие копии и производные работы. Однако это
 сам документ не может быть изменен каким-либо образом, например, путем удаления
 уведомление об авторских правах или ссылки на Internet Society или другие
 Интернет-организациям, за исключением случаев, когда это необходимо для целей
 разработка интернет-стандартов, и в этом случае процедуры для
 авторские права, определенные в процессе Интернет-стандартов, должны быть
 следовала или по мере необходимости переводила его на языки, отличные от
 Английский.
No related posts.