URL은 대소 문자를 구분해야합니까?

난 그것을 알아 챘다

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK

과

http://stackoverflow.com/questions/ask

둘 다 잘 작동합니다-실제로 이전의 것은 소문자로 변환됩니다.

나는 이것이 사용자에게 의미가 있다고 생각합니다.

Google을 보면이 URL이 정상적으로 작동합니다.

http://www.google.com/intl/en/about/corporate/index.html  

그러나 "ABOUT"이있는 것은 작동하지 않습니다.

http://www.google.com/intl/en/ABOUT/corporate/index.html   

URL은 대소 문자를 구분해야합니까?

W3의 " HTML 및 URL " 에 따르면 다음 과 같아야합니다.

대소 문자가 중요하지 않은 URL 또는 URL의 일부가있을 수 있지만 식별하기 쉽지 않을 수 있습니다. 사용자는 항상 URL이 대소 문자를 구분한다는 점을 고려해야합니다.

가독성을 위해 모든 " 무감각 "이 굵게 표시됩니다.

RFC 4343 에 따라 도메인 이름은 대소 문자를 구분하지 않습니다 . 나머지 URL은 GET 메소드를 통해 서버로 전송됩니다. 대소 문자를 구분하거나 구분하지 않을 수 있습니다.

예를 들어 stackoverflow.com은 GET 문자열 / questions / 7996919 / should-url-be-case-sensitive을 수신 하여 HTML 문서를 브라우저로 보냅니다. Stackoverflow.com은 / QUEStions / 7996919 / Should-url-be-case-sensitive에 대해 동일한 결과를 생성하므로 대소 문자를 구분하지 않습니다 .

반면 위키 백과는 제목의 첫 문자를 제외하고 대소 문자를 구분합니다. 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바르면 URL이 유효한 자원 자체를 가리 키지 않는 한 http://en.example.org/WIKI/URL또는 http://en.example.org/wiki/urlHTTP 404 오류 페이지를 표시합니다.

나는 오래된 기사를 부딪히는 팬이 아니지만 이것이이 특정 문제에 대한 첫 번째 응답 중 하나 였기 때문에 뭔가를 분명히해야한다고 생각했습니다.

@Bhavin Shah 답변에 따르면 URL의 도메인 부분은 대소 문자를 구분하지 않으므로

http://google.com 

과

http://GOOGLE.COM 

과

http://GoOgLe.CoM 

모두 동일하지만 도메인 이름 부분 뒤의 모든 항목은 대소 문자를 구분합니다.

그래서...

http://GOOGLE.COM/ABOUT

과

http://GOOGLE.COM/about

다르다.

참고 : 많은 경우에 "기술적으로"말하고 "문자 적으로"말하지 않습니다. 대부분의 경우 서버는 이러한 항목을 동일하게 처리하도록 설정되어 있지만 동일하게 처리되지 않도록 설정할 수 있습니다.

다른 서버는 이것을 다르게 처리하며 경우에 따라 대소 문자를 구분해야합니다. 많은 경우 쿼리 문자열 값이 인코딩됩니다 (예 : 쿼리 문자열 값으로 전달 된 세션 ID 또는 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

이 가상의 예에서 GET 메소드를 사용하는 HTML 양식은 "name"매개 변수를 새 사용자 계정을 작성하는 PHP 스크립트로 보냅니다.

이 예제를 사용하여 작성하는 요점은 "McCartney"의 대문자를 유지하려면 (또는 다른 방법으로 "Walter d' Isney"를 유지하려면이 GET 매개 변수는 대소 문자를 구분해야 함) 이름이 일반적인 대문자 사용 규칙을 위반하는 경우).

스키마와 호스트는 대소 문자를 구분하지 않는 W3C 권장 사항을 안내하는 경우와 같은 경우이지만 그 이후의 모든 항목은 대소 문자를 구분하며 서버에 맡겨집니다. 표준에 따라 대소 문자를 구분하지 않으면 위의 예에서 GET 쿼리 매개 변수로 전달 된 사용자 입력의 대소 문자를 보존 할 수 없습니다.

그러나 내가 말하는 것은 이것이 반드시 그러한 경우를 수용하는 법의 서한이지만, 법의 정신은 사건이 관련이없는 경우 대소 문자를 구분하지 않는 방식으로 행동한다는 것입니다. 그러나 표준은 내가 제시 한 예제와 같이 상황에 따라 달라지기 때문에 사례가 관련이없는 곳을 알려줄 수 없습니다.

