Из Википедии, бесплатной энциклопедии
  (Перенаправлено из нормализации URL )
Перейти к навигации Перейти к поиску

Не путать с канонизацией URL .
Типы нормализации URI.

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

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

Процесс нормализации [ править ]

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

Нормализации, сохраняющие семантику [ править ]

Следующие нормализации описаны в RFC 3986 [1] для получения эквивалентных URI:

  • Преобразование троек, закодированных в процентах, в верхний регистр. Шестнадцатеричные цифры в тройке URI с процентным кодированием (например, %3aversus %3A) нечувствительны к регистру и поэтому должны быть нормализованы для использования прописных букв для цифр AF. [2] Пример:
http://example.com/foo%2a → http://example.com/foo%2A
  • Преобразование схемы и хоста в нижний регистр. Компоненты схемы и хоста URI нечувствительны к регистру и поэтому должны быть нормализованы до нижнего регистра. [3] Пример:
HTTP://[email protected]/Foo → http://[email protected]/Foo
  • Расшифровка троек незарезервированных символов, закодированных в процентах. Процентно закодированные тройки URI в диапазонах АЛЬФА ( %41- %5Aи %61- %7A), ЦИФРА ( %30- %39), дефис ( %2D), точка ( %2E), подчеркивание ( %5F) или тильда ( %7E) не требуют процентного кодирования и должны быть декодированы в соответствующие им безоговорочные символы. [4] Пример:
http://example.com/%7Efoo → http://example.com/~foo
  • Удаление точечных сегментов. Точечные сегменты .и ..компонент пути URI должны быть удалены путем применения алгоритма remove_dot_segments [5] к пути, описанному в RFC 3986 . [6] Пример:
http://example.com/foo/./bar/baz/../qux → http://example.com/foo/bar/qux
  • Преобразование пустого пути в путь "/". При наличии компонента полномочий пустой компонент пути должен быть нормализован до компонента пути "/". [7] Пример:
http://example.com → http://example.com/
  • Удаление порта по умолчанию. Пустой компонент порта или порт по умолчанию из URI (порт 80 для httpсхемы) с разделителем «:» должен быть удален. [8] Пример:
http://example.com:80/ → http://example.com/

Нормализации, которые обычно сохраняют семантику [ править ]

Для http и https URI следующие нормализации, перечисленные в RFC 3986, могут привести к эквивалентным URI, но стандарты не гарантируются:

  • Добавление завершающего символа "/" к непустому пути. Каталоги (папки) обозначаются косой чертой в конце и должны быть включены в URI. Пример:
http://example.com/foo → http://example.com/foo/
Однако невозможно узнать, представляет ли компонент пути URI каталог или нет. RFC 3986 отмечает, что если первый URI перенаправляет на второй URI, то это означает, что они эквивалентны.

Нормализации, изменяющие семантику [ править ]

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

http://example.com/default.asp → http://example.com/
http://example.com/a/index.html → http://example.com/a/
  • Удаление фрагмента. Компонент фрагмента URI никогда не виден сервером и иногда может быть удален. Пример:
http://example.com/bar.html#section1 → http://example.com/bar.html
Однако приложения AJAX часто используют значение во фрагменте.
  • Замена IP на доменное имя. Проверьте, соответствует ли IP-адрес доменному имени. Пример:
http://208.77.188.166/ → http://example.com/
Обратная замена редко бывает безопасной из-за виртуальных веб-серверов .
  • Ограничивающие протоколы. Ограничение различных протоколов прикладного уровня . Например, схему «https» можно заменить на «http». Пример:
https://example.com/ → http://example.com/
  • Удаление повторяющихся косых черт Пути, содержащие две смежные косые черты, можно преобразовать в один. Пример:
