Нормализация URL

Нормализа́ция URL — процесс, при котором URL приводится к единообразному виду. Цель процесса нормализации заключается в преобразовании URL в нормализованный вид, с тем, чтобы определить эквивалентность двух синтаксически различных URL-адресов.^[1]

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

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

Процесс нормализации

Нормализации, сохраняющие исходное написание

Перечисленные ниже способы нормализации описаны в RFC 3986^[2] и приводят к эквивалентным URL.

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

HTTP://www.Example.com/ → http://www.example.com/

Перевод в верхний регистр управляющих конструкций Все символы с процентным указателем (например «%3А») являются регистро-зависимыми и должны быть переведены в верхний регистр. Например:

http://www.example.com/a%c2%b1b → http://www.example.com/a%C2%B1b

Перекодировка управляющих конструкций в явные символы. Для связанности процентные конструкции переводятся в понятные символы (Альфа (%41-%5A и %61-%7A), Цифровые (%30-%39), дефис (%2D), точка (%2E), подчёркивание (%5F), или тильда (%7E) не должны создаваться URI поставщиками и когда находятся такие URI с процентными конструкциями, то они должны быть переведены в символы.^[3] Например:

http://www.example.com/%7Eusername/ → http://www.example.com/~username/

Удаление порта́ по умолчанию. Порт по умолчанию (порт 80 для протокола http) может быть удалён из URL. Например:

http://www.example.com:80/bar.html → http://www.example.com/bar.html

Нормализация с частичным сохранением исходного написания

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

Добавление конечной косой черты. Демонстрация каталога при помощи конечной косой черты, включённой в состав URL. Например:

http://www.example.com/alice → http://www.example.com/alice/

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

Удаление сегментов-точек. Сегменты «..» и «.» могут быть удалены из URL, согласно алгоритму, описанному в RFC 3986 (или похожему). Например:

http://www.example.com/../a/b/../c/./d.html → http://www.example.com/a/c/d.html

Нормализации, изменяющие написание

Применяются следующие способы нормализации, приводящие к различному написанию URL, ведущих на один ресурс:

Удаление головного индекса. Например:

http://www.example.com/default.asp → http://www.example.com/

http://www.example.com/a/index.html → http://www.example.com/a/

Удаление фрагментов. Фрагмент URL^[англ.] никогда не виден на сервере и может быть удален. Например:

http://www.example.com/bar.html#section1 → http://www.example.com/bar.html

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

Замена IP адреса именем доме́на. Проверка, есть ли для IP-адреса доменное имя. Например:

http://208.77.188.166/ → http://www.example.com/

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

Сокращение идентификаторов протоколов. Различные протоколы прикладного уровня, например, https, могут быть переведены в http. Например:

https://www.example.com/ → http://www.example.com/

Удаление дублированных слешей Два соседних слеша в пути можно преобразовать в один. Например:

http://www.example.com/foo//bar.html → http://www.example.com/foo/bar.html

Удаление или добавление «www» как элемента верхнего доменного уровня. Некоторые сайты оперируют двумя интернет-доменами. Например http://example.com/ и http://www.example.com/ могут вести на один ресурс. Многие веб-сайты перенаправляют пользователя с www на не-www адрес или наоборот. Алгоритмы нормализации могут определить эти перенаправления и соответствующим образом преобразовать URL. Например:

http://www.example.com/ → http://example.com/

Сортировка параметров запросов. Некоторые веб страницы используют более чем один параметр в URL. Алгоритмы нормализации могут отсортировать параметры в алфавитном порядке (с сохранением их значений) и пересоздать URL. Например:

http://www.example.com/display?lang=en&article=fred → http://www.example.com/display?article=fred&lang=en

Однако порядок параметров в URL может быть значимым (это не определяется стандартами) и веб сервер может позволять переменным появляться несколько раз.^[4]

Удаление неиспользуемых переменных в запросе. Страница может ожидать только определённые параметры и неиспользуемые параметры можно удалить. Например:

http://www.example.com/display?id=123&fakefoo=fakebar → http://www.example.com/display?id=123

Параметр без значения не означает что параметр не используется.

Удаление параметров запроса по умолчанию. Значение параметров по умолчанию в строке запроса могут показывать одинаковый результат, даже если они не будут указаны. Например:

http://www.example.com/display?id=&sort=ascending → http://www.example.com/display

Удаление «?» при пустом запросе. Когда запрос пустой, то символ «?», возможно, не нужен. Например:

http://www.example.com/display? → http://www.example.com/display

Нормализация, основанная на списках URL

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

http://foo.org/story?id=xyz

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

http://foo.org/story_xyz

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

Сконфелд и соавторы в 2006 году^[5] представили эвристическую систему DustBuster, которая позволяет обнаружить DUST (different URLs with similar text, различные URL с похожим текстом), это правила которые могут быть применены к URL спискам. Они показали, что как только были найдены нужные правила по DUST и применены к нормализующим алгоритмам, они показали способность к поиску до 68 % избыточных URL-адресов в списках URL.

См. также

Поисковый робот

Примечания

↑ RFC3986, 2005, Section 6, p. 38.
↑ RFC3986, 2005.
↑ RFC3986, 2005, Section 2.3.
↑ Ben, 2009.
↑ DUST2006, 2006, pp. 1015-1016.

Литература

Network Working Group. RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax. — WWW, 2005. — 61 с.
Gautam Pant, Padmini Srinivasan, and Filippo Menczer. Crawling the Web (англ.). — 2004.
Uri Schonfeld, Ziv Bar-Yossef, and Idit Keidar. Do not crawl in the dust: different URLs with similar text (англ.). — 2006.
Uri Schonfeld, Ziv Bar-Yossef, and Idit Keidar. Do not crawl in the dust: different URLs with similar text (англ.). — 2007.
Ben Alman. jQuery 1.4 $.param demystified (англ.). — 2009.

[RFC_3986-1] RFC3986, 2005, Section 6, p. 38.

[_852fb78df94ff5ef-2] RFC3986, 2005.

[RFC_3986_Section_2.3-3] RFC3986, 2005, Section 2.3.

[_e985fcaecc52b749-4] Ben, 2009.

[_af570870da7864db-5] DUST2006, 2006, pp. 1015-1016.

[1]

[2]

[3]

[4]

[5]