| Auteur | |
|---|---|
| Crousti2 | |
| 197 Posts |
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 " ".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 ! Modifié par Crousti2 (10 Aug 2011 - 14:05) |
| Lpu8er | |
| 208 Posts |
http://tech-at-all.blogspot.com/2010/01/lutf-8-et-le-web.html Il te suffit de lancer la commande SQL de conversion en elle-même: ALTER TABLE {tablename} CONVERT TO CHARACTER SET utf8; |
| Crousti2 | |
| 197 Posts |
Eh bien je l'ai fais il a bien changé l'Interclassement en utf8_general_ci, mais mes caractères apparaissent toujours comme ça : "ééé" dans ma bdd et comme ça sur la page web : " " Modifié par Crousti2 (10 Aug 2011 - 14:42) |
| Lpu8er | |
| 208 Posts |
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. |
| Crousti2 | |
| 197 Posts |
Oula je ne comprends pas tout, il va falloir m'expliquer
Je vérifie ça comment ? et où ?
Même question pour cela ! Modifié par Crousti2 (10 Aug 2011 - 15:26) |
| Lpu8er | |
| 208 Posts |
Pour vérifier les charsets, il te suffit de visualiser le schéma de ta table. En ligne de commande,
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
Puis de tester:
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'"); |
| Crousti2 | |
| 197 Posts |
Je te remercie de ton aide, mais là j'ai vraiment du mal 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é |
| Crousti2 | |
| 197 Posts |
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 ? |
| Lpu8er | |
| 208 Posts |
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:
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. |
| Lpu8er | |
| 208 Posts |
(je viens de voir ta réponse) http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html pour plus d'infos. C'est plus de la configuration qu'autre chose, mais c'est souvent comme ça lors de telles migrations. |
| Crousti2 | |
| 197 Posts |
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) |
| Lpu8er | |
| 208 Posts |
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
puis tous les champs de chaque 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. |
| Crousti2 | |
| 197 Posts |
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) |
| Lpu8er | |
| 208 Posts |
Non, non. Exemple à l'arrache et pas beau mais fonctionnel:
Tu vois le principe ? Modifié par Lpu8er (10 Aug 2011 - 16:26) |
| Crousti2 | |
| 197 Posts |
J'ai pas vraiment su appliquer le code, du coups j'ai fais table par table Merci à toi en tout cas ! Modifié par Crousti2 (10 Aug 2011 - 16:38) |
| jmlapam | |
Bazinga ! 2148 Posts |
T'as tenté:
? Modifié par jmlapam (22 Aug 2011 - 02:08) Don't <li> ! |
| Lpu8er | |
| 208 Posts |
Crousti2 a écrit : |
| jmlapam | |
Bazinga ! 2148 Posts |
Pardon mais j'écris depuis un smartphone, j'ai pas vu mais ce serait bien de mettre [résolu] alors. Modifié par jmlapam (22 Aug 2011 - 19:41) Don't <li> ! |
| Christele | |
| 231 Posts |
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 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) |