URL이 대소 문자를 구분하는 이유는 무엇입니까?

내 질문 : URL을 처음 디자인 할 때 대 / 소문자를 구분 한 이유는 무엇입니까? 필자는 불필요 한 오류를 방지하고 이미 복잡한 텍스트 문자열을 단순화하기 위해 대소 문자를 구분하지 않는 것이 나 (즉, 평신도)에게 보이기 때문에 이것을 묻습니다.

또한 대소 문자에 상관없이 동일한 페이지를 가리키는 대부분의 URL과 달리 대소 문자를 구분하는 URL을 사용하는 실질적인 목적 / 장점이 있습니까?

예를 들어 Wikipedia는 대소 문자를 구분하는 웹 사이트입니다 (첫 번째 문자 제외).

https://en.wikipedia.org/wiki/St ck_Exchange는 DOA입니다.

URL이 대소 문자를 구분하지 않는 이유는 무엇입니까?

나는 그것이 도발적인 (그리고 "악마의 옹호자") 유형의 수사적 질문처럼 보일 수도 있지만, 고려하는 것이 유용하다고 생각합니다. HTTP의 디자인은 일반적으로 "웹 브라우저"라고하는 "클라이언트"는 "웹 서버"에 데이터를 요청하는 것입니다.

릴리스 된 많은 다른 웹 서버가 있습니다. Microsoft는 Windows Server 운영 체제 (및 Windows XP Professional을 포함한 기타)와 함께 IIS를 출시했습니다. 유닉스에는 OpenBSD의 내부 httpd, thttpd 또는 lighttpd와 같은 더 작은 오퍼링은 말할 것도없고 nginx 및 Apache와 같은 헤비급이 있습니다. 또한 많은 네트워크 가능 장치에는 라우터 (많은 Wi-Fi 액세스 포인트 및 DSL 모뎀 포함)와 같은 네트워크 전용 장치 및 프린터 나 네트워크 연결이 가능한 UPS (배터리 기반 무정전 전원 공급 장치).

"URL이 대소 문자를 구분하는 이유는 무엇입니까?"라는 질문은 "웹 서버가 URL을 대소 문자를 구분하는 이유는 무엇입니까?"입니다. 그리고 실제 대답은 : 그들이 전부는 아닙니다. 상당히 인기있는 하나 이상의 웹 서버는 일반적으로 대소 문자를 구분하지 않습니다. (웹 서버는 IIS입니다.)

서로 다른 웹 서버간에 서로 다른 동작을하는 주요 이유는 단순성의 문제 일 수 있습니다. 웹 서버를 만드는 간단한 방법은 컴퓨터 / 장치 운영 체제가 파일을 찾는 방법과 같은 방식으로 작업하는 것입니다. 많은 경우, 웹 서버는 응답을 제공하기 위해 파일을 찾습니다. Unix는 고급 컴퓨터를 중심으로 설계되었으므로 Unix는 대문자와 소문자를 허용하는 바람직한 기능을 제공했습니다. 유닉스는 대문자와 소문자를 다르게 처리하기로 결정했습니다. 그것은 간단하고 자연스러운 일입니다. Windows는 이미 작성된 소프트웨어를 지원하려는 욕구 때문에 대소 문자를 구분하지 않은 이력을 가지고 있으며,이 이력은 단순히 소문자를 지원하지 않은 DOS로 되돌아갑니다. 적은 메모리를 사용하는 덜 강력한 컴퓨터로 작업을 단순화하기 위해 노력하고 있습니다. 이러한 운영 체제가 다르기 때문에 단순하게 설계된 (이전 버전의) 웹 서버는 동일한 차이점을 반영합니다.

이제 모든 배경 지식을 바탕으로 구체적인 질문에 대한 몇 가지 구체적인 답변이 있습니다.

URL을 처음 디자인 할 때 대 / 소문자를 구분 한 이유는 무엇입니까?

