Errors de codificació de caràcters a jsoup després d'una descàrrega a través d'un proxy

La pàgina es carrega a través del proxy, però les lletres accentuades tornen desordenades. Abans de canviar de proxy, troba el primer lloc on els bytes de la resposta esdevenen un String de Java. Un InputStreamReader sense charset explícit pot prendre aquesta decisió abans que jsoup vegi el document.

Quan jsoup gestiona l'obtenció, mantén la resposta unida fins a l'anàlisi:

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

L'API de resposta exposa informació de charset derivada del Content-Type. També pot acceptar una substitució explícita del charset quan has establert que la declaració del servidor és incorrecta. Una adreça de proxy per si sola no et diu quina codificació de caràcters utilitza el document. Si necessites una comparació permesa de pàgina pública sense compte de proxy, substitueix l'amfitrió i el port HTTP de l'exemple per un candidat de la llista de proxies HTTP, tot mantenint les mateixes comprovacions de codificació.

Si un altre client HTTP proporciona un InputStream, la variant d'anàlisi de flux de jsoup accepta un nom de charset i un URI base. Un charset nul permet la detecció i el comportament de reserva documentats; un charset HTTP conegut i correcte s'ha de traslladar deliberadament. L'URI base proporciona context per als enllaços relatius.

Un cop els bytes s'han descodificat incorrectament, analitzar el String resultant amb un altre charset no recupera el text original. Torna als bytes i a les metadades de la resposta. Compara també què s'ha rebut: la pàgina d'inici de sessió o la denegació d'un proxy poden ser un document completament diferent de la pàgina sol·licitada, i no una fallada de descodificació en ella.