3.2.2. Хост
Подкомпонент власти хоста идентифицируется литералом IP
заключенный в квадратные скобки, адрес IPv4 в точках
десятичная форма или зарегистрированное имя. Подкомпонент хоста
нечувствительны. присутствие субкомпонента хоста в URI не
подразумевает, что схема требует доступа к данному хосту на
Интернет. Во многих случаях синтаксис хоста используется только ради
повторное использование существующего процесса регистрации, созданного и развернутого для
DNS, таким образом получая глобально уникальное имя без затрат на
развертывание другого реестра. Однако такое использование имеет свои собственные
расходы: право собственности на доменное имя может меняться со временем по причинам, не
ожидается производителем URI. В других случаях данные в пределах
Компонент хоста идентифицирует зарегистрированное имя, которое не имеет ничего общего
с интернет-хостом. Мы используем имя «хост» для правила ABNF
потому что это его самая распространенная цель, а не единственная цель.
host = IP-literal / IPv4address / reg-name
Правило синтаксиса для хоста неоднозначно, потому что оно не полностью
различать адрес IPv4 и имя рег. Чтобы
устраняя неоднозначность синтаксиса, мы применяем алгоритм "first-match-wins": если
хост соответствует правилу для IPv4-адреса, тогда его следует считать
IPv4-адрес буквальный, а не рег-имя. Хотя хост
без учета регистра, производители и нормализаторы должны использовать строчные
зарегистрированные имена и шестнадцатеричные адреса для единообразия,
при этом используются только заглавные буквы для процентного кодирования.
Хост, идентифицируемый буквенным адресом интернет-протокола, версия 6
[RFC3513] или более поздней версии, отличается литералом IP
в квадратных скобках ("[" и "]"). Это единственное место, где
В синтаксисе URI разрешены квадратные скобки. В
ожидание будущих, пока еще не определенных форматов буквальных IP-адресов,
реализация может использовать необязательный флаг версии, чтобы указать такой
форматировать явно, а не полагаться на эвристическое определение.
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
Флаг версии не указывает версию IP; скорее это
указывает на будущие версии буквального формата. В качестве таких,
реализации не должны предоставлять флаг версии для существующего
Формы буквенных адресов IPv4 и IPv6 описаны ниже. Если URI
содержащий IP-литерал, который начинается с "v" (без учета регистра),
указывает на наличие флага версии, разыменовывается
приложение, которое не знает значения этого флага версии, то
приложение должно вернуть соответствующую ошибку для "адреса
механизм не поддерживается ".
Хост, идентифицируемый буквенным адресом IPv6, представлен внутри
квадратные скобки без флага предыдущей версии. АБНФ предоставил
вот перевод текстового определения литерала IPv6
адрес указан в [RFC3513]. Этот синтаксис не поддерживает IPv6
идентификаторы зоны адресации в области.
128-битный адрес IPv6 делится на восемь 16-битных частей. Каждый кусок
численно представлен в шестнадцатеричном формате без учета регистра, используя
до четырех шестнадцатеричных цифр (допускаются начальные нули). Восемь
закодированные части даны самыми значимыми первыми, разделенными двоеточием
персонажи. По выбору, наименее значимые две части могут вместо
быть представленным в текстовом формате адреса IPv4. Последовательность одного или
более последовательные нулевые 16-битные фрагменты в адресе могут быть
исключены все их цифры и оставлены ровно две подряд
Колоны на своем месте, чтобы отметить исключение.
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
ls32 = ( h16 ":" h16 ) / IPv4address
; least-significant 32 bits of address
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
Хост, идентифицируемый буквенным адресом IPv4, представлен в десятичном виде с разделительными точками (последовательность из четырех десятичных чисел в диапазоне от 0 до 255, разделенных "."), Как описано в [RFC1123] со ссылкой на [RFC0952].Обратите внимание, что другие формы точечной нотации могут интерпретироваться на некоторых платформах, как описано в Разделе 7.4, но только грамматическая точка из четырех октетов допускается этой грамматикой.
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
Хост, идентифицируемыйЗарегистрированное имя - это последовательность символов, обычно предназначенная для поиска в локально определенном реестре хоста или имени службы, хотя для семантики, специфичной для схемы URI, может потребоваться использование конкретного реестра (или таблицы фиксированных имен).Наиболее распространенным механизмом регистрации имен является система доменных имен (DNS).Зарегистрированное имя, предназначенное для поиска в DNS, использует синтаксис, определенный в Разделе 3.5 [RFC1034] и Разделе 2.1 [RFC1123].Такое имя состоит из последовательности меток домена, разделенных символом «.», Каждая метка домена начинается и заканчивается буквенно-цифровым символом и, возможно, также содержит символы «-».За самой правой доменной меткой полного доменного имени в DNS может следовать одно «.»и должно быть, если необходимо различать полное имя домена и некоторый локальный домен.
reg-name = *( unreserved / pct-encoded / sub-delims )
Если схема URI определяет значение по умолчанию для хоста, то это значение по умолчанию применяется, когда подкомпонент хоста не определен или когдазарегистрированное имя пусто (нулевая длина).Например, схема URI «file» определена таким образом, что никакие права доступа, пустой хост и localhost не означают машину конечного пользователя, тогда как схема http считает недостающие права доступа или пустой хост недействительными.
Эта спецификация не требует конкретной технологии поиска зарегистрированного имени и, следовательно, не ограничивает синтаксис имени за пределами того, что необходимо для совместимости.Вместо этого он делегирует вопрос о соответствии синтаксиса зарегистрированного имени операционной системе каждого приложения, выполняющего разрешение URI, и эта операционная система решает, что она позволит для идентификации хоста.Реализация разрешения URI может использовать DNS, таблицы хостов, желтые страницы, NetInfo, WINS или любую другую систему для поиска зарегистрированных имен.Однако для имен URI, имеющих глобальную область видимости, необходима глобальная система именования, такая как полные доменные имена DNS.Производители URI должны использовать имена, соответствующие синтаксису DNS, даже если использование DNS не сразу видно, и должны ограничивать эти имена длиной не более 255 символов.
Синтаксис reg-name разрешает процент-закодированные октеты для представления имен, не зарегистрированных в ASCII, единообразным способом, который не зависит от базовой технологии разрешения имен.Не-ASCII-символы должны сначала кодироваться в соответствии с UTF-8 [STD63], а затем каждый октет соответствующей последовательности UTF-8 должен кодироваться в процентах, чтобы быть представленными в виде символов URI.Приложения, производящие URI, не должны использовать процентное кодирование в хосте, если оно не используется для представления последовательности символов UTF-8.Если зарегистрированное имя не в формате ASCII представляет собой интернационализированное доменное имя, предназначенное для разрешения через DNS, имя должно быть преобразовано в кодировку IDNA [RFC3490] до поиска имени.Производители URI должны предоставить эти зарегистрированные имена в кодировке IDNA, а не в процентном кодировании, если они хотят максимизировать совместимость с устаревшими распознавателями URI.