왜 안돼? 모든 표준 웹 서버가 대소 문자를 구분하지 않으면 웹 서버가 표준에 지정된 일련의 규칙을 따르고 있음을 나타냅니다. 그 사건을 무시해야한다는 규칙은 없었습니다. 규칙이없는 이유는 단순히 그러한 규칙이있을 이유가 없기 때문입니다. 왜 불필요한 규칙을 만들려고 귀찮게합니까?

필자는 불필요 한 오류를 방지하고 이미 복잡한 텍스트 문자열을 단순화하기 위해 대소 문자를 구분하지 않는 것이 나 (즉, 평신도)에게 보이기 때문에 이것을 묻습니다.

URL은 기계가 처리하도록 설계되었습니다. 사람은 주소 표시 줄에 전체 URL을 입력 할 수 있지만 의도 한 디자인의 주요 부분은 아닙니다. 의도 된 디자인은 사람들이 하이퍼 링크를 따라갈 수 있도록하는 것입니다. 평범한 평신도들이 그렇게하고 있다면, 보이지 않는 URL이 단순하거나 복잡한 지 상관하지 않습니다.

또한 대소 문자에 상관없이 동일한 페이지를 가리키는 대부분의 URL과 달리 대소 문자를 구분하는 URL을 사용하는 실질적인 목적 / 장점이 있습니까?

윌리엄 헤이 (William Hay)의 답변에서 다섯 번째로 지적 된 점은 기술적 이점이 있습니다. URL은 웹 브라우저가 웹 서버에 약간의 정보를 전송하는 효과적인 방법이 될 수 있으며 제한이 적 으면 더 많은 정보가 포함될 수 있으므로 대소 문자 구분 제한은 포함 할 수있는 정보의 양을 줄입니다.

그러나 대부분의 경우 대 / 소문자 구분에 대한 강력한 이점은 없습니다. 이는 일반적으로 IIS가이를 방해하지 않는다는 사실에 의해 입증됩니다.

요약하자면, 가장 강력한 이유는 웹 서버 소프트웨어를 디자인 한 사람들, 특히 유닉스와 같이 대소 문자를 구분하는 플랫폼에서 간단 할 것입니다. (유닉스가 특히 HTTP보다 오래 되었기 때문에 HTTP는 Unix의 원래 디자인에 영향을 미치지 않았습니다.)

URL은 대소 문자를 구분하지 않으며 일부만 구분합니다.
예를 들어 URL에서 대소 문자를 구분하는 것은 없습니다 https://google.com.

을 참조 일반 구문 :이 URI (Uniform Resource Identifier) - RFC 3986

