[validation] 어떤 문자가 URL을 유효하지 않게합니까?

여기에있는 기존 답변의 대부분은 다음과 같은 실제 주소 사용을 완전히 무시하기 때문에 비실용적입니다.

• https://en.wikipedia.org/wiki/Möbius_strip 또는
• https://zh.wikipedia.org/wiki/Wikipedia : 关于 中文 维基 百科 / ko .

첫째, 용어로의 탈선. 이 주소 는 무엇입니까 ? 유효한 URL입니까?

역사적으로 대답은 “아니오”였습니다. 에 따르면RFC 3986 2005 년부터 이러한 주소는 URI가 아니므로 URL 이 URI의 유형 이므로 URL 이 아닙니다 . 2005 IETF 표준의 용어에 따라 RFC 3987에 정의 된 대로 IRI (Internationalized Resource Identifiers)를 적절하게 호출해야합니다. RFC 3987 은 기술적으로 URI가 아니지만 IRI에서 ASCII가 아닌 모든 문자를 퍼센트 인코딩하여 간단히 URI로 변환 할 수 있습니다. .

현대의 사양에 따라 대답은 “예”입니다. 그만큼WHATWG 생활 수준은 단순히 이전에 “URL을”로 “URI를”또는 “아이리스”라는 것 모든 것을 분류한다. 이는 스펙을 읽지 않은 일반 사람들이 스펙의 목표 중 하나 인 “URL”이라는 단어를 사용하는 방식과 스펙 용어를 정렬합니다 .

WHATWG 생활 표준에 따라 어떤 문자가 허용됩니까?

“URL”의이 새로운 의미에 따라 어떤 문자가 허용됩니까? 쿼리 문자열 및 경로와 같은 URL의 많은 부분에서 임의의 것을 사용할 수 있습니다. “URL 단위” 를 사용할 수 있습니다.

URL 코드 포인트 및 퍼센트 인코딩 된 바이트 .

“URL 코드 포인트”란 무엇입니까?

URL 코드 포인트 + 0,021 U (!) + 0024 U ($) + 0026 U () + 0027 U ( ‘), U + 0028 LEFT PARENTHESIS, U + 0029 RIGHT PARENTHESIS, U +, ASCII의 영숫자 002A (*), U + 002B (+), U + 002C (,), U + 002D (-), U + 002E (.), U + 002F (/), U + 003A (:), U + 003B (;), U + 003D (=), U + 003F (?), U + 0040 (@), U + 005F (_), U + 007E (~) 및 U + 00A0 ~ U 범위의 코드 포인트 + 10FFFD, 대리 및 비 문자 제외.

(주 “URL 코드 포인트”의 목록에 포함되지 않습니다 %,하지만% 의는 “URL 코드 단위”에서 허용되는 경우 그들이 퍼센트 인코딩 시퀀스의있는 거 부분.)

스펙 이이 세트에 없는 문자의 사용을 허용하는 유일한 장소 는 IPv6 주소 와 문자 로 묶인 호스트 입니다. URL의 다른 곳에서는 URL 단위 또는 더 제한적인 문자 집합이 허용됩니다.[]

이전 RFC에서 어떤 문자가 허용 되었습니까?

역사를 위해서, 그리고 여기에 대한 답변의 다른 곳에서 완전히 탐구되지 않았으므로, 더 오래된 사양 쌍에서 검사가 허용되었습니다.

우선, 두 가지 유형의 RFC 3986 예약 문자가 있습니다 .

• :/?#[]@RFC 3986에 정의 된 URI에 대한 일반 구문의 일부입니다.
• !$&'()*+,;=는 RFC의 일반 구문에 포함되지 않지만 특정 URI 체계의 구문 구성 요소로 사용하도록 예약되어 있습니다. 예를 들어, 세미콜론 및 쉼표의 신택스의 일부로서 사용되는 데이터의 URI 와 &와 =유비쿼터스의 일부로서 사용된다 ?foo=bar&qux=baz(질의 스트링의 형식 되지 RFC 3986에 의해 특정).

위의 예약 문자는 인코딩 목적없이 URI에서 합법적으로 사용되어 구문 목적으로 사용되거나 데이터의 문자 그대로 문자 그대로 사용되어 구문 목적으로 사용되는 문자로 잘못 해석 될 수없는 경우가 있습니다. 예를 들어 /URL에 구문 의미가 있지만 쿼리 문자열 에는 의미 가 없으므로 쿼리 문자열에서 인코딩되지 않은 상태로 사용할 수 있습니다 .

RFC 3986은 또한 예약되지 않은 문자를 지정 하며 인코딩없이 데이터를 나타내는 데 항상 간단하게 사용할 수 있습니다.

• abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~

마지막으로 %문자 자체는 퍼센트 인코딩에 허용됩니다.

잎 만 다음 ASCII 문자 그 금지 의 URL에 표시 :

• 줄 바꾸기, 탭 및 캐리지 리턴을 포함한 제어 문자 (문자 0-1F 및 7F).
• "<>\^`{|}

ASCII의 다른 모든 문자는 합법적으로 URL에 표시 될 수 있습니다.

그런 다음 RFC 3987은 예약되지 않은 문자 세트를 다음과 같은 유니 코드 문자 범위로 확장합니다.

  %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD

구 스펙에서 이러한 블록 선택은 최신 유니 코드 블록 정의를 고려할 때 기괴하고 임의적입니다 . RFC 3987이 작성된 이후 10 년 동안 블록이 추가 되었기 때문일 수 있습니다.

마지막으로, 어떤 문자가 URL의 특정 부분에서만 유효한 것이기 때문에, 어떤 문자가 URL에 합법적으로 나타날 수 있는지 아는 것만으로는 주어진 문자열이 유효한 URL인지 아닌지를 인식하기에 충분하지 않다는 점에 주목할 가치가 있습니다. 예를 들어, 예약 문자 [와는 ]합법적 같은 URL에서의 IPv6 리터럴 호스트의 일환으로 / foo는 HTTP : // [417A 1080 :: 8 : 800 : 200C] 그렇게하지만, 다른 상황에서 불법이다 OP의 예 http://example.com/file[/].html는 불법입니다.

답변

>>> allowed = "-_.~!*'();:@&=+$,/?%#[]?@ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
>>> from string import printable
>>> ''.join(set(printable).difference(set(allowed)))
'`" <\x0b\n\r\x0c\\\t{^}|>'