Discussion :

[ericd69]

et en faisant ça:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT LEFT(convert(libelle using utf8),1),libelle FROM matable
WHERE convert(libelle using utf8) LIKE  'a%'
ORDER BY libelle;

ou

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT LEFT(convert(libelle using latin1),1),libelle FROM matable
WHERE convert(libelle using latin1) LIKE  'a%'
ORDER BY libelle;

[Fred_34]

Je résume mon probleme qui n'est pas lié à phpmyadmin:

->J'ai une table contenant une colonne "libelle"
->Les données sont en utf8
->Je cherche à faire un index (au sens table des matières, non pas au sens bdd) des libellés
->Du coup, pour afficher la page des A (par exemple), je fais un select where left(libelle,1)='a'
-> problème, mysql (rien à voir avec mon appli ni même phpmyadmin, c'est interne à mysql) me ressort aussi les é majuscules lors de la requête précédente....

A priori, tes données sont en Latin1 dans une table en utf8.
Tu peux les reformater en utf8 (Alternative Method 2):
http://en.gentoo-wiki.com/wiki/Conve...UTF-8_in_MySQL
Mais si ton application fonctionne avec les données actuelle, que va t'il se passer avec du véritable utf8 ???

[tse_jc]

Bonjour,

Visiblement tu as enregistré dans ta base de données Evelyne avec e accent aïgu majuscule ce qui est une erreur et forcément dans ton cas, n'aide pas (tu l'aurais enregistré avec un E normal même en ISO il serait resté intact en UTF8, Latin1, etc...).
Ensuite ton application est-elle localisée? As-tu vraiment besoin d'être en UTF8 unicode_ci partout dans ta bd? Pour ce que tu souhaites faire pour ta colonne libellé et pour rendre ton index plus performant, une collation binaire (et donc sensible à la casse) n'aurait-elle pas été plus judicieuse?

Car tout faire dans un environnement utf8 de l'IHM au SGBDR c'est une démarche, qui même si elle s'explique et qu'elle a sa logique, n'en reste pas moins un choix qui se place d'un point de vue dev PHP et il me semble que sur la partie SGBDR, penser plus comme un admin SGBDR pourrait être beaucoup plus productif.

++

[waxman]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM matable WHERE id=460;

Id d'un libellé commençant par un é majuscule

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[waxman]

Bonjour,

Visiblement tu as enregistré dans ta base de données Evelyne avec e accent aïgu majuscule ce qui est une erreur et forcément dans ton cas, n'aide pas (tu l'aurais enregistré avec un E normal même en ISO il serait resté intact en UTF8, Latin1, etc...).

Le prénom s'écrit avec un é et non un e (majuscule ou non) et à mon sens, altérer les données pour satisfaire l'applicatif ou la bdd, ça c'est une vraie erreur.

Mais peut être n'ai je pas la bonne vision des choses. Peux tu m'expliquer pourquoi à ton avis c'est une erreur ?

[tse_jc]

A ce que tu viens de dire "que les données soient décodées de l'UTF8" prouve au moins une chose, c'est que ton environnement global Apache/PHP/SGBDR n'est pas configuré par défaut partout en UTF8, car sinon tu n'aurais pas besoin d'encoder/décoder explicitement tes chaînes de caractères.

++

[waxman]

A moins que, pour une raison encore inconnue mais je vais chercher, les données de cette table soient double encodée et que le fait de les décoder les mette simplement en utf8 comme elles devaient toujours l'être

[ericd69]

oui certainement

même un script sql d'export/import encodé en iso peut l'expliquer...

après tu as juste le bol que dans ton application un truc remette les choses d'aplomb...
d'où certainement pas d'erreur avec l'appli et elles apparaissent sous pma...

mais ça peut devenir un problème à long terme si tu as du vrai utf mixé avec de l'iso

après on est pas dans ton code

regarde les fichiers qui traitent des prénoms vu que tu sais que le problème est au moins la et vérifie toute ta table pour voir si le problème touche toute la colonne ou une partie...

après à voir les conversions à faire

[waxman]

Bon... Mes données ne sont pas double-encodées.
je les ai décodées, les requêtes fonctionnent comme attendu !

Seulement je suis obligé de mettre un utf8_encode au chargement dans l'application pour que la suite se passe correctement.

J'en reviens à l'idée du mauvais comportement de mysql....

[ericd69]

si y a un utf_encode... c'est qu'il y a un pb et que tu as bien de l'iso qui lui arrive

moi je travaille depuis plusieurs années qu'en utf-8 et j'en ai jamais eu besoin

tu es sur ton hébergement ou en local...

si j'ai bien compris tu as convertis un truc qui anciennement était en iso...

tu l'as fait comment cette transition?

est ce que tu as le moyen de tester ta table en local?

[waxman]

Oui, mes données sont désormais en iso pour que les requêtes fonctionnent correctement dans mysql
Du coup, l'application étant en utf8, je dois en effet faire un utf8_encode lors du chargement des données.

L'hébergement est chez OVH. Le projet étant en cours de dev, je travaille directement sur le serveur final.
J'ai eu trop de problème de par le passé avec des appli qui tournaient en local mais qui avaient des soucis en prod à cause de directives de configuration particulières chez l'hébergeur (directives parfois découvertes sur le tas car ils ne communiquent pas toujours dessus)

Encore merci pour l'aide apportée

[ericd69]

et de l'utf8_decode à l'insertion si tu as rechanger le charset de tes tables

oui... ovh a 2 ou 3 spécificités sur php surtout, j'ai des hébergements aussi chez eux... mais rien de transcendant...