Non, ce n'est pas possible depuis le HTML. L'en-tête de réponse du serveur a priorité sur la méta-balise du document. Comme spécifié en 5.2.2 Spécification de l'encodage des caractères - Spécification HTML 4.01 :
Pour résumer, les agents utilisateurs conformes doivent respecter les priorités suivantes lors de la détermination du codage de caractères d'un document (de la priorité la plus élevée à la plus faible):
- Un paramètre HTTP "charset" dans un champ "Content-Type".
- Une déclaration META avec "http-equiv" défini sur "Content-Type" et une valeur définie pour "charset".
- L'attribut charset défini sur un élément qui désigne une ressource externe.
Cela nécessite donc une configuration côté serveur. Cependant, comme le chapitre continue:
Les agents utilisateurs peuvent fournir un mécanisme qui permet aux utilisateurs de remplacer les informations de "jeu de caractères" incorrectes. Cependant, si un agent utilisateur propose un tel mécanisme, il ne doit le proposer que pour la navigation et non pour l'édition, afin d'éviter la création de pages Web marquées avec un paramètre "charset" incorrect.
Dans mon cas, l'en - tête Content-Type du serveur contient le bon type MIME mais le mauvais jeu de caractères .
Il s'est avéré que ma configuration Apache httpd avait AddDefaultCharset
activé la fonction qui ajoutait la ; charset=ISO-8859-1
pièce. Placer dans le répertoire racine des sites Web .htaccess
la ligne suivante:
AddDefaultCharset Off
les informations de jeu de caractères ont été supprimées:
$ curl -I http://example.com/file.html
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 15:07:52 GMT
...
Content-Type: text/html
(voir dernière ligne, aucune ; charset=...
partie). Ceci, en combinaison avec la méta-balise html, déclenche l'heuristique dudit navigateur pour reprendre le jeu de caractères de la méta-balise. Le site Web est correctement décodé.
Testé avec:
- Google Chrome v. 22.0.1229.94
- Firefox v. 16.0.1
- Lynx version 2.8.7rel.1 (5 juil.2009)
Ces trois navigateurs ont eu des problèmes avec la configuration d'origine et fonctionnent maintenant (tous sur Fedora 17).
- Opera 12.02
- Internet Explorer 6 (Win XP SP3)
N'a pas eu le problème en premier lieu. Les deux préféraient UTF-8 de la méta-étiquette au paramètre ISO-8859-1 du serveur.
Ne prend pas en charge UTF-8 et choisit donc toujours Western (Latin1) quels que soient les paramètres du serveur et la balise META.