먼저 Wikipedia 에서 URL은 다음과 같습니다.

 scheme:[//host[:port]][/]path[?query][#fragment]

( user:password흥미롭지 않고 거의 사용되지 않기 때문에 부분을 제거했습니다 )

• scheme:

체계는 대소 문자를 구분하지 않습니다

• host:

호스트 하위 구성 요소는 대소 문자를 구분하지 않습니다.

• path:

경로 구성 요소에 데이터가 포함되어 있습니다.

• query:

쿼리 구성 요소에 비 계층 데이터가 포함되어 있습니다.

• fragment:

개별 미디어 유형은 다른 유형의 서브 세트, 뷰 또는 외부 참조를 지정하기 위해 프래그먼트 식별자 구문 내에서 자체 제한 또는 구조를 정의 할 수 있습니다.

그래서, scheme그리고 host대소 문자를 구별하지 않는다.
나머지 URL은 대소 문자를 구분합니다.

path대소 문자를 구분 하는 이유는 무엇 입니까?

이것이 주요 질문 인 것 같습니다. 문서화되지 않은 경우 왜 " 무엇을 "했는지
대답하기는 어렵지만 우리는 아주 좋은 추측을 할 수 있습니다. 나는 data에 중점을 두어 스펙에서 매우 구체적인 따옴표를 선택했습니다 . URL을 다시 보자.

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data

• 위치-위치는 정식 형식이며 대소 문자를 구분하지 않습니다. 왜? 아마도 수천 개의 변형을 구매하지 않고도 도메인 이름을 구입할 수 있습니다.

• 데이터-데이터는 대상 서버에서 사용되며 응용 프로그램은 그 의미를 선택할 수 있습니다 . 대소 문자를 구분하지 않는 것이 이치에 맞지 않습니다. 응용 프로그램에는 더 많은 옵션이 있어야하며 사양에서 대 / 소문자를 구분하지 않으면 이러한 옵션이 제한됩니다.
  이는 HTTPS의 유용한 차이점이기도합니다. 데이터는 암호화 되지만 호스트는 표시됩니다.

유용합니까?

대 / 소문자 구분은 캐싱 및 정식 URL과 관련하여 함정이 있지만 확실히 유용합니다. 몇 가지 예 :

• 데이터 URI에 사용되는 Base64 .
• : 사이트, 예를 들어, URL에 Base64로 데이터를 인코딩 할 수 http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• URL 축약 대소 문자 구분을 활용 : /a5B다를 수 있습니다/a5b
• 언급했듯이 Wikipedia는 "AIDS"와 "Aids"를 구별 할 수 있습니다.

단순한. OS는 대소 문자를 구분합니다. 웹 서버는 일반적으로 특정 시점에 파일 시스템에 충돌하지 않는 한 신경 쓰지 않습니다. Linux 및 기타 Unix 기반 운영 체제가 파일 시스템의 규칙을 시행하는 경우가 중요합니다.이 경우 감도가 중요한 부분입니다. 이것이 IIS 가 대소 문자를 구분 한 적이없는 이유입니다 . Windows는 대소 문자를 구분하지 않았기 때문입니다.

[최신 정보]

내가 언급했듯이 URL이 파일 시스템과 어떤 관계가 있는지에 대한 의견에서 삭제 된 이후 몇 가지 강력한 주장이있었습니다. 이 논쟁은 뜨거워졌다. 관계가 없다고 믿는 것은 매우 근시안적입니다. 절대적으로 있습니다! 더 설명하겠습니다.

응용 프로그램 프로그래머는 일반적으로 시스템 내부 프로그래머가 아닙니다. 나는 모욕하지 않습니다. 이들은 두 가지 별도의 분야이며, 응용 프로그램이 단순히 OS를 호출 할 수있는 경우 응용 프로그램을 작성하는 데 시스템 내부 지식이 필요하지 않습니다. 응용 프로그램 프로그래머는 시스템 내부 프로그래머가 아니므로 OS 서비스를 우회 할 수 없습니다. 나는 이것이 두 개의 별도 캠프이기 때문에 거의 교차하지 않기 때문에 이것을 말합니다. 응용 프로그램은 일반적으로 OS 서비스를 사용하도록 작성되었습니다. 물론 몇 가지 예외가 있습니다.

웹 서버가 나타나기 시작했을 때 응용 프로그램 개발자는 OS 서비스를 우회하지 않았습니다. 이에 대한 몇 가지 이유가있었습니다. 하나는 필요하지 않았습니다. 둘째, 응용 프로그램 프로그래머는 일반적으로 OS 서비스를 우회하는 방법을 알지 못했습니다. 셋째, 대부분의 OS는 매우 안정적이고 강력하거나 매우 단순하고 가벼우 며 비용이 들지 않았습니다.

초기 웹 서버는 DEC VAX / VMS 서버 및 유닉스와 같은 고가의 컴퓨터 (Berkeley 및 Ultrix 및 기타)를 메인 프레임 또는 미드 프레임 컴퓨터에서 실행 한 다음 곧 작동합니다. PC 및 Windows 3.1과 같은 경량 컴퓨터. 1997/8 년 구글과 같은 최신 검색 엔진이 등장하기 시작하자 Windows는 Windows NT로 옮겨졌고 Novell 및 Linux와 같은 다른 OS도 웹 서버를 실행하기 시작했습니다. 아파치 (Apache)는 지배적 인 웹 서버 였지만 IIS와 O'Reilly와 같은 다른 서버도 매우 인기가있었습니다. 당시에는 어느 것도 OS 서비스를 우회하지 않았습니다. 오늘날에도 웹 서버 중 어느 것도 수행하지 않을 수 있습니다.

초기 웹 서버는 매우 간단했습니다. 그들은 여전히 ​​오늘입니다. 하드 드라이브에 존재하는 HTTP 요청을 통해 리소스에 대한 모든 요청은 OS 파일 시스템을 통해 웹 서버에 의해 이루어졌습니다.

파일 시스템은 단순한 메커니즘입니다. 파일에 대한 액세스 요청이 수행 될 때 해당 파일이 존재하면 요청이 권한 부여 서브 시스템으로 전달되고 부여 된 경우 원래 요청이 충족됩니다. 자원이 없거나 권한이 없으면 시스템에서 예외가 발생합니다. 애플리케이션이 요청하면 트리거가 설정되고 애플리케이션이 대기합니다. 요청에 응답하면 트리거가 발생하고 애플리케이션이 요청 응답을 처리합니다. 오늘날에도 여전히 그렇게 작동합니다. 응용 프로그램에서 요청이 충족 된 것으로 확인되면 계속하고, 실패하면 응용 프로그램 코드 내에서 오류 조건을 실행하거나 처리하지 않으면 죽습니다. 단순한.

웹 서버의 경우, 경로 / 파일에 대한 URL 요청이 있다고 가정하면 웹 서버는 URL 요청 (URI)의 경로 / 파일 부분을 가져 와서 파일 시스템에 요청하고 만족합니다. 또는 예외를 던집니다. 그런 다음 웹 서버는 응답을 처리합니다. 예를 들어, 요청 된 경로 및 파일이 발견되고 권한 부여 서브 시스템이 액세스 권한을 부여하면 웹 서버는 해당 I / O 요청을 정상적으로 처리합니다. 파일 시스템에서 예외가 발생하면 파일을 찾을 수 없으면 웹 서버가 404 오류를, 이유 코드가 인증되지 않은 경우 403 금지를 리턴합니다.

일부 OS는 대소 문자를 구분하며이 유형의 파일 시스템은 정확히 일치해야하므로 웹 서버에 요청 된 경로 / 파일은 하드 드라이브에 존재하는 경로와 정확하게 일치해야합니다. 그 이유는 간단합니다. 웹 서버는 당신이 무엇을 의미하는지 추측하지 않습니다. 프로그래밍되지 않은 컴퓨터는 없습니다. 웹 서버는 요청을 수신 할 때 간단히 처리합니다. 파일 시스템으로 직접 전달되는 URL 요청의 경로 / 파일 부분이 하드 드라이브의 경로 / 파일 부분과 일치하지 않으면 파일 시스템에서 예외가 발생하고 웹 서버는 404 Not Found 오류를 반환합니다.

정말 단순한 사람들입니다. 로켓 과학이 아닙니다. URL의 경로 / 파일 부분과 파일 시스템 간에는 절대적인 관계가 있습니다.

1. URL은 UNIFORM 리소스 로케이터라고 주장하며 웹 이전의 리소스를 가리킬 수 있습니다. 이 중 일부는 대소 문자를 구분하며 (예 : 많은 ftp 서버) URL은 이러한 리소스를 합리적으로 직관적으로 표현할 수 있어야합니다.

2. 대소 문자를 구분하지 않으면 일치하는 항목 (OS 또는 그 이상)을 찾을 때 더 많은 작업이 필요합니다.

3. URL을 대소 문자를 구분하여 정의하면 개별 서버는 URL을 대소 문자를 구분하지 않고 구현할 수 있습니다. 그 반대입니다.

4. https://en.wikipedia.org/wiki/Dotted_and_dotless_I 국제 상황에서는 대소 문자를 구분하지 않아도됩니다 . 또한 RFC1738은 인코딩되었지만 문자 집합을 지정하지 않은 경우 ASCII 범위 밖의 문자를 사용할 수있었습니다. 이것은 WORLD 와이드 웹 자체를 호출하는 데 매우 중요합니다. 대소 문자를 구분하지 않는 URL을 정의하면 버그의 범위가 넓어집니다.

5. 많은 양의 데이터를 URI (예 : Data URI ) 로 묶으려는 경우 대문자와 소문자가 다른 경우 더 많이 묶을 수 있습니다.

나는 Old New Thing 블로그에서 "왜 그런가?"라는 형식의 질문에 접근하는 습관을 훔쳤습니다. 반대 질문으로 "세상이 아니라면 세상은 어떨까?"

내가 사무실에있을 때 전화로 읽을 수 있도록 폴더에서 내 문서 파일을 제공하도록 웹 서버를 설정했다고 가정 해 봅시다. 이제, 내 문서 폴더에, 나는 세 개의 파일을 가지고 todo.txt, ToDo.txt그리고 TODO.TXT(나는 알고있다,하지만 난 파일을 만들 때 그것은 나에게 이해했다).

이 파일에 액세스하기 위해 어떤 URL을 사용하고 싶습니까? 을 사용하여 직관적 인 방식으로 액세스하고 싶습니다 http://www.example.com/docs/filename.

웹을 통해 주소록에 연락처를 추가 할 수있는 스크립트가 있다고 가정 해 봅시다. 어떻게 매개 변수를 취해야합니까? 글쎄, 나는 그것을 다음과 같이 사용하고 싶다 : http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly. 그러나 사례별로 이름을 지정할 방법이 없다면 어떻게해야합니까?

Cat 및 CAT, 텍스트 및 텍스트, 라텍스 및 LaTeX의 위키 페이지를 어떻게 차별화합니까? Disambig 페이지는 추측하지만 원하는 것을 얻는 것을 선호합니다.

그러나 어쨌든 그것은 잘못된 질문에 대답하는 것처럼 느껴집니다.

당신이 정말로 묻고있는 질문은 "웹 서버 (404)가 왜 컴퓨터 일 때, 삶을 더 단순하게 만들도록 설계되었으며, 가장 명확한 대소 문자 변화를 완벽하게 찾을 수있는 이유는 무엇입니까? 입력 한 URL이 작동합니까? "

이에 대한 대답은 일부 사이트 에서이 작업을 수행했지만 다른 오타도 확인하는 반면 웹 서버의 기본 404 오류 페이지를 변경하여 그럴 가치가 있다고 생각한 사람은 아무도 없습니다.

위의 대답은 정확하고 좋습니다. 포인트를 더 추가하고 싶습니다.

더 잘 이해하려면 Unix (Linux) Vs Windows 서버의 기본적인 차이점을 이해해야합니다. 유닉스는 대소 문자를 구분하며 Windows는 대소 문자를 구분하지 않는 OS입니다.

HTTP 프로토콜은 1990 년 무렵에 발전하거나 구현되기 시작했습니다. HTTP 프로토콜은 CERN 연구소에서 근무하는 엔지니어에 의해 설계되었습니다. 당시 대부분의 과학자들은 Windows가 아닌 Unix 머신을 사용했습니다.

대부분의 과학자는 Unix에 익숙하므로 Unix 스타일 파일 시스템에 영향을 받았을 수 있습니다.

Windows 서버는 2000 년 이후에 출시되었습니다. Windows 서버가 널리 사용되기 훨씬 전에 HTTP 프로토콜이 완성되어 사양이 완성되었습니다.

이것이 이유 일 수 있습니다.

"왜 이런 식으로 설계 되었습니까?" 질문? 역사적으로 정확한 의사 결정 과정을 요구하고 있습니까, 아니면 "왜 이런 식으로 설계하겠습니까?"

역사적으로 정확한 계정을 얻는 것은 거의 불가능합니다. 때때로 표준위원회에서 결정을 내릴 때 토론이 진행된 방법에 대한 기록적인 흔적이 있지만 웹 초기 초반에는 소수의 개인이 (이 경우 아마도 TimBL 자신이) 결정을 내 렸으며 그 근거는 거의 없을 것입니다. 적어졌습니다. 그러나 TimBL은 URL 디자인에 실수를했다는 것을 인정했습니다. http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address를 참조 하십시오 -mistake.html

초기에는 URL이 파일 이름에 매우 직접 매핑되었으며 파일은 일반적으로 Unix와 유사한 컴퓨터에 있었고 Unix와 같은 컴퓨터에는 대소 문자를 구분하는 파일 이름이 있습니다. 그래서 제 생각에는 구현 편의를 위해 그 방법이 생겼으며 (최종 사용자의 경우) 유용성은 고려되지 않았습니다. 어쨌든 사용자는 어쨌든 모든 유닉스 프로그래머였습니다.

이것은 도메인을 구입 한 곳과 관련이 없으며 DNS는 대소 문자를 구분하지 않습니다. 그러나 호스팅에 사용중인 서버의 파일 시스템은입니다.

이것은 실제로 문제가되지 않으며 * nix 호스트에서 상당히 일반적입니다. 페이지에 작성한 모든 링크가 올바른지 확인하고 문제가 없는지 확인하십시오. 더 쉽게하기 위해 항상 페이지 이름을 모두 소문자로 지정하는 것이 좋습니다. 그러면 링크를 작성할 때 이름을 다시 확인할 필요가 없습니다.

Closetnoc은 OS에 관한 것입니다. 일부 파일 시스템은 다른 이름으로 다른 이름을 가진 동일한 이름을 다른 파일로 취급합니다.

또한 대소 문자에 상관없이 동일한 페이지를 가리키는 대부분의 URL과 달리 대소 문자를 구분하는 URL을 사용하는 실질적인 목적 / 장점이 있습니까?

예. 중복 콘텐츠 문제를 피하기 위해.

예를 들어 다음 URL이있는 경우 :

http://example.com/page-1
http://example.com/Page-1
http://example.com/paGe-1
http://example.com/PAGE-1
http://example.com/pAGE-1

그리고 그들은 모두 정확히 동일한 내용을 가진 동일한 페이지를 가리키면 중복 된 내용을 갖게 될 것입니다. Google 검색 콘솔 (웹 마스터 도구) 계정이 있다면 Google에서이를 알려줄 것입니다.

당신이 그 상황에 있다면 내가 제안하는 것은 모든 소문자 URL을 사용하고 적어도 하나의 대문자가있는 URL을 소문자 버전으로 리디렉션하는 것입니다. 따라서 위의 URL 목록에서 모든 URL을 첫 번째 URL로 리디렉션하십시오.

대소 문자 구분은 가치가 있습니다.

글자가 26자인 경우 각각 대문자를 사용하는 능력이 52 자입니다.

4 개의 문자는 52 * 52 * 52 * 52 조합이 가능하며 7311616 조합과 같습니다.

문자를 대문자로 표시 할 수없는 경우 조합 량은 26 * 26 * 26 * 26 = 456976입니다.

26 자보다 52 자 이상으로 14 배 이상 더 많은 조합을 사용할 수 있습니다. 따라서 데이터를 저장하기 위해 Urls가 더 짧아지고 더 적은 정보가 전송되는 네트워크를 통해 더 많은 정보가 전달 될 수 있습니다.

이것이 https://www.youtube.com/watch?v=xXxxXxxX 와 같은 URL을 사용하여 YouTube를 보는 이유입니다.