jsoup-Zeichenkodierungsfehler nach einem Download über einen Proxy

Die Seite lädt über den Proxy, aber akzentuierte Buchstaben kommen verstümmelt zurück. Bevor Sie den Proxy wechseln, suchen Sie die erste Stelle, an der die Antwortbytes zu einem Java String werden. Ein InputStreamReader ohne ausdrückliches Charset kann diese Entscheidung treffen, bevor jsoup das Dokument sieht.

Wenn jsoup den Abruf übernimmt, halten Sie die Antwort bis zur Analyse zusammen:

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

Die Response-API gibt Charset-Informationen aus dem Content-Type preis. Sie kann auch eine ausdrückliche Charset-Überschreibung akzeptieren, wenn Sie festgestellt haben, dass die Angabe des Servers falsch ist. Eine Proxy-Adresse allein sagt Ihnen nicht, welche Zeichenkodierung das Dokument verwendet. Wenn Sie einen zulässigen Vergleich einer öffentlichen Seite ohne Proxy-Konto benötigen, ersetzen Sie HTTP-Host und Port des Beispiels durch einen Kandidaten aus der HTTP-Proxy-Liste, und behalten Sie dieselben Kodierungsprüfungen bei.

Wenn ein anderer HTTP-Client einen InputStream liefert, akzeptiert die Stream-Parse-Überladung von jsoup einen Charset-Namen und eine Basis-URI. Ein Null-Charset erlaubt das dokumentierte Erkennungs- und Rückfallverhalten; ein bekanntes, korrektes HTTP-Charset sollte bewusst weitergegeben werden. Die Basis-URI liefert den Kontext für relative Links.

Sind Bytes erst einmal falsch dekodiert, gewinnt das Parsen des resultierenden String mit einem anderen Charset den ursprünglichen Text nicht zurück. Gehen Sie zurück zu den Bytes und den Metadaten der Antwort. Vergleichen Sie außerdem das Empfangene: Eine Anmeldeseite oder Ablehnung des Proxys kann ein völlig anderes Dokument als die angeforderte Seite sein und kein Dekodierungsfehler darin.