Я заметил, что
HTTP://STACKOVERFLOW.COM/info/ASK
и
HTTP://STACKOVERFLOW.COM/info/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 строку fooobar.com/questions/32448/..., отправляя HTML-документ в ваш браузер. Stackoverflow.com нечувствителен к регистру, поскольку он дает тот же результат для fooobar.com/questions/32448/....
С другой стороны, Википедия чувствительна к регистру, кроме первого символа названия. 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/ открывают одну и ту же страницу.
Путь используется для указания и, возможно, поиска запрашиваемого ресурса. Он чувствителен к регистру, хотя на некоторых серверах он может рассматриваться как не зависящий от регистра, особенно тот, который основан на 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.
Учтите следующее:
https://www.example.com/createuser.php?name=Paul%20McCartney
В этом гипотетическом примере HTML-форма - с использованием метода GET - отправляет параметр "name" в сценарий PHP, который создает новую учетную запись пользователя.
И смысл этого примера в том, что этот параметр GET должен учитывать регистр, чтобы сохранить заглавные буквы "Маккартни" (или, как еще один пример, чтобы сохранить "Вальтер д'Исней", поскольку существуют другие способы). для имен нарушать обычные правила использования заглавных букв).
Это случаи, подобные этим, которые руководствуются рекомендацией W3C, что схема и хост нечувствительны к регистру, но все, что после этого, потенциально чувствительно к регистру - и остается на усмотрение сервера. Принудительное использование нечувствительности к регистру по стандарту сделало бы приведенный выше пример неспособным сохранить случай ввода пользователя, переданного в качестве параметра запроса GET.
Но я бы сказал, что, хотя это обязательно буква закона для учета таких случаев, дух закона заключается в том, что, когда дело не имеет значения, ведите себя без учета дела. Стандарты, тем не менее, не могут сказать вам, где случай не имеет значения, потому что, как и примеры, которые я привел, это зависит от контекста.
(например, имя пользователя учетной записи, вероятно, лучше всего вводить без учета регистра - поскольку "User123" и "user123" из-за разных учетных записей могут привести к путанице - даже если их настоящее имя, как указано выше, лучше всего оставить чувствительным к регистру.)
Иногда это актуально, в большинстве случаев это не так. Но решение об этом должно быть оставлено на усмотрение сервера/веб-разработчика - и не может быть предписано стандартом - поскольку только на этом уровне контекст может быть известен.
Схема и хост не чувствительны к регистру (который показывает стандартное предпочтение регистронезависимости, где это может быть универсально предписано). Остальное решать вам, поскольку вы лучше понимаете контекст. Но, как уже говорилось, вам, вероятно, следует, в духе закона, по умолчанию не учитывать регистр, если у вас нет веских причин не делать этого.
Старый вопрос, но я тут же споткнулся, так почему бы не сделать снимок, потому что вопрос ищет разные перспективы, а не окончательный ответ.
w3c может иметь свои рекомендации, о которых я очень забочусь, но хочу переосмыслить, так как вопрос здесь.
Почему w3c считает, что имена доменов нечувствительны к регистру и ничего не оставляет после этого регистрозависимости?
Я думаю, что обоснование заключается в том, что доменная часть URL-адреса вручную вводится пользователем. Все после гипертекста будет разрешено машиной (браузер и сервер в задней части).
Машины могут обрабатывать чувствительность к регистру лучше, чем люди (а не технический вид:)).
Но вопрос только в том, что машины МОГУТ справиться с этим, если это будет сделано так?
Я имею в виду, каковы преимущества именования и доступа к ресурсу, находящемуся в hereIsTheResource vs hereIsTheResource?
Боковая часть очень нечитабельная, чем на верблюжьем корпусе, которая более читаема. Читаемый для людей (включая технический вид).
Итак, вот мои пункты: -
Путь к ресурсам попадает где-то в середине структуры программирования и иногда находится рядом с конечным пользователем за браузером.
Ваш URL-адрес (за исключением имени домена) должен быть нечувствительным к регистру, если ваши пользователи должны будут его коснуться или ввести его и т.д. Вам следует разработать свое приложение для AVOID, когда пользователи будут вводить путь как можно больше.
Ваш URL-адрес (за исключением имени домена) должен быть чувствителен к регистру, если ваши пользователи никогда не будут вводить его вручную.
Заключение
Путь должен быть чувствительным к регистру. Мои очки взвешиваются в сторону чувствительных к регистру путей.
URL-адреса преобразуются в шестнадцатеричный код (если вы когда-либо заметили пробелы в URL-адресах, отображаемых как %20 и т.д.), а так как нижний и верхний регистр имеют разные значения шестнадцатеричных значений, имеет смысл, что URL-адреса наиболее определенны деликатный случай. Однако дух вопроса, похоже, ДОЛЖЕН быть стандартным, и я говорю "нет", но они есть. Его разработчику/поставщику следует учитывать это в своем коде, если они хотят, чтобы он работал независимо от конечного пользователя.
Я думаю, что это и многие ответы вокруг того, что спецификация делает или не говорит, не имеют смысла в вопросе. Должны они чувствительны к регистру? Это действительно загруженный вопрос. С точки зрения пользователя чувствительность к регистру - это боль, но не все знают, что имеет значение. Вопрос о том, должны ли URI быть или не должны быть, зависит от контекста вопроса. Для технической гибкости, да, они должны быть. Для удобства использования нет, их не должно быть.
URL-адреса сохраняют регистр между клиентом и сервером. Но части URL-адресов могут быть или не быть чувствительными к регистру, в зависимости от сервера, по нескольким причинам.
Следующие полужирные части URL-адресов могут вводиться с учетом регистра в зависимости от конфигурации сайта и/или сервера.
http://www. example.com /abc/def.ghi?jkl=mno#pqr
user @example.com
Чувствительность к регистру в URL может иметь несколько применений. В основном:
Как разработчик, я считаю, что с вышеизложенным часто можно справиться лучше, но я также понимаю, что есть случаи, когда ситуация может этого не позволить.
Например, представьте себе существующий продукт, для которого требуется много данных, помещенных в URL-адрес "GET", но он должен быть совместим с максимальной длиной URL-адреса всех основных серверов, браузеров и механизмов кэширования/прокси. Чтобы вместить даже командную строку средней длины (менее 1024 символов для некоторых старых браузеров), вам нужно будет использовать каждый уникальный URL-безопасный символ, который вы можете (что в основном и является кодировкой base64url).
Вопрос о том, должны ли URL-адреса учитываться регистр, является спорным. Я лично считаю, что это не должно быть, для простоты (хотя это может создавать более длинные URL-адреса, у нас есть процентные переходы для простой обработки случаев, когда мы должны обеспечить сохранение точных символов, и существуют способы передачи данных, отличных от правильных в URL-адресе),
Многие, похоже, согласны с тем, что URL-адреса без учета регистра явно включены для многих популярных сайтов и сервисов, чтобы повысить удобство использования. Наиболее ярким примером является часть имени пользователя в адресах электронной почты. Большинство провайдеров электронной почты игнорируют регистр, а иногда даже точки и другие символы (например, "[email protected]" совпадает с "[email protected]"). Хотя имена пользователей электронной почты по умолчанию чувствительны к регистру, согласно спецификации.
Тем не менее, факт заключается в том, что, несмотря на то, что я или другие могли бы хотеть, это состояние, как вещи в настоящее время работают. И хотя возможный во всем мире переход к стандарту 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