Erreurs d'encodage des caractères dans jsoup après un téléchargement via un proxy

La page se charge via le proxy, mais les lettres accentuées reviennent brouillées. Avant de changer de proxy, trouvez le premier endroit où les octets de la réponse deviennent une String Java. Un InputStreamReader sans charset explicite peut prendre cette décision avant que jsoup ne voie le document.

Lorsque jsoup gère la récupération, gardez la réponse d'un seul tenant jusqu'à l'analyse :

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

L'API de réponse expose les informations de charset dérivées du Content-Type. Elle peut aussi accepter une substitution explicite de charset lorsque vous avez établi que la déclaration du serveur est erronée. Une adresse de proxy seule ne dit pas quel encodage de caractères le document utilise. Si vous avez besoin d'une comparaison autorisée de page publique sans compte proxy, remplacez l'hôte et le port HTTP de l'exemple par un candidat de la liste de proxies HTTP, tout en conservant les mêmes contrôles d'encodage.

Si un autre client HTTP fournit un InputStream, la surcharge d'analyse de flux de jsoup accepte un nom de charset et une URI de base. Un charset nul autorise sa détection et son comportement de repli documentés ; un charset HTTP connu et correct doit être transmis délibérément. L'URI de base fournit le contexte des liens relatifs.

Une fois les octets mal décodés, l'analyse de la String obtenue avec un autre charset ne récupère pas le texte d'origine. Revenez aux octets et aux métadonnées de la réponse. Comparez aussi ce qui a été reçu : la page de connexion ou le refus d'un proxy peut être un document totalement différent de la page demandée, plutôt qu'une erreur de décodage dans celle-ci.