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

그렇게하지 않는 이유 URL은 대소 문자를 구분합니까?

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

많은 웹 서버가 출시됩니다. Microsoft는 Windows와 함께 IIS를 출시했습니다. 서버 운영 체제 (및 Windows XP Professional을 포함한 기타) Unix는 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가 일반적으로 문제를 해결하지 않는다는 사실에 의해 입증되었습니다.

요약하면, 웹 서버 소프트웨어를 설계 한 사람들, 특히 Unix와 같은 대소 문자를 구분하는 플랫폼에서 가장 설득력있는 이유는 단순함 일 가능성이 높습니다. . (유닉스는 HTTP보다 훨씬 오래 되었기 때문에 HTTP는 Unix의 원래 디자인에 영향을주지 않았습니다.)

댓글

• ” 다른 웹 브라우저 간에 서로 다른 동작을하는 주요 이유는 아마도 단순성 문제로 귀결 될 수 있습니다. “-당신을 가정합니다. ” 웹 브라우저 iv id = “0b599e20a1가 아닌 ” 웹 서버 “를 의미합니다. “>

URL은 대소 문자를 구분하지 않고 일부만 구분합니다.
예를 들어 URL https://google.com,

에서는 대소 문자를 구분하지 않습니다. RFC 3986-URI (Uniform Resource Identifier) : 일반 구문

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

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

(user:password 부분은 흥미롭지 않고 거의 사용되지 않기 때문입니다.)

• scheme :

스키마는 대소 문자를 구분하지 않습니다.

• host :

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

• path :

경로 구성 요소 데이터 포함 …

• query :

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

• fragment :

개별 미디어 유형은 다양한 유형의 하위 집합,보기 또는 외부 참조를 지정하기 위해 조각 식별자 구문 내에서 자체 제한 또는 구조를 정의 할 수 있습니다.

따라서 scheme 및 host는 대소 문자를 구분하지 않습니다.
나머지 URL은 대소 문자를 구분합니다.

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

주요 질문 인 것 같습니다.
대답하기 어렵습니다. “why” 문서화되지 않은 경우 어떤 작업이 수행되었지만 우리는 아주 좋은 추측을 할 수 있습니다.
저는 데이터 .
URL을 다시 살펴 보겠습니다.

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

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

• 데이터-데이터는 대상 서버와 애플리케이션이 의미를 선택할 수 있습니다 . 데이터 대소 문자를 구분하지 않는 것은 의미가 없습니다. 애플리케이션에는 더 많은 옵션이 있어야하며 사양에서 대소 문자 구분을 정의하면 이러한 옵션이 제한됩니다.
  이는 HTTPS의 유용한 구분이기도합니다. 데이터는 암호화되지만 호스트는 표시됩니다.

유용합니까?

사례- 민감도는 캐싱 및 표준 URL과 관련하여 함정이 있지만 확실히 유용합니다. 몇 가지 예 :

• Base64 , 데이터 URI 에서 사용됩니다.
• 사이트는 URL에 Base64 데이터를 인코딩 할 수 있습니다. 예 : http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• URL 단축기는 대소 문자 구분을 활용합니다. /a5B는 /a5b
• 지금까지 언급했듯이 Wikipedia는 “AIDS”와 “Aids”를 구분할 수 있습니다.

댓글

• ” URL은 CAS가 아닙니다. 전자를 구분합니다. ” / ” 나머지 URL은 대소 문자를 구분합니다. “-이것은 모순처럼 보입니까?
• 사실,이 스키마는 나머지 URL에서 무엇을 기대할 수 있는지 정의합니다. http: 및 관련 체계는 URL이 DNS 호스트 이름을 참조 함을 의미합니다. DNS는 URL이 발명되기 훨씬 전에 ASCII 대소 문자를 구분하지 않았습니다. ietf.org/rfc/rfc883.txt

의 55 페이지를 참조하세요.

