2.4.4. 좀 더 알아보기

이쯤 되면, 예전에 안전하지 않은 문자를 URL에 사용했어도 아무런 문제가 발생하지 않았던 것이 생각나면서 의아해질 것이다.
예를 들어 http://www.test.com/~hyungju에 있는 페이지에 접근할 수 있다.
~ 문자는 인코딩하지 않는다.
어떤 전송 프로토콜에서는 이것이 별문제가 되지 않기는 하지만, 애플리케이션 개발자들이 안전하지 않은 문자를 인코딩하지 않은 것은 실수다.

애플리케이션은 정해진 방식대로 구현해야 한다.
어떤 애플리케이션에 어떤 URL을 보내든지, 그 전에 클라이언트 애플리케이션에서 안전하지 않거나 제한된 문자를 변환하는 것이 좋다.

여기서는 프락시 같은 HTTP 중개 애플리케이션이 아닌 클라이언트 애플리케이션에 대해서만 이야기한다.
6장의 '전송 중 URI 변경'에서는 클라이언트 애플리케이션 대신 프락시나 다른 중개 HTTP 애플리케이션이 URL을 수정(예를 들어 인코딩)할 경우 발생할 수 있는 문제에 대해 논의한다.

안전하지 않은 모든 문자를 인코딩하기만 하면, 다른 애플리케이션으로부터 특별한 의미를 가지는 문자를 받았을 때 혼동할 걱정 없이, 애플리케이션 간에 공유할 수 있는 URL의 원형을 유지할 수 있다.

입력받은 URL에서 어떤 문자를 인코딩해야 하는지 결정하는 데는 브라우저와 같이 사용자로부터 최초로 URL을 입력받는 애플리케이션에서 하는 것이 가장 적절하다.
URL을 구성하는 각 컴포넌트마다 사용할 수 있거나 없는 문자들이 있을 것이고, 또 어떤 문자는 스킴에 따라서 가용성이 달라지기 때문에, 해당 문자들을 직접 입력 받는 애플리케이션이야말로 어떤 문자를 인코딩해야 하는지 결정하기에 가장 좋은 위치라는 것이다.

물론 극단적인 방법은 애플리케이션이 모든 문자를 인코딩하는 것이다.
이 방식을 추천하지는 않지만, 이미 안전한 것으로 판단되는 문자를 재차 인코딩하는 것보다 더 완벽하고 빠른 규칙은 없다.
하지만 실제로 이 방식은 안전한 문자들을 인코딩하지 않는 애플리케이션도 있기 때문에 오작동을 일으킬 수 있다.

악의적인 사람들은 URL의 패턴 매칭을 하는 애플리케이션(예를 들어 필터링 애플리케이션)을 회피하여 다른 문자들을 인코딩하기도 한다.
안전한 URL 컴포넌트를 인코딩하면, 패턴 매칭 애플리케이션이 원하는 패턴을 찾지 못하는 원인이 될 수 있다.
보통, URL을 해석하는 애플리케이션은 그것을 처리하기 전에 URL을 디코드해야 한다.

스킴 같은 몇몇 URL 컴포넌트는 쉽게 알아볼 수 있어야 하며 알파벳 문자로 시작되어야 한다.
각 URL 컴포넌트 간에 선점된 문자나 안전하지 않은 문자를 사용하는 방법에 대한 상세한 내용은, 앞서 다룬 'URL 문법'을 다시 참고하자.

앞의 표에 여러 URL 컴포넌트에 대한 예약문자가 기술되어 있다.
일반적으로, 인코딩은 전송하기에 안전하지 않은 문자에만 적용해야 한다.