[Résolu] Dreamweaver CS4 - PHP - MySQL - Encodage

Bonjour à tous,
Je suis en train de créer un site dynamique avec Dreamweaver CS4 en local.
J'utilise : [b]WampServer 2.0, [b]PHP 5.2.5, Apache 2.2.8 et MySQL 5.0.51a.
Mes données dans ma table sont en interclassement [/b]utf8_bin[/b].
Mes pages PHP faites avec DW sont encodées en content="text/html; charset=utf-8"
Quand je teste mes pages, ça coince, j'ai des � : ? dans losange noir.
Sur la page Tutoriel UTF-8 PHP MySQLQ il est indiqué que :

a écrit :
Si la page affiche des caractères de ce type : � (? dans losange noir)
=> Les données ont été enregistrées au format ISO, et le navigateur les affiche en pensant avoir affaire à de l'UTF-8.

Pourtant dans ma base MySQL j'ai bien un interclassement en UTF-8 ?
Sachant que les données sont importées depuis un fichier .sql enregistré au format UTF-8 (avec EditPlus)
Qu'est-ce qui peut coincer ?
Merci de votre aide
Modifié par krakkos (15 May 2009 - 15:17)

L'interclassement ce n'est pas les données. Il faut aussi envoyer les bons headers.

Content-Type: text/html; charset=UTF-8

Modifié par Patidou (14 May 2009 - 12:19)

Salut,

plus globalement (re)lire l'annonce de ce salon.

En plus des headers à vérifier il faudra à priori préciser que la connexion se fait en utf8 :

mysql_query('SET NAMES UTF8');

à placer juste après la connexion à la base.

Je dirais que la connexion se fait en ISO-8859-1, et que donc MySQL mouline pour faire de l'ISO-8859-1 à partir du contenu initialement en UTF-8. Donc les données reçues sont en ISO-8859-1.

Mais je m'avance un peu, ça pourrait tout à fait être autre chose.

Merci Heyoan, la solution est bien celle-ci : ajouter mysql_query("SET NAMES 'utf8'"); en dernière ligne du fichier de connexion à ma base.
Cool...

J'ai trouvé cette page très didactique en ce qui concerne les 3 différentes normes d'encodage UTF-8 que l'on peut utiliser dans MySQL

Il ne s'agit pas de règles de codage, mais de mode de tri pour les données UTF-8 dans MySQL. C'est un mécanisme de MySQL qui lui permet de savoir dans quel ordre classer des données lorsqu'on lui demande un tri ascendant ou descendant sur des valeurs textuelles.

krakkos a écrit :
- Cela veut dire que l'interclassement est utile strictement en interne dans MySQL (affichage, tri, recherche) ?

Pas l'affichage mais le tri, la recherche, les index FULLTEXT.

krakkos a écrit :
- Cela veut dire que l'interclassement n'intervient pas dans l'affichage des données dans le navigateur web avec une page dynamique PHP ?

Non : PHP ne sert ensuite qu'à afficher les résultats de la requête qui eux sont triés en fonction de l'interclassement.

krakkos a écrit :
En conclusion, si mes données sont bien importées en UTF-8 dans MySQL, il faut impérativement avoir un charset="UTF-8" dans mes pages PHP Dreamweaver et insérer mysql_query("SET NAMES 'utf8'"); dans le fichier de connexion ?

Pas impérativement puisque, comme tu as pu le voir, il est possible de se connecter par exemple en iso-8859-1 -que ce soit par défaut ou en précisant mysql_query('SET NAMES LATIN1');- et déclarer sa page en LATIN1 également (headers et meta "Content-Type"). Ce serait juste illogique et forcerait inutilement la conversion des données.

Merci Heyoan pour ces précisions.

Si je récapitule ma problématique, en une méthodo logique :

1) Avoir mon fichier .sql d'importation de données en UTF-8
2) Créer une base dans MySQL avec interclassement en UTF-8 pour la base et pour la connexion
3) Insérer la ligne de code mysql_query("SET NAMES 'utf8'"); dans le fichier PHP de connexion généré par Dreaweaver
4) Avoir un encodage UTF-8 dans mes fichiers PHP Dreamweaver (encodage par défaut d'ailleurs)

Ainsi toute ma chaîne de création est en UTF-8.

krakkos a écrit :
1) Avoir mon fichier .sql d'importation de données en UTF-8

Je suppose que ça veut dire : récupérer mes données encodées en UTF-8.

krakkos a écrit :
2) Créer une base dans MySQL avec interclassement en UTF-8 pour la base et pour la connexion

Et donc avec un encodage (ou charset) en UTF-8.

krakkos a écrit :
Ainsi toute ma chaîne de création est en UTF-8.

Il ne faut pas oublier de vérifier les en-têtes envoyées par le serveur car si elles spécifient un encodage en LATIN1 (iso-8859-1) cela sera prioritaire par rapport à la balise <meta> "Content-Type". Il faudra alors :

* soit mettre dans un fichier .htaccess à la racine du site

AddDefaultCharset UTF-8

*soit inclure une ligne PHP au début de toutes tes pages :

<?php header('Content-type: text/html; charset=UTF-8', true); ?>

Heyoan a écrit :
krakkos a écrit :
1) Avoir mon fichier .sql d'importation de données en UTF-8

Je suppose que ça veut dire : récupérer mes données encodées en UTF-8.

Je veux dire par la que mes données ne sont pas saisie directement dans MySQL. Elles sont présentes dans un fichier .sql. Et dans MySQL j'importe ce fichier après avoir créé la base.

Heyoan a écrit :
Il ne faut pas oublier de vérifier les en-têtes envoyées par le serveur

Comment faire ?
Est-ce que http://web-sniffer.net/ fonctionne pour des tests en local avec WampServer ?

Edit : je viens de tester, cela ne fonctionne pas en local
Modifié par krakkos (15 May 2009 - 14:13)

krakkos a écrit :
Est-ce que http://web-sniffer.net/ fonctionne pour des tests en local avec WampServer ?

En local la question ne se pose pas puisque Wampserver ne déclare aucun encodage (par défaut en tout cas). Sinon tu peux installer une extension Firefox qui permet de connaître les en-têtes envoyées (il me semble que web developper le fait nativement ou bien il faut utiliser LiveHTTPHeaders...) et qui fonctionnera également en local.

Heyoan a écrit :
il me semble que web developper le fait nativement

C'est le cas. Information > View Response Headers
Modifié par Florent V. (15 May 2009 - 14:31)

Je viens de tester avec Web Developer : la réponse est

Content-Type: text/html

Pas plus de précisions sur l'encodage

krakkos a écrit :
Je viens de tester avec Web Developer : la réponse est

Content-Type: text/html

Pas plus de précisions sur l'encodage

Eh bien non : cela signifie qu'aucun encodage n'est déclaré et que c'est donc la balise meta qui sera prise en compte.

Heyoan a écrit :
cela signifie qu'aucun encodage n'est déclaré

Cela veut donc dire que ce n'est pas un paramètre obligatoire pour le serveur ? Ou bien est-ce juste parce que j'utilise un serveur web local ?

krakkos a écrit :
Cela veut donc dire que ce n'est pas un paramètre obligatoire pour le serveur ?

Oui.

Un très merci pour toutes ces réponses techniques et précises.
C'est enfin clair dans ma p'tite tête