Erros de codificação de caracteres no jsoup após um download por proxy

A página carrega pelo proxy, mas letras acentuadas voltam embaralhadas. Antes de trocar de proxy, encontre o primeiro ponto em que os bytes da resposta se tornam uma String Java. Um InputStreamReader sem charset explícito pode tomar essa decisão antes de o jsoup ver o documento.

Quando o jsoup trata da obtenção, mantenha a resposta unida até a análise:

Connection.Response response = Jsoup
    .connect("https://www.example.com/catalog")
    .proxy("proxy.example", 8080)
    .execute();
Document page = response.parse();

A API de resposta expõe informações de charset derivadas do Content-Type. Ela também pode aceitar uma substituição explícita do charset quando você confirmou que a declaração do servidor está errada. Um endereço de proxy por si só não diz qual codificação de caracteres o documento usa. Se precisar de uma comparação permitida de página pública sem conta de proxy, substitua o host e a porta HTTP do exemplo por um candidato da lista de proxies HTTP, mantendo as mesmas verificações de codificação.

Se outro cliente HTTP fornecer um InputStream, a sobrecarga de análise de fluxo do jsoup aceita um nome de charset e um URI base. Um charset nulo permite a detecção e o comportamento de fallback documentados; um charset HTTP conhecido e correto deve ser transportado deliberadamente. O URI base fornece contexto para links relativos.

Depois que os bytes forem decodificados incorretamente, analisar a String resultante com outro charset não recupera o texto original. Volte aos bytes e aos metadados da resposta. Compare também o que foi recebido: a página de login ou a recusa de um proxy pode ser um documento totalmente diferente da página solicitada, e não uma falha de decodificação nela.