---

Chapter 2. URLs and Resources

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

---

❤️ 원문 번역 ❤️

A Bit More

You might be wondering why nothing bad has happened when you have used characters that are unsafe. For instance, you can visit Joe’s home page at:

http://www.joes-hardware.com/~joe

and not encode the “~” character. For some transport protocols this is not an issue, but it is still unwise for application developers not to encode unsafe characters.

• 여러분은 안전하지 않은 문자를 사용할 때 어떤 잘못된 상황이 벌어지는지 궁금할지도 모릅니다.

• 예를 들어, 다음과 같은 Joe의 홈페이지에 방문한다고 해봅시다.
  -> http://www.joes-hardware.com/~joe
  

• 여기서 "~" 문자를 인코딩하지 않습니다.

• 어떤 전송 프로토콜에서는 이것이 큰 문제가 되지 않지만, 애플리케이션 개발자가 안전하지 않은 문자를 인코딩하지 않는 것은 그다지 현명하지 않습니다.

Applications need to walk a fine line. It is best for client applications to convert any unsafe or restricted characters before sending any URL to any other application.* Once all the unsafe characters have been encoded, the URL is in a canonical form that can be shared between applications; there is no need to worry about the other application getting confused by any of the characters’ special meanings.

• 애플리케이션은 좋은 길만을 걸어야 합니다. 클라이언트 애플리케이션이 URL을 다른 애플리케이션으로 전송하기 전에, 안전하지 않거나 제한된 모든 문자들을 변환하는 것이 가장 좋습니다.

• 안전하지 않은 모든 문자들이 인코딩되고 나면 URL은 애플리케이션 사이에서 공유할 수 있는 표준 형태가 됩니다. 이는 다른 애플리케이션이 문자가 특별한 의미를 가지고 있는지 혼동하는 것을 걱정할 필요가 없게 합니다.

The original application that gets the URL from the user is best fit to determine which characters need to be encoded. Because each component of the URL may have its own safe/unsafe characters, and which characters are safe/unsafe is scheme-dependent, only the application receiving the URL from the user really is in a position to determine what needs to be encoded.

• 유저로부터 URL을 받는 원본 애플리케이션은 어떤 문자가 인코딩이 필요한지 결정하는 데 가장 적합합니다.

• URL의 각각의 구성요소는 그들만의 안전하거나 안전하지 않은 문자들을 가지고 있고 이 문자들의 안전성은 Scheme에 의존적입니다. 따라서 오직 유저로부터 URL을 받은 애플리케이션만이 어떤 문자가 인코딩이 필요한지를 결정하는 역할을 합니다.

Of course, the other extreme is for the application to encode all characters. While this is not recommended, there is no hard and fast rule against encoding characters that are considered safe already; however, in practice this can lead to odd and broken behavior, because some applications may assume that safe characters will not be encoded.

• 물론 애플리케이션이 모든 문자를 인코딩하는 극단적인 예시도 있습니다.

• 그러나 이는 권장되지 않습니다. 이미 안전한 문자를 인코딩하는 것에 대한 엄격하고 빠른 규칙이 존재하지 않습니다.

• 실제로 이 방법은 이상하고 잘못된 방식입니다. 어떤 애플리케이션은 안전한 문자들은 인코딩되지 않을 것이라고 가정할지도 모르기 때문입니다.

Sometimes, malicious folks encode extra characters in an attempt to get around applications that are doing pattern matching on URLs—for example, web filtering applications. Encoding safe URL components can cause pattern-matching applications to fail to recognize the patterns for which they are searching. In general, applications interpreting URLs must decode the URLs before processing them.

• 가끔 악의적인 사람들은 웹 필터링 애플리케이션과 같이 패턴 매칭을 수행하는 애플리케이션을 피하기 위해 추가적인 문자를 인코딩합니다.

• 안전한 URL 구성 요소를 인코딩하는 것은 패턴 매칭 애플리케이션이 탐색하고자 하는 패턴을 인식하는 데 실패하게 만들 수 있습니다.

• 일반적으로 URL을 해석하는 애플리케이션은 그것들을 처리하기 전에 URL을 디코딩해야 합니다.

** URL 인코딩을 활용해 웹 필터링을 우회하는 기법에 대한 설명

Some URL components, such as the scheme, need to be recognized readily and are required to start with an alphabetic character. Refer back to “URL Syntax” for more guidelines on the use of reserved and unsafe characters within different URL components.*

• Scheme과 같은 URL 구성 요소 몇 가지는 쉽게 인식되어야 하고, 알파벳 문자로 시작해야 합니다.

• 서로 다른 URL 구성 요소에서의 예약어와 안전하지 않은 문자의 사용에 대한 가이드라인은 "URL Syntax"의 내용을 참고하기 바랍니다.

---

A Sea of Schemes

In this section, we’ll take a look at the more common scheme formats on the Web. Appendix A gives a fairly exhaustive list of schemes and references to their individual documentation.

• 이번 섹션에서는 더 일반적인 웹에서의 Scheme 포맷에 대해 살펴볼 것입니다.

• Appendix A가 상당히 많은 Scheme의 목록과 이 Scheme에 대한 각각의 참조 문서를 제공합니다.

Table 2-4 summarizes some of the most popular schemes. Reviewing “URL Syntax” will make the syntax portion of the table a little more familiar.

• Table 2-4는 자주 사용되는 몇 가지 Scheme들만 정리할 것입니다.

• "URL Syntax"의 내용을 복습하면 테이블의 구문 일부가 더 친숙하게 느껴질 것입니다.

---

💛 감상 💛

• URL 인코딩이나 웹 보안과는 크게 관련없지만, 중학생 때 있었던 일이 하나 생각난다...ㅋㅋㅋㅋ 지금은 보안 문제 때문인지 학교 홈페이지에 개인정보가 적혀 있지 않은데 그 당시에만 해도 각 반 담임선생님들의 성함을 확인할 수 있었다. 반 배정이 나면 학교에서는 개학 전까지 담임선생님을 확인할 수 있는 페이지를 숨겼는데, 나는 담임선생님이 너무 궁금한 나머지 숨긴 페이지를 찾아냈었다. 학교 홈페이지라 그런지 진짜 허술했다. 같은 카테고리에 있는 페이지끼리 URL이 번호 하나씩 차이가 났었다. 그런데 중간에 번호 하나가 비어있는 게 있길래 그 번호를 입력하고 들어갔더니 담임선생님 성함이 떡하니 적혀 있었다. 그 이후로는 3월 2일이 되기도 전에 담임선생님이 누군지 알았다. 나만 아는 비밀이어서 더 재미있었다.

• 또 3일이나 쉬었다. 그래도 다시 시작했다. 작심삼일도 100일이면 300일이나 공부하게 되는 거다. 이렇게 정신 승리를 해본다.