(예 : 위와 같이 실제 이름이 대소 문자를 구분하는 것이 가장 좋지만 다른 계정 인 "User123"과 "user123"은 혼동을 일으킬 수 있으므로 계정 사용자 이름은 대소 문자를 구분하지 않는 것이 가장 좋습니다.

때로는 관련이 있지만 대부분 관련이 없습니다. 그러나 서버 / 웹 개발자는 이러한 사항을 결정해야하며, 해당 수준에서만 컨텍스트를 알 수 있기 때문에 표준으로 규정 할 수 없습니다.

체계와 호스트는 대소 문자를 구분하지 않습니다 (일반적으로 처방 될 수있는 대소 문자를 구분하지 않는 표준의 선호도를 보여줍니다). 문맥을 더 잘 이해하면 나머지는 결정해야 할 책임이 있습니다. 그러나 논의 된 바와 같이, 법의 정신에 따라, 정당한 이유가없는 한, 기본적으로 대소 문자를 구분하지 않아야합니다.

그렇지 않은 적절한 이유가없는 한 URL은 대소 문자를 구분하지 않아야합니다.

필수 사항은 아니지만 (RFC의 일부는 아님) URL의 통신 및 저장을 훨씬 더 안정적으로 만듭니다.

웹 사이트에 두 페이지가있는 경우 :

http://stackoverflow.com/ABOUT.html

과

http://stackoverflow.com/about.html

그것들은 어떻게 다릅니 까? 어쩌면 하나는 '소리 스타일'(모자)로 쓰여질 수도 있지만 IA 관점에서 URL의 경우 변경을 통해 구별해서는 안됩니다.

또한 아파치에서 이것을 쉽게 구현할 수 CheckSpelling On있습니다-mod_Speling에서 사용 하십시오.

오래된 질문이지만 나는 여기에서 우연히 발견되었으므로 질문이 다양한 관점을 추구하고 결정적인 대답이 아니기 때문에 왜 그것을 쏘지 않겠습니까?

w3c는 권장 사항이있을 수 있습니다. 많은 관심이 있지만 질문이 있기 때문에 다시 생각하고 싶습니다.

왜 w3c는 도메인 이름이 대소 문자를 구분하지 않는 것으로 간주하고 이후에 대소 문자를 구분하지 않습니까?

그 근거는 URL의 도메인 부분이 사용자가 직접 입력한다는 것입니다. 하이퍼 텍스트가 된 후의 모든 것은 머신 (뒷면의 브라우저 및 서버)에 의해 해결됩니다.

기계는 사람보다 대소 문자 구분을 잘 처리 할 수 ​​있습니다 (기술적 인 종류가 아님).

그러나 문제는 기계가 그렇게 할 수있는 것을 처리 할 수 ​​있기 때문입니다.

나는 hereIsTheResourcevs에 있는 리소스의 이름을 지정하고 액세스하면 어떤 이점이 hereistheresource있습니까?

측면은 더 읽기 쉬운 낙타 경우보다 읽을 수 없습니다. 사람이 읽을 수 있음 (기술적 인 종류 포함)

그래서 여기 내 요점이 있습니다 :-

리소스 경로는 프로그래밍 구조의 중간에 있으며 때로는 브라우저 뒤의 최종 사용자와 가깝습니다.

사용자가 URL을 만지거나 입력해야하는 경우 URL (도메인 이름 제외)은 대소 문자를 구분하지 않아야합니다. 사용자가 가능한 한 경로를 입력하도록 AVOID로 응용 프로그램을 개발해야합니다.

사용자가 직접 입력하지 않으면 URL (도메인 이름 제외)은 대소 문자를 구분해야합니다.

결론

경로는 대소 문자를 구분해야합니다. 내 요점은 대소 문자를 구분하는 경로를 향해 가고 있습니다.

URL 문자는 16 진수 코드로 변환되며 (URL에서 공백이 % 20 등으로 표시되는 것을 본 적이있는 경우), 소문자와 16 진수 값이 다르므로 URL은 대소 문자를 구분하는 것이 가장 좋습니다. 그러나 질문의 ​​정신은 표준이되어야하며 나는 아니오라고 말하지만, 그렇지 않습니다. 최종 사용자와 관계없이 작동하게하려면 코드에서이를 설명하는 것은 개발자 / 제공자에게 달려 있습니다.

나는 스펙이 말하거나 말하지 않은 것에 대한 이것과 많은 대답이 질문의 요점을 놓치고 있다고 생각합니다. 대소 문자를 구분 해야합니까 ? 정말로드 된 질문입니다. 사용자의 관점에서 대소 문자 구분은 고통의 포인트이며 모두가 차이를 만드는 것은 아닙니다. URI의 유무에 대한 질문은 질문의 맥락에 따라 다릅니다. 기술적 인 유연성을 위해서는 그렇습니다. 유용성을 위해, 아닙니다.

사례 보존

URL은 클라이언트와 서버 사이에서 대소 문자를 보존 합니다. 그러나 몇 가지 이유로 URL의 일부는 서버에 따라 대소 문자를 구분 하거나 구분 하지 않을 수 있습니다 .

대소 문자 구분

사이트 및 / 또는 서버 구성에 따라 다음과 같이 굵게 표시된 URL 부분은 대소 문자 를 구분할 수 있습니다.

    http : // www. example.com /abc/def.ghi?jkl=mno#pqr

    사용자 @ example.com

이론적 해석

URL의 대소 문자 구분은 여러 가지 용도로 사용될 수 있습니다. 주로:

1. 대소 문자 구분 파일 시스템과의 기본 호환성.
2. 직렬화, 해싱, ID, 영구 링크 및 URL 단축기와 같이 URL 내에서보다 컴팩트 한 데이터 인코딩

개발자는 위의 내용을 더 나은 방법으로 처리 할 수 ​​있다고 생각하지만 상황에 따라 허용되지 않는 경우도 있음을 이해합니다.

예를 들어, "GET"URL에 많은 양의 데이터가 필요하지만 모든 주요 서버, 브라우저 및 캐싱 / 프록시 메커니즘의 최대 URL 길이와 호환되어야하는 기존 제품을 상상해보십시오. 적당한 길이의 명령 문자열 (일부 구형 브라우저의 경우 1,024 자 미만)에도 맞추려면 가능한 모든 고유 한 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 Server에서 FOLDER의 이름을 지정할 때와 같이 URL은 대소 문자를 구분하지 않으며 동일한 위치로 리디렉션됩니다.

대소 문자를 구분하지 않는 URL을 만들 수 있습니다

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

Google.com..GOOGLE.com 등을 google.com으로 직접 만들기