Erros de codificación de caracteres de jsoup tras unha descarga a través dun proxy

A páxina cárgase a través do proxy, pero as letras acentuadas volven desordenadas. Antes de cambiar de proxy, localiza o primeiro punto no que os bytes da resposta se converten nun String de Java. Un InputStreamReader sen charset explícito pode tomar esa decisión antes de que jsoup vexa o documento.

Cando jsoup se encarga da descarga, mantén a resposta unida ata 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ón información de charset derivada do Content-Type. Tamén pode aceptar unha substitución explícita do charset cando comprobases que a declaración do servidor é incorrecta. Un enderezo de proxy por si só non che di que codificación de caracteres usa o documento. Se necesitas unha comparación permitida dunha páxina pública sen conta de proxy, substitúe o host e o porto HTTP do exemplo por un candidato da lista de proxies HTTP, mantendo as mesmas comprobacións de codificación.

Se outro cliente HTTP fornece un InputStream, a sobrecarga de análise de fluxo de jsoup acepta un nome de charset e un URI base. Un charset nulo permite a súa detección e comportamento de reserva documentados; un charset HTTP coñecido e correcto debe transferirse deliberadamente. O URI base achega contexto para as ligazóns relativas.

Unha vez que os bytes se decodificaron incorrectamente, analizar o String resultante con outro charset non recupera o texto orixinal. Volve aos bytes e aos metadatos da resposta. Compara tamén o recibido: a páxina de inicio de sesión ou a denegación dun proxy pode ser un documento completamente distinto da páxina solicitada, en lugar dun fallo de decodificación nela.