jsoup-tekencoderingfouten na een download via een proxy

De pagina laadt via de proxy, maar letters met accenten komen door elkaar gehusseld terug. Voordat je van proxy wisselt, zoek de eerste plek waar de bytes van de respons een Java String worden. Een InputStreamReader zonder expliciete charset kan die beslissing nemen voordat jsoup het document ziet.

Wanneer jsoup de fetch afhandelt, houd de respons bij elkaar tot het parsen:

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

De respons-API toont charset-informatie die van Content-Type is afgeleid. Hij kan ook een expliciete charset-overschrijving accepteren wanneer je hebt vastgesteld dat de verklaring van de server onjuist is. Een proxyadres op zichzelf zegt niet welke tekencodering het document gebruikt. Als je een toegestane vergelijking van een openbare pagina zonder proxyaccount nodig hebt, vervang dan de HTTP-host en -poort uit het voorbeeld door een kandidaat uit de HTTP-proxylijst, terwijl je dezelfde coderingscontroles houdt.

Als een andere HTTP-client een InputStream levert, accepteert de stream-parse-overload van jsoup een charset-naam en een basis-URI. Een null-charset staat het gedocumenteerde detectie- en terugvalgedrag toe; een bekende en juiste HTTP-charset moet bewust worden doorgegeven. De basis-URI geeft context voor relatieve links.

Zodra bytes verkeerd zijn gedecodeerd, haalt het parsen van de resulterende String met een andere charset de oorspronkelijke tekst niet terug. Ga terug naar de bytes en de metadata van de respons. Vergelijk ook wat is ontvangen: de inlogpagina of weigering van een proxy kan een heel ander document zijn dan de opgevraagde pagina, in plaats van een decoderingsfout daarin.