IT story

URL에서 % 20 또는 +를 사용하여 공백을 인코딩해야합니까?

hot-time 2020. 8. 2. 17:21
반응형

URL에서 % 20 또는 +를 사용하여 공백을 인코딩해야합니까? [복제]


이 질문에는 이미 답변이 있습니다.

URL에서 %20또는 +?를 사용하여 공백을 인코딩해야 합니까? 예를 들어, 다음 예에서 어느 것이 맞습니까?

www.mydomain.com?type=xbox%20360
www.mydomain.com?type=xbox+360

우리 회사는 이전에 기대어 있지만, Java 메소드를 사용 URLEncoder.encode(String, String)하여 "xbox 360"(과 "UTF-8") 후자 돌아갑니다 .

차이점은 무엇입니까?


양식 데이터 (GET 또는 POST 용)는 일반적으로 application/x-www-form-urlencoded다음 과 같이 인코딩됩니다 . +공백을 지정 합니다.

URL은 RFC 1738 로 인코딩되어 다음 을 지정합니다 %20.

이론적으로 나는 당신이 전후에 % 20을 가져야한다고 생각합니다 ?.

example.com/foo%20bar?foo+bar

W3C 에 따르면 (그리고 이것들에 대한 공식 소스 임), 쿼리 문자열 (및 쿼리 문자열에서만)의 공백 문자는 " %20"또는 " +" 로 인코딩 될 수 있습니다 . "권장 사항"의 "문자열 쿼리"섹션에서 :

쿼리 문자열 내에서 더하기 부호는 공백의 속기 표기법으로 예약됩니다. 따라서 실수 더하기 부호를 인코딩해야합니다. 이 방법은 공백을 허용하지 않는 시스템에서 쿼리 URI를 더 쉽게 전달하는 데 사용되었습니다.

일반적으로 URI에 대한 공식 사양 RFC2396의 섹션 3.4에 따르면 "쿼리"구성 요소는 URL에 따라 다릅니다.

3.4. 쿼리 구성 요소 쿼리 구성 요소는 리소스에서 해석 할 정보 문자열입니다.

   query         = *uric

쿼리 구성 요소 내에서 ";", "/", "?", ":", "@", "&", "=", "+", ","및 "$"문자는 예약되어 있습니다.

따라서 " +"문자 로 인코딩 된 쿼리 문자열에 공백이있는 URL을 허용하지 않으면 다른 소프트웨어의 버그입니다 .

질문의 세 번째 부분은 출력을 수정하는 한 가지 방법 (약간 추악하지만) 은 반환 값 URLEncoder.encode()호출 replaceAll("\\+","%20") 하는 것입니다.


이 혼란은 오늘날까지 URL이 여전히 '파손'되었기 때문입니다.

예를 들어 " http://www.google.com "을 선택 하십시오 . 이것은 URL입니다. URL은 Uniform Resource Locator이며 실제로 웹 페이지에 대한 포인터입니다 (대부분의 경우). URL은 실제로 1994 년 첫 번째 사양 이후 매우 잘 정의 된 구조를 가지고 있습니다.

" http://www.google.com "URL 에 대한 자세한 정보를 추출 할 수 있습니다 .

+---------------+-------------------+   
|      Part     |      Data         |   
+---------------+-------------------+   
|  Scheme       | http              |   
|  Host address | www.google.com    |   
+---------------+-------------------+  

" https : // bob : bobby@www.lunatech.com : 8080 / file; p = 1? q = 2 # third " 와 같이보다 복잡한 URL을 보면 다음 정보를 추출 할 수 있습니다.

+-------------------+---------------------+
|        Part       |       Data          |
+-------------------+---------------------+
|  Scheme           | https               |
|  User             | bob                 |
|  Password         | bobby               |
|  Host address     | www.lunatech.com    |
|  Port             | 8080                |
|  Path             | /file               |
|  Path parameters  | p=1                 |
|  Query parameters | q=2                 |
|  Fragment         | third               |
+-------------------+---------------------+

예약 문자는 각 부분마다 다릅니다

HTTP URL의 경우 경로 조각 부분의 공백은 "% 20"( "+"아님)로 인코딩해야하지만 경로 조각 부분의 "+"문자는 인코딩되지 않은 채로 둘 수 있습니다.

이제 쿼리 부분에서 공백은 "+"(이전 버전과의 호환성을 위해 : URI 표준에서 검색하지 마십시오) 또는 "% 20"으로 인코딩 될 수 있지만 "+"문자 (이 모호함의 결과) )를 "% 2B"(으)로 이스케이프해야합니다.

이것은 "blue + light blue"문자열이 경로와 쿼리 부분에서 다르게 인코딩되어야한다는 것을 의미합니다 : " http://example.com/blue+light%20blue?blue%2Blight+blue ". 여기에서 URL 구조를 구문 적으로 인식하지 않으면 완전히 구성된 URL을 인코딩 할 수 없다고 추론 할 수 있습니다.

이것의 비결은

당신은해야 %20전과 ?+

출처


그것은 더 이상은 41 %로 문자 A를 인코딩하는 경우보다 문제.

However, if you're dealing with a system that doesn't recognize one form, it seems like you're just going to have to give it what it expects regardless of what the "spec" says.


You can use either - which means most people opt for "+" as it's more human readable.


When encoding query values, either form, plus or percent-20, is valid; however, since the bandwidth of the internet isn't infinite, you should use plus, since it's two fewer bytes.

참고URL : https://stackoverflow.com/questions/1211229/in-a-url-should-spaces-be-encoded-using-20-or

반응형