Чи має 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-адреса залежно від регістру?

Відповідно до " HTML і URL-адрес " W3, вони повинні:

Можливо, є URL-адреси або частини URL-адрес, де справа не має значення, але визначити їх може бути непросто. Користувачі завжди повинні враховувати, що URL-адреси залежать від регістру.

Усі " нечутливі " є зміцненими для читабельності.

Відповідно до RFC 4343, доменні імена не залежать від регістру . Решта URL-адреси надсилається на сервер методом GET. Це може бути залежно від регістру чи ні.

Візьмемо, наприклад, цю сторінку, stackoverflow.com отримує GET рядок / питання / 7996919 / must-url-be-регістр , надсилаючи HTML-документ у свій браузер. Stackoverflow.com нечутливий до регістру, оскільки він дає такий самий результат для / QUEStions / 7996919 / Should-url-be-регістр .

З іншого боку, Вікіпедія відрізняється від регістру, окрім першого символу заголовка. URL-адреси https://en.wikipedia.org/wiki/Case_sensibility та https://en.wikipedia.org/wiki/case_sensibility призводять до тієї ж статті, але 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#page-19

Схема та хост не залежать від регістру і зазвичай надаються з малих літер; всі інші компоненти порівнюються залежно від регістру.

Розглянемо наступне:

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

У цьому гіпотетичному прикладі форма HTML - за допомогою методу GET - надсилає параметр "ім'я" до сценарію PHP, який створює новий обліковий запис користувача.

І справа, яку я зазначаю на цьому прикладі, полягає в тому, що цей параметр GET повинен бути чутливим до регістру, щоб зберегти капіталізацію "Маккартні" (або, як інший приклад, для збереження "Walter d'Isney", оскільки є й інші способи імена порушують звичайні правила великої літери).

Такі випадки керуються рекомендацією W3C, що схема та хост не залежать від регістру, але все після цього є потенційно залежним від регістру - і залишається на сервері. Примушення нечутливості регістру за допомогою стандарту зробить приклад вищезгаданим нездатним зберегти випадок введення користувача, переданий як параметр GET запиту.

Але я б сказав, що, хоча це обов'язково літера закону для прийняття таких випадків, дух закону полягає в тому, що, коли справа не має значення, поводитись у випадку нечутливим чином. Стандарти, однак, не можуть сказати вам, де випадок не має значення, оскільки, як і приклади, які я наводив, це річ, що залежить від контексту.

.

Іноді це актуально, частіше за все це не так. Але вирішити ці речі - і це не може бути встановлено стандартом - залишається за рішенням сервера / веб-розробника, оскільки лише на цьому рівні міг бути відомий контекст.

Схема та хост не залежать від регістру (що показує перевагу стандарту щодо нечутливості випадку, де він може бути загальновизначений). Залишилося вирішити, як краще зрозуміти контекст. Але, як було обговорено, ви, мабуть, повинні, в дусі закону, замовчуватись на випадок нечутливості, якщо у вас немає вагомих причин цього не робити.

URL-адреси повинні бути нечутливими до регістру, якщо тільки немає поважних причин, чому вони не повинні бути.

Це не є обов'язковим (це не будь-яка частина RFC), але це робить зв’язок та зберігання URL-адрес набагато надійнішими.

Якщо у мене на веб-сайті є дві сторінки:

http://stackoverflow.com/ABOUT.html

і

http://stackoverflow.com/about.html

Чим вони повинні відрізнятися? Може бути, написано "кричащий стиль" (літери), але, з точки зору ІА, розрізнення ніколи не повинно здійснюватися зміною у випадку URL-адреси.

Більше того, реалізувати це в Apache досить просто - просто використовуйте CheckSpelling Onmod_Speling.

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

w3c може мати свої рекомендації - що мене дуже хвилює - але я хочу переосмислити, оскільки тут питання.

Чому w3c вважає доменні імена нечутливими до регістру і залишає після цього що-небудь нечутливе?

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

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

Але питання полягає лише в тому, що машини МОЖУТИ впоратися, що це слід робити так?

Я маю на увазі, в чому переваги іменування та доступу до ресурсу, який сидить у hereIsTheResourcevs hereistheresource?

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

Тож ось мої моменти: -

Шлях до ресурсів потрапляє десь посередині структури програмування і іноді знаходиться поруч з кінцевим користувачем за браузером.

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

Ваша URL-адреса (за винятком доменного імені) має відрізнятись від регістру, якщо ваші користувачі ніколи не вводять її вручну.

Висновок

Шлях повинен враховувати регістри. Мої бали зважуються на залежні від регістру шляхи.

Символи URL-адреси перетворюються в шістнадцятковий код (якщо ви коли-небудь помічали пробіли в URL-адресах, що відображаються як% 20 тощо), і оскільки нижній і верхній регістри мають різні шістнадцяткові значення, має ідеальний сенс, що URL-адреси, безумовно, залежать від регістру. Однак дух питання, здається, ДОЛЖЕН бути стандартним, і я кажу "ні", але вони є. Розробник / постачальник зобов'язаний враховувати це у своєму коді, якщо вони хочуть, щоб він працював незалежно від кінцевого користувача.

Я думаю, що це і багато відповідей навколо того, що робить або не говорить специфіка, не вистачає суті питання. Чи повинні вони враховувати регістри? Це дійсно завантажене питання. З точки зору користувача, чутливість регістру є больовою точкою, але не всі знають, що має значення. Питання про те, мають бути чи не повинні бути, залежить від контексту питання. Щодо технічної гнучкості, так, вони повинні бути. Щодо зручності використання, ні, їх не повинно бути.

Збереження справ

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

питання полягає в тому, чи має URL-адреса залежно від регістру?

Я не бачу жодної корисності та належної практики за URL-адресами з урахуванням регістру. Це дурно, це смокче і слід уникати його в усі часи.

Просто для підтвердження моєї думки, коли хтось запитує, яка URL-адреса, як ви могли пояснити, які символи URL - це верхній чи нижній регістр? Це нісенітниця, і ніхто не повинен вам говорити інакше.

Для веб-сайтів, розміщених на сервері Linux, URL-адреса залежить від регістру. http://www.google.com/about та http://www.google.com/ About буде переспрямовано на різні місця. Перебуваючи на сервері Windows, 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