Должен ли URL быть чувствительным к регистру?
Я заметил, что
HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK
а также
http://stackru.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 быть чувствительным к регистру?
18 ответов
Согласно W3 " HTML и URL" они должны:
Там могут быть URL-адреса или части URL-адресов, где регистр не имеет значения, но определить их может быть непросто. Пользователи всегда должны учитывать, что URL-адреса чувствительны к регистру.
Все " нечувствительные " смелы для удобства чтения.
Доменные имена нечувствительны к регистру в соответствии с RFC 4343. Остальная часть URL отправляется на сервер с помощью метода GET. Это может быть с учетом регистра или нет.
Возьмем, к примеру, эту страницу, stackru.com получает строку GET /questions/28741173/dolzhen-li-url-byit-chuvstvitelnyim-k-registru, отправляя HTML-документ в ваш браузер. Stackru.com нечувствителен к регистру, потому что он дает тот же результат для /questions/28741173/dolzhen-li-url-byit-chuvstvitelnyim-k-registru.
С другой стороны, Википедия чувствительна к регистру, кроме первого символа названия. 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
Схема и хост не чувствительны к регистру и обычно представлены в нижнем регистре; все остальные компоненты сравниваются с учетом регистра.
В разделе 6.2.2.1 RFC 3986 говорится, что « схема и хост нечувствительны к регистру и поэтому должны быть нормализованы к нижнему регистру . Например, URI
HTTP://www.EXAMPLE.com/ эквивалентно
http://www.example.com/. Предполагается, что другие компоненты общего синтаксиса чувствительны к регистру, если иное не определено схемой ".
Сервер может внутренне нормализовать переданный URI и обслуживать один и тот же ресурс для URI другого регистра (
/about/ а также
/ABOUT/), что делает URI-код без учета регистра для пользователя.
Учтите следующее:
https://www.example.com/createuser.php?name=Paul%20McCartney
В этом гипотетическом примере HTML-форма - с использованием метода GET - отправляет параметр "name" в скрипт PHP, который создает новую учетную запись пользователя.
И смысл этого примера в том, что этот параметр GET должен учитывать регистр, чтобы сохранить заглавные буквы "Маккартни" (или, как еще один пример, чтобы сохранить "Вальтер д'Исней", поскольку существуют другие способы). для имен нарушать обычные правила использования заглавных букв).
Подобные случаи определяют рекомендации W3C о том, что схема и хост не чувствительны к регистру, но все, что после этого, потенциально чувствительно к регистру и остается на усмотрение сервера. Принудительное использование нечувствительности к регистру по стандарту сделало бы приведенный выше пример неспособным сохранить регистр ввода пользователя, переданного в качестве параметра запроса GET.
Но я бы сказал, что, хотя это обязательно буква закона для учета таких случаев, дух закона заключается в том, что, когда дело не имеет значения, ведите себя нечувствительно к делу. Стандарты, тем не менее, не могут сказать вам, где случай не имеет значения, потому что, как и примеры, которые я привел, это зависит от контекста.
(например, имя пользователя учетной записи, вероятно, лучше всего вводить без учета регистра - поскольку "User123" и "user123" - разные учетные записи, могут привести к путанице - даже если их реальное имя, как указано выше, лучше всего оставить чувствительным к регистру.)
Иногда это актуально, в большинстве случаев это не так. Но решение об этих вещах должно быть оставлено на усмотрение сервера / веб-разработчика - и не может быть предписано стандартом - поскольку только на этом уровне контекст может быть известен.
Схема и хост не чувствительны к регистру (что показывает предпочтение стандарта к регистронезависимости, где это может быть универсально предписано). Остальное решать вам, поскольку вы лучше понимаете контекст. Но, как уже говорилось, вам, вероятно, следует, в духе закона, по умолчанию не учитывать регистр, если у вас нет веских причин не делать этого.
Сохранение дела
URL-адреса сохраняют регистр между клиентом и сервером. Но части URL-адресов могут быть или не быть чувствительными к регистру, в зависимости от сервера, по нескольким причинам.
Чувствительность к регистру
Следующие полужирные части URL-адресов могут вводиться с учетом регистра в зависимости от конфигурации сайта и / или сервера.
http: // www. example.com /abc/def.ghi?jkl=mno#pqr
user @ example.com
обоснование
Чувствительность к регистру в URL может иметь несколько применений. В основном:
- Нативная совместимость с чувствительными к регистру файловыми системами.
- Более компактное кодирование данных в URL-адресах, например, для сериализации, хеширования, идентификаторов, постоянных ссылок и сокращений URL-адресов.
Как разработчик, я считаю, что с вышеизложенным часто можно справиться лучше, но я также понимаю, что есть случаи, когда ситуация может этого не позволить.
Например, представьте себе существующий продукт, для которого требуется много данных, помещенных в URL-адрес "GET", но он должен быть совместим с максимальной длиной URL-адреса всех основных серверов, браузеров и механизмов кэширования / прокси. Чтобы вместить даже командную строку средней длины (менее 1024 символов для некоторых старых браузеров), вам нужно будет использовать каждый уникальный URL-безопасный символ, который вы можете (что в основном и является кодировкой base64url).
В идеальном мире
Вопрос о том, должны ли URL-адреса учитываться регистр, является спорным. Я лично считаю, что это не должно быть, для простоты (хотя это может создавать более длинные URL-адреса, у нас есть процентные переходы для простой обработки случаев, когда мы должны обеспечить сохранение точных символов, и существуют способы передачи данных, отличных от правильных в URL-адресе),
Многие, похоже, согласны с тем, что URL-адреса без учета регистра явно включены для многих популярных сайтов и сервисов, чтобы повысить удобство использования. Наиболее ярким примером является часть имени пользователя в адресах электронной почты. Большинство провайдеров электронной почты игнорируют регистр, а иногда даже точки и другие символы (например, "j.smith@example.com" совпадает с "JSMITH@example.com"). Хотя имена пользователей электронной почты по умолчанию чувствительны к регистру, согласно спецификации.
Тем не менее, факт заключается в том, что, несмотря на то, что я или другие могли бы хотеть, это состояние, как вещи в настоящее время работают. И хотя возможный во всем мире переход к стандарту URL без учета регистра, безусловно, возможен, это, вероятно, займет довольно много времени, поскольку в настоящее время регистр-регистр широко используется для различных целей в Интернете.
Лучшие практики
Что касается передового опыта, как пользователь, вы можете разумно придерживаться строчных букв в большинстве ситуаций и ожидать, что все будет работать. Основными исключениями будут URL-адреса, использующие кодировку на основе регистра или пути к документам с прямыми эквивалентами файловой системы. Однако такие сложные URL-адреса обычно вставляются копированием (или простым щелчком), а не вводятся вручную.
Как веб-разработчик, вы должны рассмотреть возможность сохранения URL-адресов как можно без учета регистра. Хотя в зависимости от контекста, как уже отмечалось выше, существуют определенные трудные для избежания ситуации.
URL должны быть нечувствительны к регистру, если нет веской причины, почему они не должны быть.
Это не является обязательным (это не какая-либо часть RFC), но делает передачу и хранение URL-адресов намного более надежной.
Если у меня есть две страницы на сайте:
http://stackru.com/ABOUT.html
а также
http://stackru.com/about.html
Как они должны отличаться? Возможно, один из них написан как "стиль крика" (заглавные буквы), но с точки зрения IA, различие никогда не должно проводиться путем изменения URL-адреса.
Более того, это легко реализовать в Apache - просто используйте CheckSpelling On от mod_Speling.
Чувствительность к регистру 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-адресах, отображаемых как%20 и т. Д.), И поскольку нижний и верхний регистр имеют различные шестнадцатеричные значения, вполне логично, что URL-адреса наиболее определенно чувствительны к регистру. Однако дух вопроса, похоже, должен быть стандартом, и я говорю нет, но они есть. Разработчик / провайдер должен учитывать это в своем коде, если он хочет, чтобы он работал независимо от конечного пользователя.
С учетом упомянутых официальных руководящих принципов возникает интересный случай, когда следует рассмотреть возможность использования всего URL-адреса в ЗАГЛАВНОМ РЕГИСТРЕ: QR-коды.
Например,
https://example.com/ не вписывается в QR-код версии 1 (21x21) и требует QR-кода версии 2 большего размера (25x25).
При использовании буквенно-цифрового режима позволяет набивать
HTTPS://EXAMPLE.COM/12345 в уменьшенную версию 1!
Старый вопрос, но я тут споткнулся, так почему бы не попробовать его, так как вопрос ищет разные перспективы, а не однозначный ответ.
У w3c могут быть свои рекомендации - которые меня очень волнуют - но я хочу переосмыслить, поскольку вопрос здесь.
Почему w3c считает доменные имена нечувствительными к регистру и оставляет после себя что-нибудь нечувствительное к регистру?
Я думаю, что обоснование заключается в том, что доменная часть URL-адреса вручную вводится пользователем. Все, что будет после гипертекста, будет разрешено машиной (браузер и сервер сзади).
Машины могут справиться с нечувствительностью к регистру лучше, чем люди (не технический вид:)).
Но вопрос только в том, что машины МОГУТ справиться с этим, нужно ли так делать?
Я имею в виду, каковы преимущества именования и доступа к ресурсу на hereIsTheResource против hereistheresource?
Боковая сторона очень нечитаема, чем верблюжья, которая более читабельна. Читаемый для людей (включая технический вид).
Итак, вот мои очки: -
Resource Path находится где-то посередине структуры программирования и иногда находится рядом с конечным пользователем за браузером.
Ваш URL (исключая доменное имя) должен учитываться без учета регистра, если ваши пользователи ожидают, что он прикоснется к нему или наберет его и т. Д. Вам следует разработать приложение, чтобы ИЗБЕЖАТЬ, чтобы пользователи как можно чаще вводили путь.
Ваш URL (исключая доменное имя) должен быть чувствительным к регистру, если ваши пользователи никогда не введут его вручную.
Заключение
Путь должен быть чувствительным к регистру. Мои очки стремятся к чувствительным к регистру путям.
Я думаю, что в этом и во многих ответах относительно того, что спецификация делает или не говорит, не хватает сути вопроса.Должны ли они быть чувствительными к регистру? Это действительно загруженный вопрос. С точки зрения пользователя, чувствительность к регистру - это болевая точка, не все знают, что это имеет значение. Вопрос о том, должны или не должны быть URI, зависит от контекста вопроса. Для технической гибкости, да, они должны быть. Для удобства использования нет, их не должно быть.
вопрос в том, должен ли 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