Должен ли URL-адрес чувствителен к регистру?

Я заметил, что

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK 

а также

 http://stackoverflow.com/questions/ask 

оба работают нормально – фактически предыдущий преобразуется в нижний регистр.

Я думаю, что это имеет смысл для пользователя.

Если я посмотрю на Google, этот URL-адрес будет работать нормально:

 http://www.google.com/intl/en/about/corporate/index.html 

но этот с «О» не работает:

 http://www.google.com/intl/en/ABOUT/corporate/index.html 

Должен ли URL быть чувствительным к регистру?

Согласно W3 « HTML и URL », они должны:

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

Все « нечувствительные » являются смелыми для удобочитаемости.

Доменные имена нечувствительны к регистру в соответствии с RFC 4343 . Остальная часть URL-адреса отправляется на сервер с помощью метода GET. Это может быть чувствительным к регистру или нет.

Возьмите эту страницу, например, stackoverflow.com получает строку GET / questions / 7996919 / should-url-be-case-sensitive , отправляя HTML-документ в ваш браузер. Stackoverflow.com нечувствителен к регистру, потому что он дает тот же результат для / QUEStions / 7996919 / Should-url-be-case-sensitive .

С другой стороны, Википедия чувствительна к регистру, за исключением первого символа названия. URL-адреса https://en.wikipedia.org/wiki/Case_sensitivity и https://en.wikipedia.org/wiki/case_sensitivity приводят к той же статье, но https://en.wikipedia.org/wiki/CASE_SENSITIVITY возвращает 404.

Зависит от хостинга os. Сайты, размещенные в Windows, как правило, нечувствительны к регистру, так как основная файловая система нечувствительна к регистру. Сайты, размещенные в системах типа Unix, как правило, чувствительны к регистру, поскольку их основные файловые системы, как правило, чувствительны к регистру. Часть имени хоста URL-адреса всегда нечувствительна к регистру, это зависит от остальной части пути.

Часть доменного имени URL-адреса не чувствительна к регистру, так как DNS игнорирует случай: http://en.example.org/ и HTTP://EN.EXAMPLE.ORG/ открывают HTTP://EN.EXAMPLE.ORG/ и ту же страницу.

Путь используется для указания и, возможно, поиска запрашиваемого ресурса. Он чувствителен к регистру, хотя на некоторых серверах он может рассматриваться как не зависящий от регистра, особенно тот, который основан на Microsoft Windows.

Если сервер чувствителен к регистру, а http://en.example.org/wiki/URL верен, то http://en.example.org/WIKI/URL или http://en.example.org/wiki/url отобразит страницу ошибки HTTP 404, если только эти URL-адреса не указывают на действительные ресурсы.

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

Как объясняет @Bhavin Shah, доменная часть URL-адреса нечувствительна к регистру, поэтому

 http://google.com 

а также

 http://GOOGLE.COM 

а также

 http://GoOgLe.CoM 

являются одинаковыми, но все после части имени домена считается чувствительным к регистру.

так…

 http://GOOGLE.COM/ABOUT 

а также

 http://GOOGLE.COM/about 

разные.

Примечание. Я говорю «технически», а не «буквально» во многих случаях, на самом деле серверы настроены так, чтобы обрабатывать эти элементы, но их можно настроить, чтобы они НЕ обрабатывались одинаково.

Различные серверы обрабатывают это по-разному, и в некоторых случаях они должны быть чувствительны к регистру. Во многих случаях строковые значения запроса кодируются (например, идентификаторы сеанса или кодированные в Base64 данные, переданные как значение строки запроса). Эти элементы чувствительны к регистру по своей природе, поэтому сервер должен учитывать регистр данных при обработке.

Поэтому, чтобы ответить на вопрос, серверы «должны» быть чувствительными к регистру при захвате этих данных, ответ «да, определенно».

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


Комментарий @Hart Simha в основном говорит то же самое. Я пропустил его до того, как я разместил его, поэтому я хочу дать кредит, в котором должен быть кредит.

Посмотрите здесь спецификацию: раздел 2.7.3 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19

Схема и хост нечувствительны к регистру и обычно предоставляются в нижнем регистре; все остальные компоненты сравниваются с учетом регистра.

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

Это необязательно (это не часть RFC), но делает связь и хранение URL-адресов более надежными.

Если у меня есть две страницы на веб-сайте:

 http://stackoverflow.com/ABOUT.html 

а также

 http://stackoverflow.com/about.html 

