Нормализация URI
Нормализация URI — это процесс, посредством которого URI последовательно изменяются и стандартизируются. Цель процесса нормализации — преобразовать URI в нормализованный URI, чтобы можно было определить, могут ли два синтаксически разных URI быть эквивалентными.
Поисковые системы используют нормализацию URI, чтобы правильно ранжировать страницы, которые можно найти по нескольким URI, и уменьшить индексацию дубликатов страниц. Веб-сканеры выполняют нормализацию URI, чтобы избежать повторного сканирования одного и того же ресурса. Веб-браузеры могут выполнять нормализацию, чтобы определить, была ли посещена ссылка или кэширована ли страница . Веб-серверы также могут выполнять нормализацию по многим причинам (например, чтобы иметь возможность легче перехватывать угрозы безопасности, исходящие от клиентских запросов, использовать только одно абсолютное имя файла для каждого ресурса, хранящегося в их кэшах, названного в файлах журналов и т. д.).
Процесс нормализации
[ редактировать ]Существует несколько типов нормализации, которые могут быть выполнены. Некоторые из них всегда сохраняют семантику, а некоторые — нет.
Нормализации, сохраняющие семантику
[ редактировать ]Следующие нормализации описаны в RFC 3986. [1] чтобы получить эквивалентные URI:
- Преобразование триплетов с процентным кодированием в верхний регистр. Шестнадцатеричные цифры в тройке процентного кодирования URI (например,
%3aпротив%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/
- Удаление порта по умолчанию. Пустой или порт по умолчанию (порт 80 для компонент URI
httpсхема) с разделителем «:» следует удалить. [8] Пример:
http://example.com:80/→http://example.com/
Нормализации, которые обычно сохраняют семантику
[ редактировать ]Для URI http и https следующие нормализации, перечисленные в RFC 3986, могут привести к эквивалентным URI, но стандарты не гарантируют это:
- Добавление завершающего «/» к непустому пути. Каталоги (папки) обозначаются косой чертой и должны быть включены в URI. Пример:
http://example.com/foo→http://example.com/foo/- Однако невозможно узнать, представляет ли компонент пути URI каталог или нет. В RFC 3986 отмечается, что если первый URI перенаправляется на второй URI, это указывает на то, что они эквивалентны.
Нормализации, меняющие семантику
[ редактировать ]Применение следующих нормализации приводит к получению семантически другого URI, хотя он может относиться к одному и тому же ресурсу:
- Удаление индекса каталога. по умолчанию Индексы каталогов обычно не нужны в URI. Примеры:
http://example.com/a/index.html→http://example.com/a/http://example.com/default.asp→http://example.com/
- Удаление фрагмента. Компонент - фрагмент 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.
Шонфельд и др. (2006) представили эвристику под названием DustBuster для обнаружения правил DUST (разные URI со схожим текстом), которые можно применять к спискам URI. Они показали, что после того, как правильные правила DUST были найдены и применены с помощью алгоритма нормализации, они смогли найти до 68% избыточных URI в списке URI.
См. также
[ редактировать ]- URL (унифицированный указатель ресурсов)
- URI фрагмента
- Веб-сканер
Ссылки
[ редактировать ]- ^ RFC 3986, раздел 6. Нормализация и сравнение.
- ^ RFC 3986, раздел 6.2.2.1. Нормализация случая
- ^ RFC 3986, раздел 6.2.2.1. Нормализация случая
- ^ RFC 3986, раздел 6.2.2.3. Нормализация сегмента пути
- ^ RFC 3986, 5.2.4. Удалить точечные сегменты
- ^ RFC 3986, 6.2.2.3. Нормализация сегмента пути
- ^ RFC 3986, раздел 6.2.3. Нормализация на основе схемы
- ^ RFC 3986, раздел 6.2.3. Нормализация на основе схемы
- ^ «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.