난 그것을 알아 챘다
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″은 혼동을 일으킬 수 있으므로 계정 사용자 이름은 대소 문자를 구분하지 않는 것이 가장 좋습니다.
때로는 관련이 있지만 대부분 관련이 없습니다. 그러나 서버 / 웹 개발자는 이러한 사항을 결정해야하며, 해당 수준에서만 컨텍스트를 알 수 있기 때문에 표준으로 규정 할 수 없습니다.
체계와 호스트는 대소 문자를 구분하지 않습니다 (일반적으로 처방 될 수있는 대소 문자를 구분하지 않는 표준의 선호도를 보여줍니다). 문맥을 더 잘 이해하면 나머지는 결정해야 할 책임이 있습니다. 그러나 논의 된 바와 같이, 법의 정신에 따라, 정당한 이유가없는 한, 기본적으로 대소 문자를 구분하지 않아야합니다.
