Alors, nous avançons...
Requetes avec les convert, j'avais déjà essayé et que ce soit avec un convert utf8 ou latin1, rien ne change...
Par contre, j'ai fait les tests suivants:
- Création de matable2, structure identique à matable (colonne en utf8)
- Création de matable3, avec colonne en latin1
Requêtes exécutées depuis l'application php et non pas pma
SELECT * FROM matable WHERE id=460;
Id d'un libellé commençant par un é majuscule
1 2 3 4 5 6
|
1/ INSERT INTO matable2 (libelle) VALUES ('{{utf8_encode($row["libelle"])}}')
2/ INSERT INTO matable2 (libelle) VALUES ('{{utf8_decode($row["libelle"])}}')
3/ INSERT INTO matable3 (libelle) VALUES ('{{utf8_encode($row["libelle"])}}')
4/ INSERT INTO matable3 (libelle) VALUES ('{{utf8_decode($row["libelle"])}}') |
Alors déjà, première différence visible, lorsque j'affiche dans pma, que ce soit dans matable2 ou matable3, la seconde insertion (issue de l'utf8_decode) s'affiche correctement
Dans les deux tables, je fais la requete suivante:
SELECT LEFT(`libelle`,1),`libelle` FROM matable(2 ou 3) WHERE `libelle` LIKE 'a%' ORDER BY `libelle`;
Pour matable2 (en utf8) => il ressort la ligne doublement encodée en utf8 (insert 1/), donc fail
Pour matable2 (en utf8) => il ne ressort pas l'insertion 2/ RÉSULTAT RECHERCHÉ
Pour matable3 (en latin) => il ne ressort aucune ligne
Dans les deux tables, je fais la requete suivante:
SELECT LEFT(`libelle`,1),`libelle` FROM matable(2 ou 3) WHERE `libelle` LIKE 'e%' ORDER BY `libelle`;
Pour matable2 (en utf8) => il ressort la ligne décodée en utf8 (insert 2/), RÉSULTAT RECHERCHÉ
Pour matable3 (en latin) => il ne ressort aucune ligne
CONCLUSIONS
Pour que ça fonctionne comme prévu, il semble falloir que:
- La table soit en UTF8
- Les données soient décodée de l'UTF8
Est ce que les données auraient été double encodées à un moment ? Je vais essayer de les décoder et réinsérer (via php) et voir comment l'application se comporte...
Qu'en pensez vous ?
Partager