jsoupin merkistökoodausvirheet välityspalvelimen kautta tehdyn latauksen jälkeen

Sivu latautuu välityspalvelimen kautta, mutta aksentoidut kirjaimet palaavat sotkeutuneina. Ennen kuin vaihdat välityspalvelinta, etsi ensimmäinen kohta, jossa vastauksen tavut muuttuvat Java Stringiksi. InputStreamReader ilman nimenomaista charsetiä voi tehdä tämän päätöksen ennen kuin jsoup näkee asiakirjan.

Kun jsoup hoitaa noudon, pidä vastaus yhtenä jäsennykseen asti:

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

Vastauksen API paljastaa Content-Typestä johdetut charset-tiedot. Se voi myös hyväksyä nimenomaisen charsetin ohituksen, kun olet todennut palvelimen ilmoituksen virheelliseksi. Pelkkä välityspalvelimen osoite ei kerro, mitä merkistökoodausta asiakirja käyttää. Jos tarvitset sallitun julkisen sivun vertailun ilman välityspalvelintiliä, korvaa esimerkin HTTP-isäntä ja -portti ehdokkaalla HTTP-välityspalvelinluettelosta ja säilytä samat koodaustarkistukset.

Jos toinen HTTP-asiakas toimittaa InputStreamin, jsoupin virran jäsennyksen ylikuormitus hyväksyy charsetin nimen ja perus-URI:n. Null-charset sallii dokumentoidun tunnistuksen ja varatoiminnan; tunnettu ja oikea HTTP-charset on välitettävä tarkoituksella. Perus-URI antaa asiayhteyden suhteellisille linkeille.

Kun tavut on kerran dekoodattu väärin, tuloksena olevan Stringin jäsentäminen toisella charsetillä ei palauta alkuperäistä tekstiä. Palaa tavuihin ja vastauksen metatietoihin. Vertaa myös sitä, mitä vastaanotettiin: välityspalvelimen kirjautumissivu tai hylkäys voi olla täysin eri asiakirja kuin pyydetty sivu, eikä siinä oleva dekoodausvirhe.