Encodage BDD MySQL : Latin -> UTF8
Résolu
Ha-Lu
Messages postés
66
Date d'inscription
Statut
Membre
Dernière intervention
-
rami -
rami -
A voir également:
- Encodage BDD MySQL : Latin -> UTF8
- Encodage ascii - Guide
- Mysql community server - Télécharger - Bases de données
- Encodage binaire - Guide
- Le flux d’octets était en erreur par rapport à l’encodage de caractères déclaré. la déclaration d’encodage des caractères était peut être incorrecte. ✓ - Forum Réseaux sociaux
- Mysql gratuit ou payant - Forum MySQL
7 réponses
Si tu vois des "©" à la place des "é", ça ne veut absolument pas dire que tes données sont en ISO8859-1.
Si tes tables sont bien déclarées en utf-8, ça veut dire au contraire que les données ont subi deux fois le transcodage ISO8859-1 -> utf-8.
Quant à l'image que tu donnes, le é est devenu "é", ça laisse penser que ton "é" a subi ce double et que de plus, tu l'affiches comme si c'était de l'ISO8859-1.
Tu n'utilises pas de utf8_encode dans ton script ?
Si tes tables sont bien déclarées en utf-8, ça veut dire au contraire que les données ont subi deux fois le transcodage ISO8859-1 -> utf-8.
Quant à l'image que tu donnes, le é est devenu "é", ça laisse penser que ton "é" a subi ce double et que de plus, tu l'affiches comme si c'était de l'ISO8859-1.
Tu n'utilises pas de utf8_encode dans ton script ?
Il y a un soucis dans la ligne <meta http-equiv="content-type" content="text/html; charset=utf-8" />
(ouverture et fermeture de guillemets foireuse)
Remplace là par <meta charset="utf-8" /> et place un <!doctype html> en haut de page
(ouverture et fermeture de guillemets foireuse)
Remplace là par <meta charset="utf-8" /> et place un <!doctype html> en haut de page
Bonjour
Exécute une requête mysql "SET NAMES 'utf8' " juste après ta connexion à ta base.
Et si tu n'est pas en HTML5, ta balise <meta http-equiv="content-type" content="text/html; charset=utf-8" /> était parfaitement correcte. Elle est juste inutile si tu envoies déjà ces informations par header.
Exécute une requête mysql "SET NAMES 'utf8' " juste après ta connexion à ta base.
Et si tu n'est pas en HTML5, ta balise <meta http-equiv="content-type" content="text/html; charset=utf-8" /> était parfaitement correcte. Elle est juste inutile si tu envoies déjà ces informations par header.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Question bête : tes données sont-elles correctes dans ta base ? Les accents ont-ils l'air corrects avec phpMyAdmin ?
Et quand tu dis que tu as "des soucis d'encodage", peux-tu dire très précisément ce qui ne va pas ?
Et quand tu dis que tu as "des soucis d'encodage", peux-tu dire très précisément ce qui ne va pas ?
Non, elles ne le sont pas... C'est le cas depuis que j'ai fais les modifications énoncées plus haut. Mes "é" sont des "©". Donc ma base est en UTF8 mais mes données entrées en ISO8859-1, c'est bien ça ?
Pour le reste de la base, c'est correct !
Je vais reprendre à partir d'un exemple :
On entre un ID anomalie, ainsi que sa description, qui est stocké dans la table correspondante. Via le site on peut ouvrir une fiche récapitulative, avec la description récupérée dans le base. Voici ce qui se passe :
- http://hpics.li/aea7020
Pour le site ça va, mais pour ce qui est de la récupération de données (même les anciennes, je conçois que les nouvelles sont mal stockées), c'est la cata...
Je vais essayer de prendre un peu de recul sur tout ça et de reproduire le problème sur moins de fichiers, peut-être que ce sera plus simple pour moi... Je vous tiens au courant si j'arrive à résoudre mon problème !
Pour le reste de la base, c'est correct !
Je vais reprendre à partir d'un exemple :
On entre un ID anomalie, ainsi que sa description, qui est stocké dans la table correspondante. Via le site on peut ouvrir une fiche récapitulative, avec la description récupérée dans le base. Voici ce qui se passe :
- http://hpics.li/aea7020
Pour le site ça va, mais pour ce qui est de la récupération de données (même les anciennes, je conçois que les nouvelles sont mal stockées), c'est la cata...
Je vais essayer de prendre un peu de recul sur tout ça et de reproduire le problème sur moins de fichiers, peut-être que ce sera plus simple pour moi... Je vous tiens au courant si j'arrive à résoudre mon problème !
J'ai vu que tu avais passé le sujet en résolu. Est-ce que tu peux expliquer comment tu as résolu le problème ? Ainsi, la personne qui aura le même problème et tombera sur ce topic aura une réponse...
Je n'ai pas vraiment résolu le problème en réalité, c'est juste que j'ai repris l'ancienne base qui était en ISO-8859-1 et repassé certains fichiers qui étaient en UTF-8 en ISO-8859-1 également. C'était plus rapide et simple, même si la norme est plus à l'UTF-8 maintenant (quoique pour un intranet français...)
Si je réussis à terminer tout ce que j'ai à faire je m'en occuperai et en rendrai compte ici ou sur un article éventuellement si ça marche. J'ai résumé les étapes principales théorique au dessus, que le père a complétées... Mais étant peu expérimenté je ne préfère pas donner ensuite de fausses manipulations si je n'ai pas eu de résultats.
Merci également pour ton aide et ton lien !
Si je réussis à terminer tout ce que j'ai à faire je m'en occuperai et en rendrai compte ici ou sur un article éventuellement si ça marche. J'ai résumé les étapes principales théorique au dessus, que le père a complétées... Mais étant peu expérimenté je ne préfère pas donner ensuite de fausses manipulations si je n'ai pas eu de résultats.
Merci également pour ton aide et ton lien !
Si, j'avais fais des utf8_encode, dans des fichiers encodés en UTF-8, du coup double encodage...
Finalement, j'ai décidé de revenir sur de l'ISO-8859-1, et ça fonctionne, j'ai réussi à éradiquer les soucis qu'il y avait au départ ! C'était tout simplement qu'une minorité de fichiers avaient été encodés en UTF-8 et pas les autres. C'est ultra-bête mais bon...
Mon CdC est assez chargé et je peux pas perdre trop de temps, mais j'aurais quand même voulu effectuer ce réencodage histoire de pouvoir m'en sortir si ça se reproduit. Je méditerai ça quand j'aurai un peu plus de temps !
Donc en bref, les étapes pour passer en UTF-8 :
-> Réencoder les fichiers avec l'éditeur par exemple ;
-> Penser à baliser les fichiers HTML/PHP ;
-> Exporter et réimporter la base en UTF-8, et réencoder les tables existantes ;
-> Faire attention au double encodage ;
C'est correct ? Je sais plus pourquoi j'ai mis ces utf8_encode, parce que c'est vraiment pas propre du tout et il me semble qu'on est pas censé les utiliser dans ce cas là en plus.
Merci beaucoup le père de ta sympathie et d'avoir accordé autant de temps à mon problème, c'est vraiment super de ta part ! :)
Dans ta liste des étapes, n'oublie pas d'ajouter le SET NAMES 'utf8' après la connexion.
Et il y a aussi l'utilisation des bibliothèques mb_ (multibyte) sans laquelle la manipulation des chaînes est hasardeuse.
Personnellement, je travaille toujours en utf-8. Je n'utilise le utf8_encode/_decode que pour importer / exporter des données vers des fichiers qui ne sont pas en utf-8, ce qui arrive très très rarement, pour ne pas dire jamais.