Чистый URL

Clean URL или довольно URL (немецкий чистый URL или довольно URL ) является Uniform Resource Locator (URL), машиночитаемыми слова , а не технические ярлыки или базы данных идентификаторов содержит. Отсутствуют компоненты searchpart или query или расширения имен файлов, такие как. B. .html , .php или другая информация, используемая серверными технологиями, такими как cgi-bin или cgi . Вместо этого в URL используются удобочитаемые и описательные заголовки или лексикографические леммы , календарные даты (в основном внешний вид) и язык содержания (в основном сокращенный в соответствии с ISO 639 ).

В веб-разработке говорят о « слаге » и подразумевают последнюю часть пути URL.

Также могут встречаться сочетания двух методов, при которых идентификатор сохраняется, но добавляются читаемые слова. В этом случае идентификатор является решающей характеристикой URL, и слова можно изменить или опустить.

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

Примеры

Примером как чистых, так и говорящих URL-адресов является Википедия , чьи URL-адреса структурированы по следующей схеме: 

<Protokoll><Sprachcode>.wikipedia.org/wiki/<Artikelbezeichnung>

Например, URL-адрес для термина подсолнечник выглядит так 

https://de.wikipedia.org/wiki/Sonnenblume

вместо URL-адреса, который позволяет делать выводы о технологии 

https://de.wikipedia.org/w/index.php?title=Sonnenblume

или URL-адрес, который не указывает на содержание 

https://de.wikipedia.org/?curid=112763

(все указанные URL имеют одинаковый результат)

технологии

Чистые URL-адреса могут быть реализованы на уровне веб-сервера и веб-приложения. Однако веб-сервер также должен быть настроен соответствующим образом на уровне веб-приложения.

Уровень веб-сервера

Большинство веб-серверов, таких как HTTP-сервер Apache или nginx, могут реализовывать «чистые» URL-адреса с помощью .htaccess или также с помощью механизмов перезаписи . Эти модули позволяют внутренне переписывать или интерпретировать запросы на основе ранее определенных правил с использованием регулярных выражений . Например, запрос из может foo/barдать тот же результат, что и запрос из /index.php?q=/foo/bar. Протокол CGI предлагает другой метод, и в этом случае сценарий называется /index.php/foo/bar /foo/barPATH_INFO.

Уровень веб-приложения

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

льготы

  • Пользователи могут быстрее оценивать релевантность озвученных URL-адресов (значимый URL-адрес обычно чаще нажимается, чем загадочный).
  • Пользователи могут легче запоминать URL-адреса (и аналогичные расширения файлов, такие как html или htm, больше не нужно угадывать).
  • Внешние ссылки и закладки на странице действительны намного дольше, потому что они не зависят от внутренних технических изменений.
  • С поисковой оптимизацией (там также sefURL для дружественной поисковой системы ), то поисковая система ранжирования по ключевым словам не только оценивает содержание страницы , но и имена доменов и файлов отдельных страниц.

веб ссылки

Индивидуальные доказательства

  1. ↑ RFC1738: унифицированные указатели ресурсов (URL) . 3.3. HTTP (английский)
  2. ↑ RFC3986: Универсальный идентификатор ресурса (URI): общий синтаксис . 3. Компоненты синтаксиса (английский)
  3. ↑ Якоб Нильсен: URL как пользовательский интерфейс. Nielsen Norman Group, 21 марта 1999, доступ к 6 апреля 2013 .
  4. ↑ RFC 3875 - Общий интерфейс шлюза (CGI) версии 1.1 . (Английский)
  5. ↑ Тим Бернерс-Ли : Классные URI не меняются. World Wide Web Consortium , 1998, доступ к 10 апреля 2013 .
  6. ↑ Sefurl - Единый указатель ресурсов для поисковых систем. Почему Сефурл? В: sefurl.de. По состоянию на 12 июня 2011 г .: «Ключевые слова также оцениваются в имени домена и в имени файла отдельных страниц».