Gabime të kodimit të karaktereve në jsoup pas një shkarkimi përmes proxy-t

Faqja ngarkohet përmes proxy-t, por shkronjat me theks kthehen të përziera. Përpara se të ndryshoni proxy-n, gjeni vendin e parë ku bajtët e përgjigjes bëhen Java String. Një InputStreamReader pa charset të qartë mund ta marrë atë vendim përpara se jsoup ta shohë dokumentin.

Kur jsoup merr përsipër shkarkimin, mbajeni përgjigjen së bashku deri në analizë:

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

API i përgjigjes ekspozon informacion charset të nxjerrë nga Content-Type. Ai mund të pranojë gjithashtu një zëvendësim të qartë të charset-it kur keni vërtetuar se deklarimi i serverit është i gabuar. Një adresë proxy në vetvete nuk ju tregon se çfarë kodimi karakteresh përdor dokumenti. Nëse ju nevojitet një krahasim i lejuar i një faqe publike pa llogari proxy, zëvendësoni hostin dhe portin HTTP të shembullit me një kandidat nga lista e proxy-ve HTTP, duke mbajtur të njëjtat kontrolle kodimi.

Nëse një klient tjetër HTTP furnizon një InputStream, mbingarkesa e analizës së rrjedhës së jsoup pranon një emër charset dhe një URI bazë. Një charset null lejon zbulimin dhe sjelljen e rezervë të dokumentuara; një charset HTTP i njohur dhe i saktë duhet të transferohet me qëllim. URI bazë ofron kontekst për lidhjet relative.

Pasi bajtët janë dekoduar gabimisht, analiza e String-ut që rezulton me një charset tjetër nuk e rikuperon tekstin origjinal. Kthehuni te bajtët dhe te metadata e përgjigjes. Krahasoni gjithashtu atë që u prit: faqja e hyrjes ose refuzimi i një proxy mund të jetë një dokument krejt tjetër nga faqja e kërkuar, dhe jo një dështim dekodimi në të.