Napake pri kodiranju znakov v jsoup po prenosu prek posredniškega strežnika

Stran se naloži prek posredniškega strežnika, vendar se črke z naglasi vrnejo popačene. Preden zamenjate posredniški strežnik, poiščite prvo mesto, kjer bajti odgovora postanejo Java String. InputStreamReader brez izrecnega charseta lahko to odločitev sprejme, preden jsoup vidi dokument.

Ko jsoup prevzame pridobivanje, držite odgovor skupaj do razčlenitve:

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

API odgovora razkrije podatke o charsetu, izpeljane iz Content-Type. Sprejme lahko tudi izrecno prepisovanje charseta, ko ugotovite, da je izjava strežnika napačna. Sam naslov posredniškega strežnika ne pove, katero kodiranje znakov uporablja dokument. Če potrebujete dovoljeno primerjavo javne strani brez računa posredniškega strežnika, zamenjajte gostitelja in vrata HTTP iz primera s kandidatom s seznama posredniških strežnikov HTTP, pri tem pa ohranite enake preverbe kodiranja.

Če drug odjemalec HTTP zagotovi InputStream, preobremenitev pretoka pri razčlenjevanju v jsoup sprejme ime charseta in osnovni URI. Ničelni charset omogoča dokumentirano zaznavanje in nadomestno vedenje; znan in pravilen charset HTTP je treba namerno prenesti naprej. Osnovni URI zagotavlja kontekst za relativne povezave.

Ko so bajti enkrat napačno dekodirani, razčlenjevanje nastalega Stringa z drugim charsetom ne obnovi izvirnega besedila. Vrnite se k bajtom in metapodatkom odgovora. Primerjajte tudi, kaj je bilo prejeto: prijavna stran ali zavrnitev posredniškega strežnika je lahko povsem drug dokument kot zahtevana stran, ne pa napaka pri dekodiranju v njej.