• 정말 상세합니다! 나는 역사적인 관점에서 가고 있었다. 원래 파일 시스템을 사용하는 경우에만 대소 문자를 구분해야하는 파일 경로였습니다. 그렇지 않으면 그렇지 않았습니다. 하지만 오늘은 상황이 바뀌 었습니다. 예를 들어, 매개 변수와 CGI는 원래 존재하지 않았습니다. 귀하의 답변은 현재의 관점을 취합니다. 당신의 노력에 보답해야했습니다 !! 당신은 정말 이것에 대해 파고 들었습니다! 이것이 그랬던 것처럼 폭발 할 것이라는 것을 누가 알았습니까 ?? 건배 !!
• @ w3dk : ‘별로 흥미로운 용어는 아니지만 ” 대소 문자 구분 ” 즉, ” 문자의 대소 문자를 변경하면 전체가 변경 될 수 있습니다. ” 또는 ” 문자의 대소 문자를 항상 변경하면 전체가 “. Kobi는 후자를 주장하는 것 같습니다. 그는 대소 문자 구분이 ” 대소 문자 변경이 중요하다는 것을 ” 의미하는 것을 선호합니다. URL에는 해당되지 않습니다. 당신은 전자를 선호합니다. ‘ 대소 문자를 어떻게 민감하게하는지의 문제입니다.
• @ rybo111 : 사용자가 example.com/fOObaR , 사양에 따라 www.example.com의 서버가 ” / fOObaR “; 서버가 ” / foOBaR “와 다르게 처리해야하는지에 대한 질문에 대해서는 침묵합니다.

간단합니다. OS는 대소 문자를 구분합니다. 웹 서버는 일반적으로 특정 지점에서 파일 시스템에 도달하지 않는 한 상관하지 않습니다. Linux 및 기타 Unix 기반 운영 체제가 대소 문자 구분이 중요한 파일 시스템의 규칙을 적용하는 곳입니다. 이것이 IIS 가 대소 문자를 구분하지 않은 이유입니다. Windows는 대소 문자를 구분하지 않았기 때문입니다.

[업데이트]

제가 언급 한대로 URL이 파일 시스템과 관계가 있는지 여부에 대한 의견 (삭제 이후)에 몇 가지 강력한 주장이 있습니다. 이러한 논쟁은 뜨거워졌습니다. 관계가 없다고 믿는 것은 극도로 근시안적입니다. 절대적으로 있습니다! 자세히 설명하겠습니다.

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

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

초기 웹 서버는 DEC VAX /와 같은 값 비싼 컴퓨터에서 실행되었습니다. VMS 서버와 오늘의 Unix (Berkeley 및 Ultrix 및 기타)는 메인 프레임 또는 미드 프레임 컴퓨터에서, 그리고 곧 PC 및 Windows 3.1과 같은 경량 컴퓨터에서 사용됩니다. 1997/8의 Google과 같은 최신 검색 엔진이 등장하기 시작했을 때 Windows는 Windows NT로 이동했으며 Novell 및 Linux와 같은 다른 OS에서도 웹 서버를 실행하기 시작했습니다. Apache가 지배적 인 웹 서버 였지만 IIS 및 O “Reilly와 같이 매우 인기가 많았습니다. 당시에는 OS 서비스를 우회 한 사람이 없었습니다. 오늘날에도 웹 서버 중 어느 것도 수행하지 않는 것 같습니다.

초기 웹 서버는 매우 단순했습니다. 오늘날에도 마찬가지입니다. 하드 드라이브에있는 HTTP 요청을 통해 리소스에 대한 요청은 OS 파일 시스템을 통해 웹 서버에 의해 이루어졌습니다.

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

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

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

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

댓글

