URL의 유니 코드 문자


135

2010 년에 대규모 웹 포털에서 UTF-8 문자가 포함 된 URL을 제공 하시겠습니까?

URL의 RFC에 따라 유니 코드 문자는 금지되어 있습니다 ( 여기 참조 ). 표준을 준수하려면 퍼센트로 인코딩해야합니다.

그러나 내 주요 요점은 멋진 URL을 만들기위한 목적으로 인코딩되지 않은 문자를 제공하므로 인코딩 비율이 백분율입니다.

모든 주요 브라우저는 RFC의 말에 상관없이 해당 URL을 구문 분석하는 것 같습니다. 그러나 일반적인 인상은 웹 브라우저의 도메인을 떠날 때 매우 흔들리는 것입니다.

  • 텍스트 파일, 전자 메일, 다른 인코딩을 사용하는 웹 사이트에 복사하여 붙여 넣기하는 URL
  • HTTP 클라이언트 라이브러리
  • 이국적인 브라우저, RSS 리더

내 문제는 여기서 문제가 예상된다는 것이 맞습니까? 따라서 기술이 아닌 독자에게 서비스를 제공하는 경우 실용적인 해결책이 아니지만 아직 인용하고 전달한 경우에도 모든 링크가 제대로 작동하는 것이 중요합니까?

HTML로 멋진 URL을 제공하는 마법의 방법이 있습니까?

http://www.example.com/düsseldorf?neighbourhood=Lörick

특수 문자를 그대로 복사하여 붙여 넣을 수는 있지만 이전 클라이언트에서 다시 사용할 때 올바르게 작동합니까?


16
Firefox는 URL 표시 줄에 유니 코드 문자를 표시하지만 인코딩 된 서버 백분율로 전송합니다. 또한 사용자가 URL 표시 줄에서 URL을 복사하면 Firefox는 인코딩 된 URL의 백분율이 클립 보드에 복사되도록합니다.
Siddhartha Reddy

답변:


126

퍼센트 인코딩을 사용하십시오. 최신 브라우저는 표시 및 붙여 넣기 문제를 처리하여 사람이 읽을 수있게합니다. 예 : http://ko.wikipedia.org/wiki/ 위키 백과 : 대문

편집 : Firefox에서 이러한 URL을 복사하면 클립 보드는 백분율로 인코딩 된 형식 (보통 좋은 것)을 유지하지만 일부만 복사하면 인코딩되지 않은 상태로 유지됩니다.


와우, 사실 네 말이 맞아! 붙여 넣기를 잘라 내면 % 인코딩 된 URL 파이어 폭스는 URL을 올바른 표시로 바꿉니다.
Dean Harding

와우, 나는 이것을 몰랐다. 이것이 최선의 해결책 일 것입니다!
Pekka

33
@Dean은 상당히 최근의 변화입니다. 2005 년에 모든 국제 위키 백과는 실제 % 6D % 65 % 73 % 73처럼 보였습니다.
Roman Starkov

2
지금까지 HTML5 문서 에서 인코딩되지 않은 UTF-8 URL, 즉 IRI를 사용할 수 있습니다 . 그렇게하면 모든 주요 브라우저가이를 이해하고 주소 표시 줄에 올바르게 표시합니다.
Oliver

최신 브라우저는 요청 라인의 서버로 어떤 바이트를 보냅니 GET /images/logo.png HTTP/1.1까? 그들은 항상 URL을 퍼센트 인코딩합니까?
Flimm

87

Tgr가 말한 것. 배경:

http://www.example.com/düsseldorf?neighbourhood=Lörick

그것은 URI가 아닙니다. 그러나 그것은 이다 IRI는 .

HTML4 문서에는 IRI를 포함 할 수 없습니다. 같은 속성 유형은 hrefIRI가 아닌 URI로 정의됩니다. 어쨌든 일부 브라우저는 IRI를 처리하지만 실제로는 좋은 생각이 아닙니다.

IRI를 URI로 인코딩하려면 경로와 쿼리 부분을 UTF-8로 인코딩 한 다음 비 ASCII 바이트를 퍼센트 인코딩합니다.

http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick

