Должен ли 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-регистрозависимый , отправляя HTML-документ в ваш браузер. Stackoverflow.com нечувствителен к регистру, потому что он дает тот же результат для / QUEStions / 7996919 / If-url-be-case-чувствительный .

С другой стороны, Википедия чувствительна к регистру, кроме первого символа названия. 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 

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

так...

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 должен учитывать регистр, чтобы сохранить заглавные буквы «Маккартни» (или, как еще один пример, чтобы сохранить «Вальтер д'Исней», поскольку существуют другие способы). чтобы имена нарушали обычные правила использования заглавных букв).

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

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

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

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

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

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

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

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

http://stackoverflow.com/ABOUT.html

и

http://stackoverflow.com/about.html

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

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

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

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

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

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

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

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

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

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

Итак, вот мои очки: -

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

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

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

Вывод

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

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

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

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

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

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

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

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

    user @ example.com

обоснование

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

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

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

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

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

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

Многие, похоже, согласны с тем, что URL-адреса без учета регистра явно включены для многих популярных сайтов и сервисов, чтобы повысить удобство использования. Наиболее ярким примером является часть имени пользователя в адресах электронной почты. Большинство провайдеров электронной почты игнорируют регистр, а иногда даже точки и другие символы (например, «j.smith@example.com» совпадает с «JSMITH@example.com»). Хотя имена пользователей электронной почты по умолчанию чувствительны к регистру, согласно спецификации.

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

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

Что касается передового опыта, как пользователь, вы можете разумно придерживаться строчных букв в большинстве ситуаций и ожидать, что все будет работать. Основными исключениями будут 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