web-dev-qa-db-fra.com

Comment indiquer au navigateur l'encodage des caractères d'un site Web HTML indépendamment de l'en-tête Server Content-Type?

J'ai une page HTML que correctement (l'encodage de la physique sur le disque correspond) annonce son Content-Type:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="Content-Type" content=
    "text/html; charset=utf-8">
    <title> ...

Ouvrir le fichier à partir du disque dans le navigateur (Google Chrome, Firefox) fonctionne bien.

En le demandant via HTTP, le serveur Web envoie un en-tête Content-Type différent:

$ curl -I http://example.com/file.html
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 10:57:13 GMT
...
Content-Type: text/html; charset=ISO-8859-1

(voir dernière ligne). Le navigateur utilise ensuite ISO-8859-1 pour afficher le résultat non souhaité.

Existe-t-il un moyen courant de remplacer les en-têtes de serveur envoyés au navigateur à partir du document HTML?

htmlbrowsershttp-headerscontent-encoding
9
hakre

"Existe-t-il un moyen courant de remplacer les en-têtes de serveur envoyés au navigateur à partir du document HTML?"

Autant que je sache, vous faites ce que vous pouvez déjà faire. Le jeu de caractères défini via Header l'emporte sur votre définition dans la balise META.

Si vous avez accès au serveur, par exemple Apache, il est configuré par cette déclaration (voir les lignes de commentaire):

# Read the documentation before enabling AddDefaultCharset.
# In general, it is only a good idea if you know that all your files
# have this encoding. It will override any encoding given in the files
# in meta http-equiv or xml encoding tags.

#AddDefaultCharset UTF-8

[Mettre à jour]

Au second commentaire de w3d, vous trouverez ici quelques façons de changer le jeu de caractères via htaccess-Directives pour le serveur Apache.

6
initall

Vous devriez mettre quelque chose comme ça dans votre racine .htaccess

<FilesMatch "\.(htm|html|xhtml|xml|php)$">
    AddDefaultCharset utf-8
</FilesMatch>
3
PatomaS

Non, ce n'est pas possible à partir du code HTML. L'en-tête de réponse du serveur est prioritaire sur la méta-balise du document. Comme spécifié dans 5.2.2 Spécification du codage de caractères - Spécification HTML 4.01 :

En résumé, 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 basse):

  1. Un paramètre "charset" HTTP dans un champ "Content-Type".
  2. Une déclaration META avec "http-equiv" défini sur "Content-Type" et une valeur définie sur "charset".
  3. L'attribut charset défini sur un élément désignant une ressource externe.

Cela nécessite donc une configuration côté serveur. Cependant, comme le chapitre continue:

Les agents d'utilisateur peuvent fournir un mécanisme permettant aux utilisateurs de remplacer des informations de "jeu de caractères" incorrectes. Cependant, si un agent utilisateur offre un tel mécanisme, il ne doit l'offrir 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 du serveur Content-Type contient le droit mime-type mais le mauvais jeu de caractères .

En fait, ma configuration Apache httpd avait activé la fonction AddDefaultCharset, ce qui ajoutait la partie ; charset=ISO-8859-1. 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, pas de partie ; charset=...). Cette combinaison avec la balise méta html déclenche les heuristiques dudit navigateur pour reprendre le jeu de caractères de la balise méta. Le site est correctement décodé.

Testé avec:

  • Google Chrome v. 22.0.1229.94
  • Firefox v. 16.0.1
  • Lynx version 2.8.7rel.1 (05 juil. 2009)

Ces trois navigateurs ont eu des problèmes avec la configuration d'origine et fonctionnent maintenant (tous sur Fedora 17).

  • Opéra 12.02
  • Internet Explorer 6 (Win XP SP3)

Je n'ai pas eu le problème en premier lieu. Les deux préféraient UTF-8 de la méta-étiquette à la ISO-8859-1 réglage du serveur.

  • Netscape 2.01 Gold

Ne supporte pas UTF-8, donc il faut toujours choisir Western (Latin1) indépendamment du paramétrage du serveur et de la méta-balise.

3
hakre

En plus de ce qui a été dit ici, j'essaierais d'utiliser le même jeu de caractères dans toutes les pages - de préférence UTF-8 (mais si presque tout est iso-8859-1, utilisez ceci).

Pour vérifier rapidement le jeu de caractères d'un fichier, vous pouvez essayer:

file --mime-type --mime-encoding {filename}

Pour vérifier le jeu de caractères de tous les fichiers de l’arbre, vous pouvez essayer:

find . -type f -exec file --mime-type --mime-encoding '{}' \;

ou (en appelant la commande file une seule fois):

find . -type f -print | file --mime-type --mime-encoding -f-

Pour obtenir un résumé, utilisez l'option -b de la commande file (pour omettre les noms de fichiers) et dirigez le résultat vers sort | uniq -c.

1
Tobias