HttpWebRequest: recevoir une réponse avec le bon encodage

Question

Je télécharge actuellement une page HTML à l'aide du code suivant:

Try
    Dim req As System.Net.HttpWebRequest = DirectCast(WebRequest.Create(URL), HttpWebRequest)
    req.Method = "GET"
    Dim resp As Net.HttpWebResponse = DirectCast(req.GetResponse(), Net.HttpWebResponse)
    Dim stIn As IO.StreamReader = New IO.StreamReader(resp.GetResponseStream())
    Dim strResponse As String = stIn.ReadToEnd

    ''Clean up
    stIn.Close()
    stIn.Dispose()
    resp.Close()

    Return strResponse

Catch ex As Exception
    Return ""
End Try

Cela fonctionne bien pour la plupart des pages, mais pour certaines (par exemple: www.gap.com), la réponse est mal codée.
Dans gap.com, par exemple, le message "& # 8217;" est affiché. comme "?" &
;
Et sans parler de ce qui se passe si je tente de charger google.cn ...

Qu'est-ce qui me manque ici, pour que .Net code ce droit?

Ma plus grande crainte est de devoir lire la balise méta dans le code HTML spécifiant le codage, puis de relire (ré-encoder?) l'intégralité du flux.

Tous les indicateurs seront grandement appréciés.

UPDATE:

Merci à la réponse de John Saunders, je suis un peu plus proche. La propriété HttpWebResponse.ContentEncoding semble toujours être vide. Cependant, HttpWebResponse.CharacterSet semble utile, et avec ce code, je me rapproche:

Dim resp As Net.HttpWebResponse = DirectCast(req.GetResponse(), Net.HttpWebResponse)
Dim respEncoding As Encoding = Encoding.GetEncoding(resp.CharacterSet)
Dim stIn As IO.StreamReader = New IO.StreamReader(resp.GetResponseStream(), respEncoding)

Maintenant, Google.cn entre parfaitement, avec tous les caractères chinois.
Cependant, Gap.Com arrive toujours dans l'erreur.

Pour Gap.com, HttpWebResponse.CharacterSet est ISO-8859-1, l’encodage auquel je parviens par GetEncoding est {System.Text.Latin1Encoding}, qui indique "ISO-8859-1". dans son nom de corps ET la balise META Content-Type dans le "jeu de caractères = ISO-8859-1" spécifié par HTML.

Est-ce que je fais toujours quelque chose de mal?
Ou bien GAP fait-il quelque chose de mal?

Answer 1

Le site de Gap est faux. Le problème spécifique est que leur page réclame un codage de Latin1 (ISO-8859-1), alors que la page utilise le caractère n ° 146 qui n’est pas valide dans ISO-8859-1.

Ce caractère est toutefois valide dans le codage Windows CP-1252 (qui est un sur-ensemble de la norme ISO 8859-1). Dans CP-1252, le code de caractère n ° 146 est utilisé pour le caractère de citation à droite. Vous verrez cela comme une apostrophe dans "Vous trouverez Petites et petites tailles". dans le texte d'aujourd'hui sur la page d'accueil de Gap.com.

Vous pouvez lire http://fr.wikipedia.org/wiki/Windows-1252 pour plus de détails. Il s’avère que ce type de problème est un problème courant sur les pages Web dont le contenu a été initialement enregistré dans le codage CP-1252 (par exemple, copier / coller depuis Word).

Morale de l'histoire ici: stockez toujours le texte internationalisé au format Unicode dans votre base de données et émettez toujours le code HTML au format UTF8 sur votre serveur Web!

Answer 2

Je pense que HttpWebResponse a une propriété ContentEncoding. Utilisez-le dans le constructeur de votre StreamReader.

Answer 3

Daniel, Certaines pages ne renvoient même pas de valeur dans CharacterSet . Cette approche n'est donc pas si fiable. Parfois, même les navigateurs ne sont pas en mesure de "deviner" quel encodage utiliser, donc je pense que vous ne pouvez pas faire une reconnaissance à 100%.

Dans mon cas particulier, lorsque je traite des pages en espagnol ou en portugais, j'utilise le codage UTF7 et cela fonctionne très bien pour moi (áéíúúñÑêê ... etc).

Peut-être que vous pouvez d’abord charger une table de codes CharacterSet et leur codage correspondant. Et si le CharacterSet est vide, vous pouvez fournir un encodage par défaut.

Le paramètre detectEncodingFromByteOrderMarks dans le constructeur StreamReader peut aider un peu, car il détecte ou déduit automatiquement certains codages dès les premiers octets.