Должен ли 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 быть чувствительным к регистру?
1 ответ
Сохранение регистра
URL-адреса сохраняют регистр между клиентом и сервером. Но части URL-адресов могут или не могут быть с учетом регистра , в зависимости от сервера, по нескольким причинам.
Чувствительность к регистру
В следующих полужирных частях URL-адресов может учитываться регистр, в зависимости от конфигурации сайта и / или сервера.
& nbsp; & nbsp; & nbsp; & nbsp; http: // www. example.com /abc/def.ghi?jkl=mno#pqr
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; пользователь @ 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-адресов как можно без учета регистра. Хотя, как уже отмечалось выше, есть несколько трудных для избежания ситуаций, в зависимости от контекста.