http://example.com/foo//bar.html → http://example.com/foo/bar.html
  • Удаление или добавление «www» в качестве первой метки домена. Некоторые веб-сайты работают одинаково в двух интернет-доменах: один с наименее значимой меткой «www» и другой, имя которого является результатом исключения наименее значимой метки из имени первого, последний известен как « голый» домен . Например, http://www.example.com/и http://example.com/может получить доступ к тому же веб-сайту. Многие веб-сайты перенаправляют пользователя с www на адрес без www или наоборот. Нормализатор может определить, перенаправляет ли один из этих URI на другой, и соответствующим образом нормализовать все URI. Пример:
http://www.example.com/ → http://example.com/
  • Сортировка параметров запроса. Некоторые веб-страницы используют более одного параметра запроса в URI. Нормализатор может отсортировать параметры в алфавитном порядке (с их значениями) и повторно собрать URI. Пример:
http://example.com/display?lang=en&article=fred → http://example.com/display?article=fred&lang=en
Однако порядок параметров в URI может иметь значение (это не определено стандартом), и веб-сервер может позволить одной и той же переменной появляться несколько раз. [9]
  • Удаление неиспользуемых переменных запроса. Страница может ожидать появления в запросе только определенных параметров; неиспользуемые параметры можно удалить. Пример:
http://example.com/display?id=123&fakefoo=fakebar → http://example.com/display?id=123
Обратите внимание, что параметр без значения не обязательно является неиспользуемым параметром.
  • Удаление параметров запроса по умолчанию. Значение по умолчанию в строке запроса может отображаться одинаково независимо от того, есть оно или нет. Пример:
http://example.com/display?id=&sort=ascending → http://example.com/display
  • Удаление символа "?" когда запрос пуст. Если запрос пуст, знак «?» Может не понадобиться. Пример:
http://example.com/display? → http://example.com/display

Нормализация на основе списков URI [ править ]

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

http://example.com/story?id=xyz

появляется в журнале сканирования несколько раз вместе с

http://example.com/story_xyz

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

Schonfeld et al. (2006) представляют эвристику под названием DustBuster для обнаружения правил DUST (разных URI с похожим текстом), которые могут применяться к спискам URI. Они показали, что как только правильные правила DUST были найдены и применены с помощью алгоритма нормализации, они смогли найти до 68% избыточных URI в списке URI.

См. Также [ править ]

  • Единый указатель ресурсов
  • Идентификатор фрагмента
  • Поисковый робот

Ссылки [ править ]

  1. ^ RFC 3986, раздел 6. Нормализация и сравнение
  2. ^ RFC 3986, раздел 6.2.2.1. Нормализация регистра
  3. ^ RFC 3986, раздел 6.2.2.1. Нормализация регистра
  4. ^ RFC 3986, раздел 6.2.2.3. Нормализация сегмента пути
  5. ^ RFC 3986, 5.2.4. Удалить точечные сегменты
  6. ^ RFC 3986, 6.2.2.3. Нормализация сегмента пути
  7. ^ RFC 3986, раздел 6.2.3. Нормализация на основе схем
  8. ^ RFC 3986, раздел 6.2.3. Нормализация на основе схем
  9. ^ "jQuery 1.4 $ .param демистифицирует" . Бен Альман. 20 декабря 2009 . Проверено 24 августа 2013 года .
  • RFC 3986 - унифицированный идентификатор ресурса (URI): общий синтаксис
  • Санг Хо Ли; Сон Джин Ким и Сок Ху Хонг (2005). О нормализации URL (PDF) . Труды Международной конференции по вычислительной науке и ее приложениям (ICCSA 2005). С. 1076–1085. Архивировано из оригинального (PDF) 18 сентября 2006 года.
  • Ури Шонфельд; Зив Бар-Йосеф и Идит Кейдар (2006). Не лезьте в пыль: разные URL с похожим текстом . Материалы 15-й международной конференции во всемирной паутине . С. 1015–1016.
  • Ури Шонфельд; Зив Бар-Йосеф и Идит Кейдар (2007). Не лезьте в пыль: разные URL с похожим текстом . Материалы 16-й международной конференции по всемирной паутине. С. 111–120.