Erori de codificare a caracterelor în jsoup după o descărcare prin proxy

Pagina se încarcă prin proxy, dar literele cu accente revin amestecate. Înainte de a schimba proxy-ul, găsiți primul loc în care octeții răspunsului devin un Java String. Un InputStreamReader fără charset explicit poate lua această decizie înainte ca jsoup să vadă documentul.

Când jsoup se ocupă de preluare, țineți răspunsul împreună până la analiză:

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

API-ul răspunsului expune informații despre charset derivate din Content-Type. Poate accepta și o suprascriere explicită a charsetului atunci când ați stabilit că declarația serverului este greșită. O adresă de proxy în sine nu vă spune ce codare a caracterelor folosește documentul. Dacă aveți nevoie de o comparație permisă a unei pagini publice fără cont de proxy, înlocuiți gazda și portul HTTP din exemplu cu un candidat din lista de proxy-uri HTTP, păstrând aceleași verificări de codare.

Dacă un alt client HTTP furnizează un InputStream, supraîncărcarea de analiză a fluxului din jsoup acceptă un nume de charset și un URI de bază. Un charset nul permite detectarea și comportamentul de rezervă documentate; un charset HTTP cunoscut și corect trebuie transmis în mod deliberat. URI-ul de bază oferă context pentru legăturile relative.

Odată ce octeții au fost decodați greșit, analiza Stringului rezultat cu alt charset nu recuperează textul original. Reveniți la octeți și la metadatele răspunsului. Comparați și ce s-a primit: pagina de autentificare sau refuzul unui proxy poate fi un document complet diferit de pagina solicitată, nu o eroare de decodare în ea.