Должен ли URL быть чувствительным к регистру?


284

Я заметил, что

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 быть чувствительным к регистру?


13
ИМХО, URL никогда не должен быть чувствительным к регистру, это просто усложняет жизнь людям, которые будут его использовать.
Мухаммед Умер

16
Вопрос "ДОЛЖЕН ли URL быть чувствительным к регистру?" это плохой вопрос, потому что это вызывает мнение. Скорее, лучше задать вопрос: «ПОЧЕМУ (или ПОЧЕМУ нет) URL-адреса чувствительны к регистру?» Или «Почему некоторые URL-адреса чувствительны к регистру, а другие нет?»
чхарве

Но для одного из возможных ответов, проверить новый URL - Стандарт от WHATWG , которая была принята на Node.js .
Чарви

на мой взгляд, нет, они не должны быть
Андрей

если браузер не учитывает случай, адрес ipfs будет сломан, но он не сломан
Beeno Tung

Ответы:


281

Согласно W3 « HTML и URL » они должны:

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


96
Я предполагаю, что «быть либеральным в том, что вы принимаете, и консерватором в том, что вы посылаете» (говорят IETF), было бы моим ориентиром.
jldupont

9
Руководство W3 разумно. В нем просто говорится, что не следует делать предположения о том, как сервер обрабатывает отправляемый вами URL. Это зависит от сервера, как обрабатывать URL запроса. Большинство веб-серверов Unix / Linux, и это означает, что большинство веб-серверов чувствительны к регистру.
oᴉɹǝɥɔ

37
W3 говорит, что ПОЛЬЗОВАТЕЛИ должны предполагать, что серверы чувствительны к регистру, но не дают рекомендации для СЕРВЕРОВ.
trysis

3
Для обеспечения устойчивости программы, интерпретирующие URL-адреса, должны обрабатывать буквы верхнего и нижнего регистра в именах схем (например, разрешать «HTTP», а также «http»). Источник
realPK

3
@PK_ Обратите внимание, что это относится только к части схемы URL. RFC1738 не обсуждает, следует ли интерпретировать другие части URL-адреса как чувствительные к регистру или нет.
dthrasher

126

Все « нечувствительные » смелы для удобства чтения.

Доменные имена нечувствительны к регистру в соответствии с 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.


7
Википедия на самом деле очень прощает чувствительность к регистру в тех случаях, когда пользователи могут подумать, что слово должно быть в том или ином случае, но это больше из-за OCD ... извините, внимательный характер своих редакторов. Хотя его URL-адреса технически чувствительны к регистру.
trysis

14
Это потому, что семантическая, читаемая часть URL-адреса вопроса в stackoverflow не идентифицирует его, она идентифицируется как 7996919. Семантическая часть URL только для целей SEO.
user3367701

4
На самом деле также /programming/7996919/should-BLABLA-be-or-NOT-to-be работает. Это связано с тем, что сервер stackoverflow.com использует идентификатор вопроса только для его идентификации и возврата правильного URL-адреса и HTML-страницы.
Bozzy

72

Зависит от хостинга ОС. Сайты, размещенные в Windows, обычно нечувствительны к регистру, поскольку основная файловая система нечувствительна к регистру. Сайты, размещенные в системах типа Unix, обычно чувствительны к регистру, так как их базовые файловые системы обычно чувствительны к регистру. Часть имени хоста в URL всегда нечувствительна к регистру, остальная часть пути меняется.


1
Да, как это мучительно выяснилось при http-запросах к файлам на ftp-сервере Unix.
Лори Стерн

1
Было бы точнее сказать «зависит от сервера» в общем смысле - потому что обслуживание файлов - не единственный способ отвечать на запросы HTTP.
Валентин Waeselynck

31

Часть имени домена в 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-адреса не указывают на действительные ресурсы сами.


3
Этот ответ имеет единственно правильную формулировку «он чувствителен к регистру, хотя может рассматриваться как регистрозависимый». Единственно верный ответ.
Даниэль В.

@DanFromGermany, путь чувствителен к регистру может быть выведено из нечетко здесь «URL - адреса в целом являются чувствительными к регистру (за исключением имен машин) .Есть может быть URL, или части URL, где дело не имеет значения, но идентификации это может быть нелегко ". Но это выводить неоднозначно. Как упомянуто в одном из вышеупомянутых комментариев, RFC1738 не обсуждает, следует ли интерпретировать части URL, отличные от схемы, с учетом регистра или нет. У вас есть какая-нибудь ссылка, которая уточняет, какие части URL чувствительны к регистру?
гранат

2
@garnet Из RFC3986 6.2.2.1. Нормализация регистра : когда URI использует компоненты общего синтаксиса, всегда применяются правила эквивалентности синтаксиса компонента; а именно, что схема и хост не чувствительны к регистру и поэтому должны быть нормализованы к строчным. Например, URI HTTP://www.EXAMPLE.com/эквивалентен http://www.example.com/. Предполагается, что другие компоненты общего синтаксиса чувствительны к регистру, если в схеме не указано иное. "
Даниэль В.

