Bonjour,


Depuis que j'ai mis mon site en utf-8, les textes affichés par la base de donnée qui comportes des caractères spéciaux s'affichent avec des signes bizarres, ils s'affichent en ISO, mais sur une page en UTF-8.

Donc je voudrais convertir ma base de donnée en utf-8, j'ai trouvé plusieurs messages sur des forums notamment ici mais ça ne fonctionne pas chez moi !

Avant d'essayer avec toute ma base de donnée j'essaye avec 1 seule table, je l'ai exportée, j'ouvre le fichier texte dans notepad++, je converti tout ça en utf-8, j'enregistre, je vide la table, j'importe, et là c'est pareil qu'avant... dans ma base de donnée je vois les caractères : "ééé" mais dans ma page web je vois " http://img84.imageshack.us/img84/781/caractresbizarres.png ".

J'ai aussi essayé de changer l'Interclassement de la table dans ma base de donnée, qui est normalement en latin1_swedish_ci, et j'ai essayé de le mettre en utf8_swedish_ci... mais là non plus ça ne change rien !


Merci de votre aide ! Smiley cligne
Modifié par Crousti2 (10 Aug 2011 - 14:05)
La commande ci-dessus convertit les données (exceptés les champs de type BLOB) coté charset (la collation devrait suivre, sinon ALTER TABLE tablename CONVERT TO CHARACTER SET 'charset' COLLATE 'collation'; ), y compris le schéma.

Tu as vérifié qu'il a bien pris en compte la commande, en regardant les charsets de table et de champs ? Si tu vérifies sous phpMyAdmin, méfies-toi. Ce truc gère mal quand c'est hors de ISO-8859-1(5).

Vérifies également, coté connexion SQL si tu as bien explicitement forcé la connexion en UTF-8 : SET NAMES 'utf8'; comme première commande, juste derrière la connexion.
Oula je ne comprends pas tout, il va falloir m'expliquer Smiley confus


Tu as vérifié qu'il a bien pris en compte la commande, en regardant les charsets de table 
et de champs ? Si tu vérifies sous phpMyAdmin, méfies-toi. Ce truc gère mal quand c'est hors
 de ISO-8859-1(5).


Je vérifie ça comment ? et où ? Smiley confus

Vérifies également, coté connexion SQL si tu as bien explicitement forcé la connexion en 
UTF-8 : SET NAMES 'utf8'; comme première commande, juste derrière la connexion.


Même question pour cela ! Smiley confus
Modifié par Crousti2 (10 Aug 2011 - 15:26)
Pour vérifier les charsets, il te suffit de visualiser le schéma de ta table.
En ligne de commande,
DESCRIBE table;
est suffisant.

PhpMyAdmin est une interface fortement bugguée qui a souffert de lenteur de fixs. Petit exemple, il m'est souvent arrivé d'avoir une page (dans PMA) affichée comme UTF-8 (navigo), mais dont la frame centrale était en ISO-8859-1.

Le meilleur test, donc, est de démarrer une console, d'ouvrir une session mysql
mysql -u username -p

Puis de tester:
SET NAMES 'utf8';
SELECT * FROM `table` ORDER BY `champ significatif` LIMIT 10;


La commande SET NAMES 'utf8'; est une requête comme une autre.
Si tu as une classe unifiée SQL surchargeant PDO, par exemple, tu peux placer cette requête dans le constructeur. Si tu utilises une fonction pour faire ton mysql_connect, il te suffit de mettre dans cette même fonction un mysql_query("SET NAMES 'utf8'");

Smiley smile
Je te remercie de ton aide, mais là j'ai vraiment du mal Smiley confused


Alors j'ai fais DESCRIBE table; , il m'affiche bien des infos à propos de la table mais que dois-je regarde, faire ?

Puis comme tout à l'heure je ne comprends ce qu'est ce SET NAMES 'utf8'; , ce qu'il faut en faire, et pourquoi... Je suis désolé Smiley rolleyes
Alors j'ai ajouté $bdd->query("SET NAMES 'utf8'"); à chaque fois que je me connecte à la BDD, et ça fonctionne... mais est-ce normal de toujours rajouter cela pour que ce soit dans les bons caractères ?
DESCRIBE va te sortir la liste des champs, avec le charset des champs de type str (CHAR, VARCHAR, TEXT...). Il faut que tu vérifies que ces champs soient bien ainsi marqués utf8.
Mea culpa en passant, DESCRIBE n'est pas assez complet.
SHOW FULL COLUMNS FROM `table`; affiche bien la collation. Ex:
mysql> SHOW FULL COLUMNS FROM users;
+---------------+--------------+-----------------+------+-----+---------+-------
---------+---------------------------------+---------+
| Field         | Type         | Collation       | Null | Key | Default | Extra
         | Privileges                      | Comment |
+---------------+--------------+-----------------+------+-----+---------+-------
---------+---------------------------------+---------+
| numero        | int(11)      | NULL            | NO   | PRI | NULL    | auto_i
ncrement | select,insert,update,references |         |
| mail          | varchar(100) | utf8_general_ci | NO   | UNI | NULL    |
         | select,insert,update,references |         |