• 당신의 주장에 결함이 있다고 생각합니다. Berners-Lee는 ‘ ftp URL의 대소 문자 구분에 대해 선택할 수 없었습니다. 그는 http URL을 디자인해야했습니다. US-ASCII로만 지정하고 대소 문자를 구분하지 않을 수 있습니다. URL 경로를 파일 시스템에 전달한 웹 서버가 있다면 안전하지 않았고 URL 인코딩의 도입으로 인해 이들과의 호환성이 깨졌습니다. 경로가 처리되고 있다는 점을 감안하면 OS 스매싱 케이스에 전달하기 전에 구현하기 쉬웠을 것입니다. 따라서 우리는 이것을 구현상의 문제가 아닌 디자인 결정으로 간주해야한다고 생각합니다.
• @WilliamHay 이것은 Berners-Lee 나 웹 디자인과는 아무런 관련이 없습니다. OS의 한계와 요구 사항에 관한 것입니다. 저는 은퇴 한 시스템 내부 엔지니어입니다. 나는 당시 이러한 시스템에서 작업했습니다. URL이 대소 문자를 구분하는 이유를 정확히 말씀드립니다. 추측이 아닙니다. 의견이 아닙니다. 그것은 사실이다. 내 대답은 의도적으로 단순화되었습니다. 물론 공개 문을 발행하기 전에 수행 할 수있는 파일 검사 및 기타 프로세스가 있습니다. 예 (!) 웹 서버는 그 결과 오늘날까지도 부분적으로 안전하지 않습니다.
• URL이 대소 문자를 구분하는지 여부는 웹 디자인과 관련이 없습니까? 정말? 권위의 주장에 이어 주장에 의한 주장.웹 서버가 URL의 경로 구성 요소를 공개 호출에 어느 정도 직접 전달하는 것은 URL의 원인이 아닌 디자인의 결과입니다. 서버 (또는 FTP의 경우 스마트 클라이언트)는 사용자에게 파일 시스템의 대소 문자 구분을 숨길 수 있습니다. ‘ 아니라는 것은 디자인 결정입니다.
• @WilliamHay 메뚜기 속도를 늦추고 제가 쓴 내용을 다시 읽어야합니다. 저는 은퇴 한 시스템 내부 엔지니어로 ARPA-Net 용 OS 구성 요소, 프로토콜 스택 및 라우터 코드를 작성하고 있습니다. Apache, O ‘ Reilly 및 IIS 내부 작업을 수행했습니다. 적어도 주요 FTP 서버는 동일한 이유로 대소 문자를 구분하므로 FTP 인수는 물을 유지하지 않습니다. URL / URI 디자인에 대해 아무 말도하지 않았습니다. 나는 웹 서버가 처리하지 않고 값을 전달했다고 말하지 않았습니다. 나는 OS 서비스가 일반적으로 사용되며 파일 시스템이 성공하기 위해서는 정확한 일치가 필요하다고 말했었습니다.
• @WilliamHay 당신과 나는 교차 목적을 생각하고 있다는 것을 이해하십시오. 내 대답에서 말한 것은 일부 OS의 경우 파일 시스템 호출이 설계 상 대소 문자를 구분한다는 것입니다. 시스템 호출을 사용하는 대부분의 애플리케이션은 OS 규칙 (이 경우 대소 문자 구분)의 적용으로 제한됩니다. 이 규칙을 우회하는 것은 불가능하지 않습니다. 실제로 이것은 실용적이지는 않지만 어떤 경우에는 다소 사소한 것일 수 있습니다. 나는 일상적으로 파일 시스템을 우회하여 어떤 이유로 든 kablooie가 된 하드 드라이브를 풀거나 데이터베이스 파일 내부를 분석하는 등의 작업을했습니다.

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

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

3. URL을 대소 문자를 구분하는 것으로 정의하면 개별 서버가 원하는 경우 대소 문자를 구분하지 않고 구현할 수 있습니다. 그 반대는 사실이 아닙니다.

4. 대소 문자 구분은 국제적 맥락에서 사소하지 않을 수 있습니다. https://en.wikipedia.org/wiki/Dotted_and_dotless_I 또한 RFC1738은 인코딩되었지만 문자 집합을 지정하지 않은 경우 ASCII 범위 밖의 문자 사용을 허용했습니다. 이것은 자체적으로 WORLD 와이드 웹을 호출하는 데 매우 중요합니다. 대소 문자를 구분하지 않는 URL을 정의하면 많은 범위가 열립니다. 버그.

5. URI에 많은 데이터를 압축하려는 경우 (예 : 데이터 URI ) 대문자와 소문자가 구별되면 더 많이 넣을 수 있습니다.

댓글