2
@garnet И из HTTP RFC : « При сравнении двух URI, чтобы определить, совпадают они или нет, клиент ДОЛЖЕН использовать чувствительное к регистру сравнение октетов за октетом всех URI [...] » (за исключением схемы и сам хост).
Даниэль В.

15

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

В ответе @Bhavin Shah говорится, что доменная часть URL не зависит от регистра, поэтому

http://google.com 

и

http://GOOGLE.COM 

и

http://GoOgLe.CoM 

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

так...

http://GOOGLE.COM/ABOUT

и

http://GOOGLE.COM/about

разные.

Примечание: я говорю «технически», а не «буквально» во многих случаях, в большинстве случаев серверы настроены так, чтобы обрабатывать эти элементы, но их можно настроить так, чтобы они НЕ обрабатывались одинаково.

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

Поэтому, чтобы ответить на вопрос, «должны ли» серверы учитывать эти данные, нужно ответить «да, определенно».

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


Комментарий @Hart Simha в основном говорит то же самое. Я пропустил это прежде, чем я отправил, таким образом, я хочу отдать должное, где кредит должен.



3

Учтите следующее:

https://www.example.com/createuser.php?name=Paul%20McCartney

В этом гипотетическом примере HTML-форма - с использованием метода GET - отправляет параметр «name» в скрипт PHP, который создает новую учетную запись пользователя.

И смысл этого примера в том, что этот параметр GET должен учитывать регистр, чтобы сохранить заглавные буквы «Маккартни» (или, как еще один пример, чтобы сохранить «Вальтер д'Исней», поскольку существуют другие способы). чтобы имена нарушали обычные правила использования заглавных букв).

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

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

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

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

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


Строки запроса обрабатываются как часть местоположения? Я считаю, что они рассматриваются как отдельные объекты и не используются для определения местоположения.
jpmc26

Строки запроса отделены от местоположения, да. Но те же принципы, которые я показал там с параметрами запроса, могут также применяться к другим частям URL. Например, некоторые CMS могут целенаправленно переписывать "/user.php?id=3756" в "/ users / PaulMcCartney" для более удобных для восприятия SEO URL-адресов, удобных для восприятия человеком (например, Wordpress). Дело в том, что стандарты намеренно отступают от предписания над тем, что зависит от контекста. Решение остается за сервером, поскольку сервер понимает контекст, а универсальный стандарт - нет.
Боб

2

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

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

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

http://stackoverflow.com/ABOUT.html

и

http://stackoverflow.com/about.html

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

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


0

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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


0

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


это интересный. обычные символы A ASCII (которые имеют верхний и нижний регистр) на самом деле не конвертируются, правда? это только пробелы и расширенные символы, которые экранируются в URL. Есть ли у расширенных символов модификаторы верхнего / нижнего регистра?
TygerKrash

0

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


Чтобы быть справедливым, любой вопрос, задаваемый «СЛЕДУЕТ», изначально основан на мнении и может быть удален из StackOverflow. (Подробнее: stackoverflow.blog/2010/09/29/good-subjective-bad-subjective )
chharvey

0

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

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


-1

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

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

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


32
Есть одно преимущество, что URL-адреса чувствительны к регистру. На некоторых веб-сайтах, где объекты кодируются уникальными идентификаторами, на которые можно ссылаться через URL-адрес, кодировка может быть чем-то вроде base64 вместо base36 . Это позволяет кодировать экспоненциально больше уникальных объектов в том же количестве символов URL. Например, foo.com/000 - foo.com/zzz (без учета регистра) может ссылаться на 36 ^ 3 уникальных объекта, где foo.com/000 - foo.com/ZZZ (с учетом регистра, что означает foo.com/zzz и foo.com/ZZZ - это разные пути), относящиеся к 62 ^ 3 объектам.
Харт Симха

6
Это не ответ, это самоуверенный комментарий.
Жестянщик

1
Я подкрепляю это примером. URL-адреса используются людьми (см. Оригинальный вопрос), а не компьютерами. Это очень сложно, поэтому посмотрите, ПОЧЕМУ ссылка не работает, и так как почти ВСЕ домены нечувствительны к регистру, то же самое следует сделать и с остальной частью URL. Понижающие голоса относятся к моему тону голоса (что плохо) или к тому, что технические люди предпочитают техническую красоту, а не пользовательский опыт.
HenriKoppen

1
@theTinMan Это ответ на вопрос, вызывающий мнение.
чхарве

Я согласен с @HartSimha, и поскольку вопрос требует мнения: если часть URL-маршрута не используется для идентификации уникального объекта, пожалуйста, за любовь ко всему, что хорошо в Интернете, НЕ делайте его чувствительным к регистру.
Jaybro

-3

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


-6

Возможно сделать не чувствительные к регистру URL

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

Создание Google.com..GOOGLE.com и т. Д. Прямо на google.com


Это не отвечает на вопрос
монокром

3
Вопрос: «Должен ли URL быть чувствительным к регистру?» Ваш ответ: «Как сделать URL без
учета
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.