Как они должны отличаться? Возможно, один написан «кричащий стиль» (шапки) – но с точки зрения IA, различие никогда не должно происходить путем изменения в случае URL-адреса.

Кроме того, это легко реализовать в Apache – просто используйте CheckSpelling On от mod_Speling.

Старый вопрос, но я споткнулся здесь, так почему бы не сделать снимок, потому что вопрос ищет различные перспективы, а не окончательный ответ.

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

Почему w3c рассматривает доменные имена нечувствительными к регистру и оставляет что-либо после этого без учета регистра?

Я думаю, что обоснование заключается в том, что доменная часть URL-адреса вводится вручную пользователем. Все после гипертекста будет разрешено машиной (браузер и сервер в задней части).

Машины могут обрабатывать чувствительность к регистру лучше, чем люди (а не технический вид :)).

Но вопрос только в том, что машины МОГУТ справиться с этим, если это будет сделано так?

Я имею в виду, каковы преимущества именования и доступа к ресурсу, hereIsTheResource hereistheresource ? hereIsTheResource vs hereistheresource ?

Боковая часть очень нечитабельная, чем на верблюжьем корпусе, которая более читаема. Читаемый для людей (включая технический вид).

Итак, вот мои пункты: –

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

Ваш URL-адрес (за исключением имени домена) должен быть нечувствительным к регистру, если ваши пользователи должны будут его коснуться или ввести его и т. Д. Вам следует разработать свое приложение для AVOID, когда пользователи будут вводить путь как можно больше.

Ваш URL-адрес (за исключением имени домена) должен быть чувствительным к регистру, если ваши пользователи никогда не будут вводить его вручную.

Вывод

Путь должен быть чувствительным к регистру. Мои очки взвешиваются в сторону чувствительных к регистру путей.

URL-адреса преобразуются в шестнадцатеричный код (если вы когда-либо заметили пробелы в URL-адресах, отображаемых как% 20 и т. Д.), А так как нижний и верхний регистр имеют разные шестнадцатеричные значения, имеет смысл, что URL-адреса наиболее точно чувствительны к регистру. Однако дух вопроса, похоже, ДОЛЖЕН быть стандартным, и я говорю «нет», но они есть. Его разработчику / поставщику следует учитывать это в своем коде, если они хотят, чтобы он работал независимо от конечного пользователя.

Я думаю, что это и многие ответы вокруг того, что спецификация делает или не говорит, не упуская точку вопроса. Должны ли они быть чувствительными к регистру? На самом деле это загруженный вопрос. С точки зрения пользователя чувствительность к регистру – это точка боли, но не все знают, что имеет значение. Вопрос о том, должны ли URI быть или не должны быть, зависит от контекста вопроса. Для технической гибкости, да, они должны быть. Для удобства использования нет, их не должно быть.

Для сайтов, размещенных на сервере Linux, URL-адрес чувствителен к регистру. http://www.google.com/about и http://www.google.com/About будут перенаправлены в разные местоположения. Хотя в Windows Server URL-адрес не чувствителен к регистру, как и при назначении FOLDER и будет перенаправлен в одно и то же место.

вопрос в том, должен ли адрес быть чувствительным к регистру?

Я не вижу никакой пользы или хорошей практики за чувствительными к регистру URL. Это глупо, это отстой, и его всегда следует избегать.

Чтобы поддержать мое мнение, когда кто-то спрашивает, какой URL-адрес, как вы могли бы объяснить, какими символами URL-адреса являются верхний или нижний регистр? Это вздор, и никто никогда не скажет вам иначе.

Можно создавать нечеткие чувствительные URL-адреса

 RewriteEngine on rewritemap lowercase int:tolower RewriteCond $1 [AZ] RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L] 

Создание Google.com..GOOGLE.com и т. Д. Прямо на google.com

  • Параметры матрицы URL по сравнению с параметрами запроса
  • Изменение URL адресной строки в приложении AJAX для соответствия текущему состоянию
  • Получение частей URL (регулярное выражение)
  • Проверка наличия или отсутствия URL-адреса
  • Что такое shebang / hashbang (#!) В Facebook и новые URL-адреса Twitter?
  • Дружественные URL-адреса для ASP.NET
  • Какие символы недействительны?
  • Как получить RouteData по URL?
  • Как я могу иметь строчные маршруты в ASP.NET MVC?
  • Получить текущий URL-адрес из приложения Windows Forms
  • Разбор JSON из URL
  • Давайте будем гением компьютера.