IRI의 호스트 이름 부분에 ASCII가 아닌 문자가있는 경우 (예 : 대신 Punycodehttp://例え.テスト/사용하여 인코딩 되었습니다.

이제 URI가 있습니다. 못생긴 URI입니다. 그러나 대부분의 브라우저는이를 숨길 것입니다. 주소 표시 줄에 복사하여 붙여 넣거나 링크를 따라 가면 원래 유니 코드 문자로 표시됩니다. Wikipedia는 수년간 이것을 사용해 왔습니다. 예 :

http://en.wikipedia.org/wiki/ɸ

동작이 예측할 수없고 항상 예쁜 IRI 버전을 표시하지 않는 브라우저는 ...

...아시다시피.


31
알아. 언젠가 누군가는 큰 클럽을 떠나서 Lynx 개발자들을 머리로 때려야합니다. 훌륭한 배경 정보에 감사드립니다.
Pekka

2
@bobince 그리고 비 IRI URI도 처리 할 수없는 하나의 봇 (2013 년으로 빨리 감기)은 ... ... 잘 알고 있습니다 : 빙봇! 그림을 이동.
Tom Harrison

1
HTML5는 마침내 IRI를 지원합니다. 주제에 대한 자세한 정보 는 관련 질문에 대한이 답변 에서 찾을 수 있습니다 .
Oliver

5
Re : IE는 항상 예쁜 IRI를 표시하지는 않으며, 사용자를 호모 그래프 기반 피싱 공격으로부터 보호합니다. 확인 w3.org/International/articles/idn-and-iri을 (특히 섹션 '도메인 이름 및 피싱')와 blogs.msdn.com/b/ie/archive/2006/07/31/684337.aspx
codingoutloud

2
도메인 이름은 이와 관련이 없습니다. 모든 브라우저는 피싱을 방지하기 위해 광범위한 문자를 허용하지 않습니다. 경로 또는 쿼리 문자열 부분에 비 ASCII 문자를 표시해도 비슷한 취약성이 발생하지 않습니다. IE는 단순히 그것을 구현하지 않았다. (그리고 Firefox는 프래그먼트 부분을 위해서도 그것을 구현 한 유일한 것입니다.)
Tgr

16

URL 체계에 따라 UTF-8로 인코딩 된 부분을 "중요하지 않음"으로 만들 수 있습니다. 예를 들어, 스택 오버플로 URL을 보면 다음과 같은 형식입니다.

http://stackoverflow.com/questions/2742852/unicode-characters-in-urls

그러나 서버는 식별자 뒤에 잘못된 부분이 있는지 실제로 신경 쓰지 않으므로 작동합니다.

http://stackoverflow.com/questions/2742852/ こ れ は 、 こ れ を 日本語 の テ キ ス ト で す

따라서 이와 같은 레이아웃이 있으면 식별자 뒤에 부분에서 UTF-8을 사용할 수 있으며 실제로 깨진 경우 문제가되지 않습니다. 물론 이것은 아마도 다소 특수한 환경에서만 작동합니다 ...


흠, 매우 영리한 생각! 아직 그들이 문자열의 위치 일부 클라이언트에 상관없이 문자에 질식 없다고 할 수 있지만, 그것은 것입니다 내가 가장 중요한 부분입니다 생각 URL을 붙여 + 복사 할 때 일반 임의로 변경으로 모든 문제를 제거 할 수 있습니다. 아직 SO의 URL을 보지 못했습니다. 감사!
Pekka

글쎄, 이것은 여전히 ​​단어 "질문"을 번역하지 않은 채로 남겨두고, 전체 URL을 따르는 해시 # 뒤에 물건이 있지만 아주 좋은 트릭입니다!
Evgeny

4
自動 翻 訳 機 を 使 っ て そ の 日本語 の URL を 作 っ た ね。
Glutexo

6

좋은 아이디어인지 확실하지 않지만 다른 의견에서 언급했듯이 해석하면 많은 유니 코드 문자 가 HTML5 URL에서 유효합니다 .

예를 들어 href문서는 http://www.w3.org/TR/html5/links.html#attr-hyperlink-href 라고 말합니다 .

및 영역 요소의 href 속성은 공백으로 둘러싸 일 수있는 유효한 URL 값을 가져야합니다.

그런 다음 "유효한 URL"의 정의는 http://url.spec.whatwg.org/를 가리키며 URL 코드 포인트 는 다음과 같이 정의 됩니다.

ASCII 영숫자, "!", "$", "&", " '", "(", ")", "*", "+", ",", "-", ".", "/" , ":", ";", "=", "?", "@", "_", "~"및 U + 00A0 ~ U + D7FF, U + E000 ~ U + FDCF 범위의 코드 포인트 , U + FDF0 ~ U + FFFD, U + 10000 ~ U + 1FFFD, U + 20000 ~ U + 2FFFD, U + 30000 ~ U + 3FFFD, U + 40000 ~ U + 4FFFD, U + 50000 ~ U + 5FFFD, U + 60000 ~ U + 6FFFD, U + 70000 ~ U + 7FFFD, U + 80000 ~ U + 8FFFD, U + 90000 ~ U + 9FFFD, U + A0000 ~ U + AFFFD, U + B0000 ~ U + BFFFD, U + C0000 U + CFFFD로, U + D0000에서 U + DFFFD로, U + E1000에서 U + EFFFD로, U + F0000에서 U + FFFFD로, U + 100000에서 U + 10FFFD로.

"URL 코드 포인트"라는 용어는 구문 분석 알고리즘의 일부에서, 예를 들어 상대 경로 상태에 사용됩니다 .

c가 URL 코드 포인트가 아니고 "%"가 아닌 경우 구문 분석 오류입니다.

또한 유효성 검사기 http://validator.w3.org/는와 같은 "你好"URL을 전달하며 공백과 같은 문자가 포함 된 URL은 전달하지 않습니다."a b"

관련 : 어떤 문자가 URL을 유효하지 않게합니까?


그러나 HTTP 요청을 올바르게 할 때 두 URL ( "你好""a b")을 백분율로 인코딩해야합니까?
Utku

"a b"공간이 위의 허용 목록에 없기 때문에 @Utku는 꽤 확실합니다. 의 경우 "你好", 퍼센트 인코딩하는 것이 더 좋은 아이디어이지만, 그것이 "구현이 충분하지 않다"거나 "표준이 그렇게 말하는"문제인지는 모르겠습니다. HTML 표준은 이러한 문자를 허용하는 것으로 보입니다. 그러나 이것이 HTML이 아닌 HTTP 표준으로 지정되었다고 생각합니다. 참조 : stackoverflow.com/questions/912811/...을
치로 틸리郝海东冠状病六四事件法轮功

예, HTML이 아닌 HTTP 표준을 생각하고있었습니다.
Utku

5

이러한 모든 의견이 사실이므로 ICANN에서 승인 한 아랍어 (페르시아어) 및 중국어 문자가 도메인 이름으로 등록되는 한 모든 브라우저 제작 회사 (Microsoft, Mozilla, Apple 등)는 인코딩없이 URL에서 유니 코드를 지원하며 Google 등에서 검색 할 수 있어야합니다.

따라서이 문제는 최대한 빨리 해결됩니다.


2
@Nasser : True – 독일어 도메인에도 특수 문자가 있지만 Punycode를 사용하여 ASCII 문자로 인코딩됩니다 . 주요 브라우저에서 작동하지만 모든 HTTP 클라이언트 라이브러리 및 이국적인 응용 프로그램이 인코딩되지 않은 유니 코드 문자를 처리하기까지는 오랜 시간이 걸릴 것입니다.
Pekka

@Pekka, 확실하지 않지만 들었 듯이 모든 브라우저는 2010 년 4 분기에 유니 코드 URL을 지원해야합니다. (확실하지 않습니다)
Nasser Hadjloo

모든 사용자 에이전트가 웹 브라우저 인 것은 아니기 때문에 문제가 복잡합니다. 가장 큰 예는 Google 자체입니다. 일반적인 웹 브라우저를 사용하여 크롤링하지 않습니다. API 상호 작용 등을위한 많은 라이브러리도 마찬가지입니다. URL은 WWW뿐만 아니라 거의 모든 곳에서 문자 그대로 존재합니다. 아마도 파일 시스템에서도 가능합니다.
Cornelius

1

퍼센트 인코딩 형식을 사용하십시오 . 예를 들어 Windows XP를 실행하는 일부 (주로 오래된) 컴퓨터는 유니 코드가 아니라 ISO 인코딩을 지원합니다. 이것이 퍼센트 인코딩 된 URL이 발명 된 이유입니다. 또한 쉽게 입력 할 수없는 문자를 포함하여 사용자에게 종이로 인쇄 된 URL을 제공하는 경우 해당 사용자는 입력하기가 어렵거나 무시할 수 있습니다. 퍼센트 인코딩 형식은 기존의 많은 오래된 컴퓨터에서도 사용할 수 있습니다 (물론 인터넷을 지원하지는 않지만).

퍼센트 인코딩 된 문자가 원래 문자보다 길기 때문에 URL이 길어질 수 있다는 단점이 있습니다. 그러나 무시하거나 URL 단축기를 사용하십시오 ( 이 경우 13 문자 길이의 URL을 만드는 goo.gl 을 권장합니다 ). 또한 Google 계정에 등록하지 않으려면 bit.ly를 시도하십시오 (bit.ly는 길이가 14자인 URL을 약간 길게 만듭니다).


여전히 Windows XP를 사용하는 오래된 컴퓨터를 지원하고 싶은 이유는 무엇입니까?
Mateus Felipe

0

나에게 이것은 올바른 방법입니다.

    $linker = rawurldecode("$link");
    <a href="<?php echo $link;?>"   target="_blank"><?php echo $linker ;?></a>

이것은 효과가 있었고 이제 링크가 올바르게 표시됩니다.

http://newspaper.annahar.com/article/121638 -معرض--جوزف-حرب-في-غاليري-جانين-ربيز-لوحاته-الجدية-تبحث-وتكتشف-وتفرض-الاحترام

링크 발견 :

http://www.galeriejaninerubeiz.com/newsite/news


2
"링크가 올바르게 표시됩니다"-StackOverflow 마크 다운 파서가 URL을 의도 한대로 해석하지 않는 것을 제외하고!
MrWhite
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.