Errores de codificación de caracteres de jsoup tras una descarga a través de un proxy

La página se carga a través del proxy, pero las letras acentuadas vuelven desordenadas. Antes de cambiar de proxy, localiza el primer punto en el que los bytes de la respuesta se convierten en un String de Java. Un InputStreamReader sin charset explícito puede tomar esa decisión antes de que jsoup vea el documento.

Cuando jsoup se encarga de la descarga, mantén la respuesta unida hasta el análisis:

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

La API de respuesta expone información de charset derivada del Content-Type. También puede aceptar una sustitución explícita del charset cuando hayas comprobado que la declaración del servidor es incorrecta. Una dirección de proxy por sí sola no te dice qué codificación de caracteres usa el documento. Si necesitas una comparación permitida de una página pública sin cuenta de proxy, sustituye el host y el puerto HTTP del ejemplo por un candidato de la lista de proxies HTTP, manteniendo las mismas comprobaciones de codificación.

Si otro cliente HTTP proporciona un InputStream, la sobrecarga de análisis de flujo de jsoup acepta un nombre de charset y un URI base. Un charset nulo permite su detección y comportamiento de reserva documentados; un charset HTTP conocido y correcto debe transferirse deliberadamente. El URI base aporta contexto para los enlaces relativos.

Una vez que los bytes se han decodificado incorrectamente, analizar el String resultante con otro charset no recupera el texto original. Vuelve a los bytes y a los metadatos de la respuesta. Compara también lo recibido: la página de inicio de sesión o la denegación de un proxy puede ser un documento completamente distinto de la página solicitada, en lugar de un fallo de decodificación en ella.