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

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

Добавьте сюда заголовок

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

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

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

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

Перечисленные ниже способы нормализации описаны в RFC 3986^[1] и приводят к эквивалентным 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 с процентными конструкциями, то они должны быть переведены в символы.^[2] Например:

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 ведущих на один ресурс:

• Удаление головного индекса. в большинстве случаев не нужен в URL (так как поисковые системы и браузеры автоматические ищут файлы index.* и default.*). Например:

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

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

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

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 эквивалентны и могут быть нормализованны в одну из форм.

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

Примечания

1. ↑ RFC 3986, Section 6: Normalization and Comparison
2. ↑ RFC 3986, Section 2.3.: Unreserved Characters
3. ↑ en:Fragment identifier
4. ↑ Ben Alman » jQuery 1.4 $.param demystified

Литература

• RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax
• Sang Ho Lee, Sung Jin Kim, and Seok Hoo Hong (2005). "On URL normalization". Proceedings of the International Conference on Computational Science and its Applications (ICCSA 2005): 1076–1085. 
• Gautam Pant, Padmini Srinivasan, and Filippo Menczer (2004). "Crawling the Web". Web Dynamics: Adapting to Change in Content, Size, Topology and Use, edited by M. Levene and A. Poulovassilis: 153–178. 
• Uri Schonfeld, Ziv Bar-Yossef, and Idit Keidar (2006). "Do not crawl in the dust: different URLs with similar text". Proceedings of the 15th international conference on World Wide Web: 1015–1016. 
• Uri Schonfeld, Ziv Bar-Yossef, and Idit Keidar (2007). "Do not crawl in the dust: different URLs with similar text". Proceedings of the 16th international conference on World Wide Web: 111–120. 

См. также

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

Связать^?

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