| pwd           | varchar(40)  | utf8_general_ci | NO   |     | NULL    |
         | select,insert,update,references |         |
| dateSubscribe | datetime     | NULL            | NO   |     | NULL    |
         | select,insert,update,references |         |
| dateAction    | datetime     | NULL            | YES  |     | NULL    |
         | select,insert,update,references |         |
+---------------+--------------+-----------------+------+-----+---------+-------
---------+---------------------------------+---------+
5 rows in set (0.00 sec)


Quant au SET NAMES, il sert à préciser le jeu de caractères utilisé lors de la connexion SQL. Il faut retenir que l'encodage peut être précisé à plusieurs niveaux:
- dans la DB, niveau des champs (serveur: définition SQL)
- dans la connexion SQL (serveur: SET NAMES)
- dans le type de retour (serveur: fichier encodé utf8, en-tête utf8 précisé)
- dans le HTML résultat (client: balise meta dans le HTML)
- dans le browser lui-même (client: action de l'user pour changer l'encodage, dans les options)

On n'a pas de contrôle sur ce dernier point, mais les autres points doivent être harmonisés. A la fois la définition de la DB, le type de retour, et le HTML résultat. Mais sait-on jamais, ton souci peut venir de là, car l'encodage utilisé lors de la connexion est défini en config.
Effectivement les collations sont en latin1, sauf là où je les ai modifié avec un bout de code que j'ai trouvé... mais maintenant que ça fonctionne avec SET NAMES, est-ce que ça vaut la peine de modifier tous les interclassement de chaque table et colonne ?


Merci à toi !
Modifié par Crousti2 (10 Aug 2011 - 16:10)
Oui, car à long terme, beaucoup de choses peuvent se passer:
- migration de code
- export DB
- changement de soft (passer d'Apache à IIS par exemple)
J'en passe et des meilleures.

L'harmonisation est réellement la seule solution durable.

Je t'ai indiqué les deux commandes pour convertir automatiquement les datas, dans mon premier post. Tu peux créer un simple script qui va sélectionner toutes les tables de ta DB
SHOW TABLES;
puis tous les champs de chaque table
SHOW COLUMNS FROM `table`; -- ou DESCRIBE `table`
pour effectuer un ALTER sur chacun. Quelques minutes de code pour avoir une DB clean, ça vaut le coup.

Attention, rappel, cette commande ne convertira rien coté BLOB.
Ok super merci à toi je vais essayer de faire ça pour toutes mes tables !


Du coups ça donne : ALTER TABLE {SHOW TABLES} CONVERT TO CHARACTER SET utf8;
?????
Modifié par Crousti2 (10 Aug 2011 - 16:18)
Non, non. Exemple à l'arrache et pas beau mais fonctionnel:


// $sql est une instance de connexion
$list = $sql->query("SHOW TABLES")->fetchAll();
foreach($list as $line) {
  $sql->query("ALTER TABLE `".$line['Table']."` CONVERT TO CHARACTER SET utf8");
}


Tu vois le principe ?
Modifié par Lpu8er (10 Aug 2011 - 16:26)
J'ai pas vraiment su appliquer le code, du coups j'ai fais table par table Smiley sweatdrop

Merci à toi en tout cas ! Smiley smile
Modifié par Crousti2 (10 Aug 2011 - 16:38)
Crousti2 a écrit :
Effectivement les collations sont en latin1, sauf là où je les ai modifié avec un bout de code que j'ai trouvé... mais maintenant que ça fonctionne avec SET NAMES, est-ce que ça vaut la peine de modifier tous les interclassement de chaque table et colonne ?


Merci à toi !
Pardon mais j'écris depuis un smartphone, j'ai pas vu mais ce serait bien de mettre [résolu] alors. Smiley bawling
Modifié par jmlapam (22 Aug 2011 - 19:41)
Bonjour,
Je regrettes de lire si tard ce sujet assez long, il faut remettre les choses en place
http://dev.mysql.com/doc/refman/5.0/fr/charset-general.html
vous expliquera que la collation ne sert qu'a l'interclassement , je veux dire ORDER BY !

Mais en aucun cas l'encodage donc l'affichage des caractéres dans une page HTML

Alors simplement qui sont les acteurs ?
SQL par rapport a PHP (dans les deux sens) a un interpréte qui est MySql !
PHP par rapport au visiteur (dans les deux sens) a un interpréte qui est le navigateur.

Il vous faut donc dire a vos interprétes dans quelle langue (encodage) parle l'un et l'autre.
Donc si je dis a MySql que je lui envoies du "latin 1" mais que SQL est en UTF8 alors tout va bien ça dialoguera IMPEC !!

j'espéres avoir été clair Smiley rolleyes

Mais attention aux piéges genre en AJAX ma page va appeler un php qui va répondre par un echo , cette page devra avoir un 'Content-type: text/html; charset=UTF-8'); par exemple si la page AJAX est en UTF8 si non ce php pourrait renvoyer du charset=iso-8859-1
Le même probléme existe pour les POST GET etc...
Modifié par Christele (03 Oct 2011 - 09:06)