• I ‘ URL은 역사적으로 ASCII로 제한되어있었습니다. 따라서 국제화는 원래의 이유가 아닐 것입니다. Unix의 역사는 대소 문자를 구분하는 OTOH가 아마도 큰 역할을했을 것입니다.
• URL에서 인코딩되지 않은 ASCII 하위 집합 만 사용할 수 있지만 RFC1738은 특히 ASCII 범위 밖의 문자를 인코딩 할 수 있다고 명시합니다. 문자 집합을 지정하지 않으면 ‘ 알 수 없습니다. 동일한 문자를 나타내는 옥텟 사건을 제외한 행위자. 업데이트되었습니다.
• Re # 4 : ‘ 실제로 그보다 더 나쁩니다. 점이 있고 점이없는 나는 모든 것이 UTF-8 (또는 다른 UTF) 인 경우에도 텍스트가 속한 로케일을 모르면 대문자 나 소문자를 올바르게 사용할 수 없다는보다 일반적인 원칙을 보여줍니다. . 기본 로케일에서 대문자 I는 소문자 라틴 문자 i로 소문자로 바뀝니다. 이는 점을 추가하기 때문에 터키어에서는 잘못된 것입니다 (” 터키어 대문자 점없는 I ” 코드 포인트. ‘ ASCII 코드 포인트를 사용합니다.) 인코딩 차이를 고려하면 ” 정말 어려운 “에서 ” 완전히 다루기 어렵습니다. . ”

블로그에서 훔쳤습니다. 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와 같이 사용하고 싶습니다.하지만 이름을 대소 문자로 지정할 방법이 없다면 어떻게해야합니까?

고양이와 고양이, 텍스트와 텍스트, 라텍스와 LaTeX에 대한 위키 페이지를 어떻게 구별 할 수 있습니까? Disambig 페이지는 추측하지만 내가 요청한 것을 얻는 것을 선호합니다.

그러나 모든 느낌은 “어쨌든 잘못된 질문에 답하는 것처럼 요.

당신이 정말로 묻고있는 질문은”왜 웹 서버는 삶을 단순하게 만들도록 설계된 컴퓨터 일 때 대소 문자 차이를 위해 당신이 404를 하는가 , 그리고 그들은 내가 입력 한 URL에서 작동 할 가장 명백한 대소 문자 변형을 완벽하게 찾을 수 있습니까? “

대답은 일부 사이트에서이 작업을 수행했지만 더 나은 방법은 다른 오타도 확인하십시오.) 웹 서버의 기본 404 오류 페이지를 변경하는 것이 가치가 있다고 생각한 사람은 아무도 없습니다 …하지만 그렇게해야할까요?

코멘트

• 일부 사이트에서는 일종의 메커니즘을 사용하여 모두 소문자 또는 일관된 것에 대한 ny 쿼리. 어떤면에서 이것은 현명합니다.
• 아니요. ‘ t. 이 기능은 바람직 할 때 추가 될 수 있으며 종종 추가 될 수 있습니다 (예 : 아파치의 모듈에 의해). 이러한 종류의 변경을 기본 동작으로 적용하거나 더 나쁜 것은 변경 불가능한 동작이 상대적으로 드문 경우보다 더 파괴적 일 수 있습니다. 누군가가 호스트 이름 이외의 URL을 수동으로 입력해야하는 경우. 이렇게하면 안되는 이유에 대한 좋은 예를 보려면 Network Solutions ” 수정 된 ” 퍼블릭 DNS의 존재하지 않는 도메인 오류를 상기하십시오. 쿼리.
• @SirNickity 아무도 어떤 수준에서도 불변성을 제안하지 않았으며 웹 서버 오류 페이지는 내가 사용한 모든 웹 서버에서 구성 할 수 있습니다. ‘ 아무도 404를 30 * 코드로 바꾸라고 제안하지 않았고, 오히려 오류 페이지에 사람이 클릭 할 수있는 제안 링크 목록을 추가했습니다. 도메인 이름은 매우 다른 주제이며 대소 문자를 구분하지 않으며 보안 컨텍스트가 다릅니다. IIS는 이미 URI의 경로 또는 파일 이름 부분에서 대소 문자 차이를 무시하여 ” 수정 “합니다.
• 1996 년부터 Apache에서는 mod_speling 으로이를 수행 할 수 있습니다. ‘별로 인기있는 일이 아닌 것 같습니다. Unix / Linux 사용자는 대소 문자를 구분하지 않고 예외로 간주합니다.

