유니 코드 문자를 URL 인코딩하는 올바른 방법은 무엇입니까?

비표준 % uxxxx 체계에 대해 알고 있지만 W3C에서 해당 체계를 거부했기 때문에 현명한 선택이 아닌 것 같습니다.

몇 가지 흥미로운 예 :

하트 캐릭터. 내 브라우저에 이것을 입력하면 :

http://www.google.com/search?q=♥

그런 다음 복사하여 붙여 넣으면이 URL이 표시됩니다.

http://www.google.com/search?q=%E2%99%A5

Firefox (또는 Safari)가이 작업을 수행하는 것처럼 보입니다.

urllib.quote_plus(x.encode("latin-1"))
'%E2%99%A5'

3 점 문자처럼 Latin-1로 인코딩 할 수없는 것을 제외하고는 말이됩니다.

…

URL을 입력하면

http://www.google.com/search?q=…

내 브라우저에 복사하여 붙여 넣으면

http://www.google.com/search?q=%E2%80%A6

뒤. 한 결과 인 것 같습니다.

urllib.quote_plus(x.encode("utf-8"))

… Latin-1로 인코딩 할 수 없기 때문에 의미가 있습니다.

그러나 브라우저가 UTF-8 또는 Latin-1로 디코딩할지 여부를 어떻게 아는지는 분명하지 않습니다.

이것은 모호한 것처럼 보이기 때문에 :

In [67]: u"…".encode('utf-8').decode('latin-1')
Out[67]: u'\xc3\xa2\xc2\x80\xc2\xa6'

작동하므로 브라우저가 UTF-8 또는 Latin-1로 디코딩할지 여부를 어떻게 파악하는지 모르겠습니다.

내가 다루어야 할 특수 문자로 옳은 일은 무엇입니까?

항상 UTF-8로 인코딩합니다. 퍼센트 인코딩에 대한 Wikipedia 페이지에서 :

일반 URI 구문은 URI에서 문자 데이터의 표현을 제공하는 새로운 URI 체계가 사실상 번역없이 예약되지 않은 집합의 문자를 나타내야하며 다른 모든 문자를 UTF-8에 따라 바이트로 변환해야한다고 요구합니다. 해당 값을 퍼센트 인코딩합니다. 이 요구 사항은 2005 년 1 월에 소개되었습니다. RFC 3986 . 이 날짜 이전에 도입 된 URI 스킴은 영향을받지 않습니다.

과거에 URL 인코딩을 수행하는 다른 방법이 있었기 때문에 브라우저는 URI를 디코딩하는 여러 가지 방법을 시도하지만 인코딩을 수행하는 경우 UTF-8을 사용해야합니다.

일반적인 규칙은 브라우저가 양식이 제공된 페이지의 콘텐츠 유형에 따라 양식 응답을 인코딩하는 것 같습니다. 이것은 서버가 "text / xml; charset = iso-8859-1"을 보내면 동일한 형식으로 응답을 기대한다는 추측입니다.

URL 표시 줄에 URL을 입력하는 경우 브라우저에 작업 할 기본 페이지가 없으므로 추측 만하면됩니다. 따라서이 경우에는 항상 utf-8을 수행하는 것 같습니다 (두 입력이 3 옥텟 형식 값을 생성했기 때문에).

슬픈 사실은 AFAIK가 쿼리 문자열의 값 또는 실제로 URL의 모든 문자를 해석해야하는 문자 집합에 대한 표준이 없다는 것입니다. 적어도 쿼리 문자열의 값의 경우에는 반드시 수행 한다고 가정 할 이유가 없습니다. 문자에 해당합니다.

쿼리 문자열이 인코딩 될 것으로 예상되는 문자 집합을 서버 프레임 워크에 알려야한다는 것은 알려진 문제입니다. 예를 들어 Tomcat에서는 먼저 request.setEncoding () (또는 유사한 메서드)을 호출 해야 합니다. request.getParameter () 메서드를 호출합니다. 이 주제에 대한 문서의 부족은 아마도 많은 개발자들 사이에서 문제에 대한 인식 부족을 반영 할 것입니다. (나는 정기적으로 Java 인터뷰 대상자에게 Reader와 InputStream의 차이점이 무엇인지 묻고 정기적으로 빈 모양을 얻습니다)

IRI ( RFC 3987 )는 URI / URL ( RFC 3986 이전) 표준 을 대체하는 최신 표준입니다 . URI / URL은 기본적으로 유니 코드를 지원하지 않습니다 (음, RFC 3986은이 를 지원하기 위해 향후 URI / URL 기반 프로토콜에 대한 조항을 추가하지만 이전 RFC를 업데이트하지는 않습니다). "% uXXXX"체계는 일부 상황에서 유니 코드를 허용하는 비표준 확장이지만 모든 사람이 보편적으로 구현하지는 않습니다. 반면 IRI는 유니 코드를 완벽하게 지원하며 텍스트를 UTF-8로 인코딩 한 다음 퍼센트 인코딩해야합니다.

HTTP를 포함한 일부 컨텍스트에서는 URI (효과적으로 ASCII) 만 허용되기 때문에 IRI는 URI를 대체하지 않습니다.

대신 IRI를 지정하면 유선으로 나갈 때 URI로 변환됩니다.

첫 번째 질문은 당신의 필요가 무엇입니까? UTF-8 인코딩은 저렴한 편집기로 만든 텍스트를 가져 오는 것과 다양한 언어를 지원하는 것 사이에서 꽤 좋은 절충안입니다. 인코딩을 식별하는 브라우저와 관련하여 웹 서버의 응답은 브라우저에 인코딩을 알려야합니다. 여전히 대부분의 브라우저는 추측을 시도합니다. 이는 많은 경우에 누락되거나 잘못 되었기 때문입니다. 그들은 기본 인코딩에 맞지 않는 문자가 있는지 확인하기 위해 일정량의 결과 스트림을 읽어 추측합니다. 현재 모든 브라우저 (? 나는 이것을 확인하지 않았지만 사실에 가깝습니다) utf-8을 기본값으로 사용합니다.

따라서 다른 많은 인코딩 체계 중 하나를 사용해야하는 설득력있는 이유가없는 한 utf-8을 사용하십시오.