내가 읽은 바로는 브라우저가 요청이 생성 된 양식의 문자 집합에있는 요청에서 x-www-form-urlencoded 데이터를 보내야하는 것처럼 보입니다.utf8 = ✓를 쿼리에 추가하는 이유는 무엇입니까?
그렇다면 http://www.railscasts.com과 같은 일부 웹 사이트는 양식에? utf8 = % E2 % 9C % 93 (that? utf8 = ✓)을 추가하는 이유는 무엇입니까? 이 작업이 더 쉽게 할 수있는 해킹입니까? 해당 페이지의 문자 세트는 이미 UTF-8이므로 (헤더를 확인 했으므로) 브라우저가 UTF-8을 전송할 것이라고 보장 할 수 없습니까? 어떤 브라우저가 이것을하지 않습니까? w3schools에 따르면 모든 주요 브라우저는 양식에서 accept-charset을 구현합니다.
<form accept-charset="UTF-8">
그런데 왜 대신 사용되지 않습니까? 아니면 (응답에서 UTF-8을 지정 했으므로) 아무 것도하지 않습니까?
search:%E6%9C%A8
을 따라서 나타나는 퍼센트 인코딩을 사용하고 :
내가 몇 가지 조사를했다 : 木 (U + 6728)을 검색 제공하지만 같은 UTF-8 페이지에서을,이 나타납니다 기본 문자 집합이 무엇이든간에 16 진수 인코딩을 바이트 단위로 인코딩하는 것입니다. 음, 확실히 작동합니다. this place은 이것이 UTF-8 인코딩이라고 말하기 때문입니다. 좋습니다.하지만 UTF-8 데이터를 UTF-8 페이지로 보내려고하는 간단한 경우입니다.
이제 양식이있는 ISO-8859-1 페이지가 있다고 가정 해 보겠습니다. 그것은 GET 양식이며 필드에 동일한 木을 입력하기로 결정했습니다. 음, 확실히 ISO-8859-1이 아닙니다. 그래서 Chrome은
search:木
으로 인코딩 한 다음 적절하게 백분율로 인코딩하여 %26%2326408%3B으로 적절하게 인코딩합니다. Internet Explorer 8이 Windows에서 동일한 기능을 수행하는지 확인했습니다. 그렇다면 UTF-8 해킹의 핵심은 무엇입니까?
관련 질문 : 다른 브라우저는 서로 다른 인코딩 데이터를 제출하면 숨겨진 데이터와 같은 일부 특수 문자를 추가하는 기술은, 예전에 개발 된 Detecting the character encoding of an HTTP POST request