프록시 다운로드 후 jsoup의 문자 인코딩 오류
HTML 파싱 전반에 걸쳐 응답의 인코딩 정보를 유지하여 프록시로 불러온 페이지의 깨진 문자를 진단합니다.
페이지는 프록시를 통해 로드되지만 악센트가 있는 문자는 깨져서 돌아옵니다. 프록시를 바꾸기 전에 응답 바이트가 Java String이 되는 첫 지점을 찾으세요. charset을 명시하지 않은 InputStreamReader는 jsoup이 문서를 보기 전에 그 결정을 내릴 수 있습니다.
jsoup이 가져오기를 담당할 때는 파싱할 때까지 응답을 하나로 유지하세요:
Connection.Response response = Jsoup
.connect("https://www.example.com/catalog")
.proxy("proxy.example", 8080)
.execute();
Document page = response.parse();응답 API는 Content-Type에서 파생된 charset 정보를 노출합니다. 서버의 선언이 잘못되었다고 확인한 경우에는 명시적인 charset 재정의도 받아들입니다. 프록시 주소만으로는 문서가 어떤 문자 인코딩을 쓰는지 알 수 없습니다. 프록시 계정 없이 허용된 공개 페이지 비교가 필요하다면 예제의 HTTP 호스트와 포트를 HTTP 프록시 목록의 후보로 바꾸고, 동일한 인코딩 점검은 그대로 유지하세요.
다른 HTTP 클라이언트가 InputStream을 제공하면 jsoup의 스트림 파싱 오버로드는 charset 이름과 기준 URI를 받습니다. charset이 null이면 문서화된 감지와 대체 동작이 허용됩니다. 알려져 있고 올바른 HTTP charset은 의도적으로 넘겨야 합니다. 기준 URI는 상대 링크에 문맥을 제공합니다.
바이트가 잘못 디코딩된 뒤에는 결과 String을 다른 charset으로 파싱해도 원래 텍스트가 복구되지 않습니다. 바이트와 응답 메타데이터로 돌아가세요. 받은 것도 비교해 보세요. 프록시의 로그인 페이지나 거부 응답은 요청한 페이지와 전혀 다른 문서일 수 있으며, 그 안의 디코딩 실패가 아닙니다.