Le codage utf-8 fonctionne-t-il ?

Septembre 2003

Bonjour,

Je suis débutant avec SPIP et j’ai du mal à comprendre comment on peut utiliser l’utf-8. Dans les paramètres avancés du site, j’ai donc choisi d’utiliser l’utf-8 pour la base de données. J’ai ensuite créé mon premier article en lui mettant exprès des accents dans le titre, histoire de tester.

Le résultat : dans la base de données, la lettre "é" a bien été convertie en utf-8, ça donne "Ã©". Le problème, c’est que lorsque j’affiche la page, bien qu’elle ait comme type de contenu "text/html ; charset=utf-8", les caractères sont affichés "bruts" avec Mozilla et Opera., donc je vois "Ã©" et pas "é". Seul Konqueror affiche correctement le caractère "é". Y a-t-il une solution ?

Merci de votre aide.

Grégoire

Résolu

Par note Par date Par date chronologique

Indiquez l’intérêt que vous portez à cette réponse

0

Septembre 2003

Salut,

Je me réponds à moi-même pour ceux qui s’arrachent encore les cheveux : le problème vient d’Apache, SPIP n’y est pour rien. Dans la version 2.0.47, le fichier "/etc/httpd/conf/commonhttpd.conf" contient la ligne "AddDefaultCharset ISO-8859-1".
Le truc, c’est qu’Apache ne regarde pas le contenu du fichier HTML, seulement les extensions. Comme rien n’indique que le codage utilisé est UTF-8 extérieurement, Apache envoie la page avec comme information HTTP le charset ISO-8859-1. Le cœur du problème, c’est que Mozilla et Opera font confiance à Apache si cette information est présente, et ne prennent alors pas la peine de regarder dans la page HTML ce que l’auteur de la page a écrit. Incroyable mais vrai. Du coup on se récupère les caractères UTF-8 codés en ISO-8859-1.

Si ce problème vous arrive, mettez en commentaire la ligne sus-mentionnée dans "commonhttpd.conf", ce qui obligera Mozilla et Opera à regarder le codage indiqué par la page HTML. Ce bogue est à rapprocher du rapport #14513 sur le BugZilla d’Apache, inutile donc de le signaler, il est déjà connu.

Grégoire
Indiquez l’intérêt que vous portez à cette réponse

0

Septembre 2003

Salut,

Je complète mon explication.

En fait, la norme HTTP 1.1 dit que les navigateurs DOIVENT respecter le codage indiqué par l’entête HTTP. Donc Opera et Mozilla respectent bien la norme.

La seule solution pour avoir le codage UTF-8 bien détecté par ces navigateurs est d’indiquer explicitement l’encodage utilisé avec la fonction "header()" de PHP.

Pour du XHTML avec encodage UTF-8, ça donne comme première ligne de chaque script PHP :
header("Content-type : application/xhtml+xml ; charset=utf-8") ;

Mais le Content-type "application/xhtml+xml" faisant planter Microsoft Internet Explorer (ah ah), on peut servir le XHTML avec :
header("Content-type : text/html ; charset=utf-8") ;
mais attention, "text/html" est officiellement déconseillé par le W3C dans le cas du XHTML.

L’important pour cette histoire de codage, c’est bien sûr ce que l’on met après "charset=". SPIP devrait utiliser la fonction header() de PHP pour envoyer le bon Content-type avec le squelette par défaut, lorsque la base de données utilise l’UTF-8.

G.
Indiquez l’intérêt que vous portez à cette réponse

0

elbouillon

Septembre 2006

Bonjour,

Je comprend tout à fait le problème, l’encodage de mon site fonctionne sur toutes les pages, sauf... la 404... c’est la seul que spip, ou mon navigateur ne veut pas encoder juste.

Toutes mes pages sont encodée en utf-8 sans problème, exemple de page saine

Et voici ce que ça donne sur la page d’erreur 404

Quelqu’un pourrait m’expliquer, ou m’aider ?

Merci d’avance
Indiquez l’intérêt que vous portez à cette réponse

0

S LEVEQUE

Octobre 2006

Nouvelle installation Spip1.9.1 : problème d’affichage UTF-8

J’ai moi-même un soucis : J’utilisais l’en tête #HTTP_HEADER{Content-Type: text/html} dans mes squelettes, car j’avais constaté que sans celle-ci, mes fonctions javascript ne fonctionnaient pas (lié à l’activation des bontons d’administration ?? activation par "document.onmouseover=fonction ;").

Or lorsque je suis passé à la version 1.9.1, j’ai voulu passé ma base en UTF-8 : base converti en UTF-8, SPIP passé en UTF-8. Et surprise, pb d’accents mal géré !! seul le retour de la base en iso 8859-1 de la base et de SPIP résolvait le pb. Puis, je me suis appercu quand surprimant #HTTP_HEADER, le pb d’accent était supprimé.....mais mes fonctions javascript inibées !! J’ai testé avec #HTTP_HEADER{Content-Type: text/html; charset=#CHARSET}, ça ne change rien.

J’ai un squelette "entete" que j’inclu dans mes pages. Doit-on mettre #HTTP_HEADER dans ce squelette ? ou dans le quelette principale (appelant) ? car si #HTTP_HEADER{Content-Type: text/html; charset=#CHARSET} ne change pas le pb qu’il soit mis dans le squelette "entete" ou dans la page principale, en revanche lorsque je met #HTTP_HEADER{Content-Type: text/html} seulement, il n’est pris en compte semble t’il que dans le squelette principale (donc pb d’accent, mais fonctions javascript actives). Dans le squelette "entete", pas d’effet, donc pas de pb d’accent , mais pb de javascript.

A préciser : tests effectués avec la balise <meta http-equiv="Content-Type" content="text/html; charset=#CHARSET"> rajoutée ou non, ça ne change rien... Pour mes pb de javascript,comme je pensais que c’était lié aux bontons d’administration, j’ai essayé de mettre $flag_preserver=True dans le fichier mes_fonctions et mes_options, aucun effets...

Quelqu’un peut’il m’éclairer, car je tourne en rond depuis en bout de temps déjà... merci d’avance !

Cordialement.
Indiquez l’intérêt que vous portez à cette réponse

0

Novembre 2008

Dans un modèle je faisais un accès à une base non spip en utf-8 alors que mes bases spip sont en latin1_...
en mettant le EVAL mysql_query("SET NAMES ’utf8’") ; cela à supprimé les incohérences d’ encodage
car la page était bien en utf-8 mais bizarrement bien que la table Mysql unetablenonspip était en utf-8 leur encodage dans la page devenait de l’ISO-88519-1. Voici ce qui fonctionne chez moi :
#EVAL{mysql_query("SET NAMES 'utf8'");} <BOUCLE_tablenonspip(unetablenonspip)> #CHAMP1 , #NOM <br> </BOUCLE_tablenonspip>
Indiquez l’intérêt que vous portez à cette réponse

0

neofutur

Mai 2010

la procedure signalee sur http://benjamin.sonntag.fr/Resolu-Probleme-de-recherche-avec-accents-dans-Spip

a resolu pour moi ce genre de problemes :

$ mysqldump -unom_utilisateur -pmot_de_passe —quote-names —set-charset —default-character-set=latin1 nom_de_base_spip > dump.sql $ cat dump.sql |sed -e ’s/latin1/utf8/g’ >dump2.sql $ mysql -unom_utilisateur -pmot_de_passe nom_de_base_spip < dump2.sql

puis
modifiez le fichier config/connect.php pour y ajouter, juste après le spip_connect_db, la ligne suivante :
mysql_query("SET NAMES ’utf8’") ;