위의 답변은 정답입니다. & 좋습니다. 더 많은 포인트를 추가하고 싶습니다.

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

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

대부분의 과학자들은 유닉스에 익숙했기 때문에 유닉스 스타일 파일 시스템에 영향을 받았을 것입니다.

Windows 서버는 2000 년 이후에 출시되었습니다. Windows 서버가 대중화되기 훨씬 이전에 HTTP 프로토콜이 잘 성숙되었고 사양이 완성되었습니다.

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

댓글

• ” Windows Server는 2000 년 이후에 출시되었습니다. ” Windows NT 3.1 팀은 1993 년에 동의하지 않았을 것입니다. 1995 년 NT 3.51은 아마도 NT가 비즈니스에 중요한 서버 응용 프로그램을 지원할 수있을만큼 성숙하고 잘 구축되었습니다.
• NT 3.51에는 Win 3.1 인터페이스가있었습니다. Windows는 Windows 95가 될 때까지 실제로 시작되지 않았고 동일한 인터페이스를 얻기 위해 NT 4.0이 필요했습니다.
• Michael Kj ö rling, 동의했습니다. 수정하겠습니다.
• @Thorbj ø rnRavnAndersen 서버 시장에서 NT 3.51은 상당히 성공적이었습니다. 소비자 / 프로슈머 시장에서 Windows 2000 (NT 5.0)까지는 NT 라인이 큰 관심을 끌기 시작했습니다.
• 사실 WorldWideWeb은 처음에는 대소 문자를 구분하는 Unix 기반 시스템에서 개발되었습니다. 파일 시스템 및 파일 시스템의 파일에 직접 매핑 된 대부분의 URL.

어떻게 읽어야합니까? “왜 이렇게 설계 되었습니까?” 질문? 의사 결정 과정에 대한 역사적으로 정확한 설명을 요구하고 있습니까? 아니면 “왜 이런 식으로 설계하겠습니까?”라고 묻는 것입니까?

역사적으로 정확한 정보를 얻는 것은 거의 불가능합니다. 계정.때때로 표준위원회에서 결정을 내릴 때 토론이 어떻게 진행되었는지에 대한 기록적인 흔적이 있지만, 웹의 초기에는 몇몇 개인 (이 경우 아마도 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와 유사한 컴퓨터에는 대소 문자를 구분하는 파일 이름이 있습니다. 그래서 제 생각에는 구현 편의성을 위해 그런 식으로 일어 났고 (최종 사용자를위한) 유용성은 고려조차되지 않았습니다. 다시 말하지만, 초기에 사용자는 어쨌든 모두 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에서이를 알려드립니다.

What I wou 이 상황에 처한 경우 모든 소문자 URL을 사용한 다음 대문자가 하나 이상 포함 된 URL을 소문자 버전으로 리디렉션하는 것이 좋습니다. 따라서 위의 URL 목록에서 모든 URL을 첫 번째 URL로 리디렉션하십시오.

댓글

• ” 예. 중복 콘텐츠 문제를 방지합니다. “-하지만 그 반대가 사실 인 것 같나요? URL이 대소 문자를 구분할 수 있다는 사실 (검색 엔진이 URL을 처리하는 방식)은 귀하가 언급 한 중복 콘텐츠 문제를 발생 합니다. URL이 일반적으로 대소 문자를 구분하지 않는 경우 대소 문자가 다른 중복 콘텐츠 문제가 없습니다. page-1는 PAGE-1와 같습니다 .
• 서버 구성이 좋지 않은 것 같습니다. 대소 문자를 구분할 때 콘텐츠가 중복 될 수 있습니다. 예를 들어 .htaccess에 저장된 문 RewriteRule ^request-uri$ /targetscript.php [NC]는 http://example.com/request-uri 및 http://example.com/ReQuEsT-Uri와 일치합니다. [NC]는 정규 표현식 하나를 평가할 때 대소 문자가 ‘ 중요하지 않음을 나타냅니다.

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

26 개의 문자가있는 경우 각각 대문자로 표기 할 수있는 문자는 52 자입니다.

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

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

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

이것이 https://www.youtube.com/watch?v=xXxxXxxX