Backbone: 라우팅 대소문자 구분

경로에 정규식을 사용하고 플래그 i(대소문자 구분 안 함)를 사용합니다. 예: /regex/i

var Router = Backbone.Router.extend({
    routes: {
        /regex/i: "home"
    }
    ....
});

#initialize 안에 대소문자를 구분하지 않는 정규식 경로를 수동으로 추가 할 수 있습니다.

URL 사양이 대소문자 구분을 지정한다는 것은 이해하지만, 솔루션에 경로가 지정되는 일반적인 방식에서 약간의 편차가 필요하다는 사실은 많은 골칫거리를 유발할 수 있습니다. 공식 사양이 몇 가지 중요한 사용 사례를 고려하지 않은 것으로 밝혀졌기 때문에 공식 사양에서 벗어난 웹 소프트웨어가 무수히 많습니다. 기본 동작의 사양에서 벗어나라고 제안하는 것은 아니지만 "사양"이 해당 동작에 대한 실제 실제 요구 사항을 모두 무시하기 때문에 대소문자 구분을 해제하는 옵션을 제공하지 않습니다. 우리는 IIS에서 .NET을 실행하고 있으며 어느 쪽도 대소문자 구분 URL을 요구하지 않습니다. 따라서 모든 개발자가 돌아가서 사양을 충족하기 위해 프로젝트 전체에 흩어져 있는 수천 개의 URL을 모두 수정해야 합니다. 일어나 다. 이것에 대한 스택 오버플로 질문이 있습니다. 온라인에 해킹 및 해결 방법을 게시하는 사람들은 모두 실제 실제 사용자보다 W3C 사양을 우선시하기 때문입니다.

이것을 옵션으로 허용하지 않으려면 최소한 관련 코드를 백본(현재 클로저에 있음)에 노출하여 원본 소스를 수정하지 않고 이 동작을 재정의할 수 있도록 하십시오.

실제로 사양에서는 실제로 URL 이 대소문자를 구분한다고 말하지 않습니다.

"URL은 _일반적으로_ 대소문자를 구분합니다(컴퓨터 이름 제외). URL이나 URL의 일부가 있을 수 있으며 대소문자는 중요하지 않지만 식별하는 것은 쉽지 않을 수 있습니다. 사용자는 항상 URL이 대소문자임을 고려해야 합니다. -민감하다. /u"

"일반적으로" != "해야 합니다." 사용자는 항상 대소문자를 구분해야 한다고 말하지만 그렇지 않은 경우 라우터/서버가 대소문자를 구분하도록 구성되어 있으면 제대로 인식되지 않을 수 있기 때문입니다.

아파치가 대소문자를 구분하지 않도록 구성할 수 있다면 백본도 같은 방식이어야 한다고 생각합니다.

이 솔루션은 라우터의 루트에 케이스 오류가 있는 경우에도 도움이 되지 않습니다.

예를 들어 앱이 www.example.com/MyApp 의 경우와 같이 도메인 루트에 있지 않은 경우 사용자가 www.example.com/myapp 에 입력할 때 정규식 솔루션이 도움이 되지 않습니다.