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

все "нечувствительный"С boldened для удобочитаемости.

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

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

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

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

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

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

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

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

вывод

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

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

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

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

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

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

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

можно сделать noncase чувствительной URL-адреса

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

создание Google.com..GOOGLE.com etc направляют к google.com