Меню Главная Случайная статья Настройки Нормализация URL Материал из https://ru.wikipedia.org Нормализация URL — процесс, при котором URL приводится к единообразному виду. Цель процесса нормализации заключается в преобразовании URL в нормализованный вид, с тем, чтобы определить эквивалентность двух синтаксически различных URL-адресов.[1] Поисковые системы используют нормализацию URL для того, чтобы снизить индексацию дубликатов страниц и расположить страницы в порядке значимости. Поисковые роботы выполняют нормализацию URL для того, чтобы избежать повторного сканирования ресурса. Браузеры могут выполнять нормализацию, чтобы определить было ли посещение или есть ли страница в кэше. Есть несколько типов нормализации, которые могут быть применены к URL: одни сохраняют исходный адрес, другие — не сохраняют Содержание 1 Процесс нормализации 1.1 Нормализации, сохраняющие исходное написание 1.2 Нормализация с частичным сохранением исходного написания 1.3 Нормализации, изменяющие написание 2 Нормализация, основанная на списках URL 3 См. также 4 Примечания 5 Литература Процесс нормализации Нормализации, сохраняющие исходное написание Перечисленные ниже способы нормализации описаны в 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.