Karakterkoderingfoute in jsoup ná 'n aflaai deur 'n instaanbediener

Die bladsy laai deur die instaanbediener, maar aksentletters kom deurmekaar terug. Voordat jy die instaanbediener verander, vind die eerste plek waar die antwoordgrepe 'n Java String word. 'n InputStreamReader sonder 'n eksplisiete karakterset kan daardie besluit neem voordat jsoup die dokument sien.

Wanneer jsoup die aflaai hanteer, hou die antwoord bymekaar totdat dit ontleed word:

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

Die antwoord-API stel karaktersetinligting beskikbaar wat van Content-Type afgelei is. Dit kan ook 'n eksplisiete karakterset-oorheersing aanvaar wanneer jy vasgestel het dat die bediener se verklaring verkeerd is. 'n Instaanbedieneradres op sigself sê nie watter karakterkodering die dokument gebruik nie. As jy 'n toegelate vergelyking van 'n openbare bladsy sonder 'n instaanbediener-rekening nodig het, vervang die voorbeeld se HTTP-gasheer en -poort met 'n kandidaat uit die HTTP-instaanbedienerlys, terwyl jy dieselfde koderingstoetse behou.

As 'n ander HTTP-kliënt 'n InputStream voorsien, aanvaar jsoup se stroom-ontledingsvariant 'n karaktersetnaam en 'n basis-URI. 'n Nul-karakterset laat die gedokumenteerde opsporing en terugval toe; 'n bekende, korrekte HTTP-karakterset moet doelbewus oorgedra word. Die basis-URI verskaf konteks vir relatiewe skakels.

Sodra grepe verkeerd gedekodeer is, herstel die ontleding van die gevolglike String met 'n ander karakterset nie die oorspronklike teks nie. Gaan terug na die grepe en die antwoord-metadata. Vergelyk ook wat ontvang is: 'n instaanbediener se aanmeldbladsy of weiering kan 'n heeltemal ander dokument as die versoekte bladsy wees, eerder as 'n dekoderingsfout daarin.