Должен ли 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- с учетом регистра.

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

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

Часть доменного имени URL-адреса не чувствительна к регистру, поскольку DNS игнорирует регистр: 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 

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

so...

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

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

Учтите следующее:

https://www.example.com/createuser.php?name=Paul%20McCartney

В этом гипотетическом примере HTML-форма - с использованием метода GET - отправляет параметр «name» в сценарий PHP, который создает новую учетную запись пользователя.

В этом примере я подчеркиваю, что этот параметр GET должен быть чувствительным к регистру, чтобы сохранить заглавные буквы в слове «Маккартни» (или, как другой пример, чтобы сохранить «Walter d'Isney», поскольку есть другие способы для имен, чтобы нарушить обычные правила использования заглавных букв).

Именно такие случаи руководят рекомендацией W3C о том, что схема и хост нечувствительны к регистру, но все, что происходит после этого, потенциально чувствительно к регистру - и остается на усмотрение сервера. Принуждение к нечувствительности к регистру по стандарту сделало бы приведенный выше пример неспособным сохранить регистр ввода пользователя, переданного как параметр запроса GET.

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

(например, имя пользователя учетной записи, вероятно, лучше всего использовать без учета регистра - поскольку «User123» и «user123», являющиеся разными учетными записями, могут сбивать с толку - даже если их настоящее имя, как указано выше, лучше всего оставить чувствительным к регистру.)

Иногда это актуально, в большинстве случаев - нет. Но решение об этих вещах должно быть оставлено на усмотрение сервера / веб-разработчика - и это не может быть предписано стандартом - поскольку только на этом уровне может быть известен контекст.

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

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

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

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

http://stackoverflow.com/ABOUT.html

а также

http://stackoverflow.com/about.html

Чем они должны отличаться? Может быть, написано «стиль крика» (заглавные буквы), но с точки зрения IA, различие никогда не должно проводиться путем изменения URL-адреса.

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

Раздел 6.2.2.1 RFC 3986 говорит, что Схема и хост не чувствительны к регистру и поэтому должны быть нормализованы к нижнему регистру. Например, URI HTTP://www.EXAMPLE.com/ эквивалентен http://www.example.com/. Предполагается, что другие компоненты общего синтаксиса чувствительны к регистру, если иное не определено схемой.

Сервер может внутренне нормализовать переданный URI и обслуживать один и тот же ресурс для URI с другим регистром (/about/ и /ABOUT/), в результате чего URI будет казаться для пользователя нечувствительным к регистру.

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

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

Почему w3c считает, что доменные имена нечувствительны к регистру, а все остальное остается нечувствительным к регистру?

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

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

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

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

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

Итак, вот мои соображения: -

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

Ваш URL-адрес (за исключением доменного имени) должен быть нечувствительным к регистру, если ожидается, что ваши пользователи будут касаться его или вводить его и т. Д. Вы должны разработать свое приложение так, чтобы ИЗБЕГАТЬ, чтобы пользователи вводили путь как можно чаще.

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

Заключение

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

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

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

Сохранение дела

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

Чувствительность к регистру

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

http: // www. example.com /abc/def.ghi?jkl=mno#pqr

пользователь @ example.com

Обоснование

Чувствительность к регистру в URL-адресах может иметь несколько применений. В основном:

1. Встроенная совместимость с файловыми системами, чувствительными к регистру.
2. Более компактное кодирование данных в URL-адресах, например для сериализации, хеширования, идентификаторов, постоянных ссылок и сокращателей URL-адресов.

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

Например, представьте существующий продукт, который требует размещения большого количества данных в URL-адресе GET, но при этом должен быть совместим с максимальной длиной URL-адресов всех основных серверов, браузеров и механизмов кэширования / прокси. Чтобы уместить даже командную строку средней длины (менее 1024 символов для некоторых старых браузеров), вам нужно будет использовать каждый уникальный URL-безопасный символ, который вы могли бы (что в основном является кодировкой base64url).

В идеальном мире

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

Многие, похоже, согласны с тем, что URL-адреса без учета регистра явно включены для многих популярных сайтов и служб, чтобы повысить удобство использования. Самый яркий пример - это имя пользователя в адресах электронной почты. Большинство провайдеров электронной почты игнорируют регистр, а иногда даже точки и другие символы (например, [email protected] совпадает с [email protected]). Несмотря на то, что имена пользователей электронной почты по умолчанию чувствительны к регистру, согласно спецификации.

Однако факт в том, что, несмотря на то, что я или другие могли бы хотеть, это то, как все работает в настоящее время. И хотя в конечном итоге глобальный переход к стандарту URL-адресов без учета регистра, вероятно, займет довольно много времени, поскольку в настоящее время чувствительность к регистру широко используется в Интернете для различных целей.

Лучшие практики

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

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

Чувствительность к регистру URL-адресов в целом (а также то, являются ли они одинаковыми или нет, если они находятся в другом регистре), необходимо рассматривать со следующих точек зрения:

• Эквивалентность ресурсов
• Сравнение URL

С точки зрения эквивалентности ресурсов, как правило, невозможно сказать, что два URL-адреса, отличающиеся каким-либо регистром (нижний регистр, верхний регистр, регистр предложений, регистр верблюда ... любая комбинация регистра), отличаются друг от друга, если ресурс не извлекается из оба URL-адреса, что во многих случаях нецелесообразно (RFC 3986, раздел 6.1, параграф 1). Поэтому, когда ресурс не может быть получен, используется перспектива сравнения.

Однако в случае, когда можно получить ресурс, вопрос становится более сложным (как и ожидалось). В соответствии с положениями RFC 3986, раздел 3.3, параграф 5, как указано ниже.

Помимо точечных сегментов в иерархических путях, сегмент пути считается непрозрачным в соответствии с общим синтаксисом

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

Тем не менее, для схемы и хостовой части органа, спецификация (мягко говоря) заявляет, что они нечувствительны к регистру. См. RFC 3986, раздел 3.1, параграф 1 и RFC 3986, раздел 6.2.2.1, параграф 2.

Исчерпав эту строку запроса, следует взглянуть на перспективу сравнения, чтобы определить, должны ли URI / URL-адреса быть чувствительными к регистру или нет.

Первый намек на это направление появляется при прочтении раздела 6.2.2.1 (выше).

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

Что дополнительно подкрепляется рассмотрением RFC 2616, раздел 3.2.3

При сравнении двух URI, чтобы решить, совпадают они или нет, клиент ДОЛЖЕН использовать октетное сравнение всех URI с учетом регистра.

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

Помимо синтаксиса, в приведенном выше RFC ничего не упоминается о фактической интерпретации пути и запроса, за исключением того, что он «непрозрачен», и только указывает, как (с ДОЛЖНЫМ, а не ОБЯЗАТЕЛЬНО) «клиент» может «сравнивать» URL-адрес. В нем ничего не говорится о том, как сервер (ДОЛЖЕН, не говоря уже о том, что ДОЛЖЕН) интерпретировать остальную часть URL-адреса за пределами схемы / полномочий.

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

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

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

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

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

Можно сделать URL-адреса без учета регистра

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

Сделать Google.com..GOOGLE.com и т. Д. Напрямую на google.com