Selections et Tris UTF8 caractère accentués - MySql 4.1.14

Bonjour,

Ma base de donnée est en Utf-8 - collation utf8_general_ci.
caractere_set_connection et caractere_set_result en utf8 également.

Lorsque je fais une recherche ou un tri sur un Nom ou prénom accentué, la collation ne marche pas.

- Pour la recherche de "Frederic", les "Frédéric" ne sont pas trouvés.
- Pour les tri, les "BÉNÉTEAU" se trouvent après les "BRUANT".

Je n'arrive pas à trouver sur internet de réponse à cette question. Les sujets traités, le sont généralement en "latin1", et là effectivement, ça marche. Mais l'orientation de l'affichage et la gestion des données s'orientant vers l'utf-8, je n'ai pas envie de faire marche arrière.

Si quelqu'un a une solution à me suggérer, il est le bien venu.

Laurent

Bonjour laurent972 et bienvenue,

Je me demande si la solution ne passerait pas par les expressions régulières.

je sais que çà n'est pas ce que tu cherche, mais à défaut permettrait de rendre un résultat cohérent.

Je vais suivre, j'ai aussi basculé mes développements en UTF-8 et j'ai un moteur à développer ce mois-ci.

Bon courage.

bonjour ernstein,

Merci beaucoup pour cette réponse et cet accueil.

Je suis prêt à utiliser n'importe quelle solution, aussi lourde soit-elle, en pariant sur le fait que les collations françaises marcheront bien un jour sur MySql en Utf8.

J'ai aussi essayé avec les REGEX, mais ça ne marche pas avec les Utf8 (en latin1 ça marche). En effet, les expressions régulières exprimées en utf8 à MySql, sont mal interprêtées dés qu'il s'agit de caractères sur 2 octets.

Alors j'ai essayé, de construire ma requête SQL en passant tout en 'latin1' .
J'en suis donc à l'étape suivante :
$val = utf8_decode($val) ;
et clause WHERE CONVERT(table_prenom USING latin1) REGEXP $val

Ca marche très bien pour un $val = 'no l' qui trouve un 'noel' ou un 'noil'.

Par contre, ça ne marche toujours pas pour un $val = 'no[eë]l' qui trouve un 'noel', mais pas un 'noël' !

Laurent.

Outch... c'est pas gnagé cette affaire...

Je suis dans un contexte différent (ASP) je ferais les tests de mon côté en fin de semaine. Désolé.... j'suis trop en retard, ici et la.

Bon courage... regarde aussi du côté du forum : MySQL FR

Pas gagné en effet, et pourtant si élémentaire.

Suivant ton conseil, j'ai mis le même post sur le forum de Mysql.

Laurent

Ma soluce n'en est p'tet pas une, mais puisque tu passes par php, pourquoi ne pas passer tes données par "htmlentities" ? tes é deviendront des

é

et ta recherche se fera sur ces critères là non ?

Euh, non, finalement en relisant ton pb, ça doit rien résoudre du tout... Désolé.
Modifié par chu (18 Oct 2005 - 16:43)

Ouf !

J'ai mis un petit peu de temps, après avoir été faire un petit tour du côté de PostgreSql, pour voir si les tris et sélections à la française était mieux gérés. Sauf, erreur de ma part, ce n'est pas mieux. Et finalement, je préfére MySql.

Donc, je suis revenu sur MySql v5, tant qu'à faire. Constatant, que les caractères multi-octet étaient sommes toutes bien reconnus : Noel trouve Noel, Noël trouve Noël, mais No[eë]l ne trouve pas Noël, j'ai testé l'expression regulière No(e|ë)l, qui sépare bien chaque groupe d'octets.... et ça marche ! Noel et Noël sont au RV.

Ceci, en attendant la collation qui correspond à notre langue, puisque dans la documentation, ils promettent le développement d'un grand nombre de nouvelles collations.

Laurent.

Salut,

A ma connaissance MySQL 4.1 connaît des bugs de collation et certains attendaient d'être résolu avec la v5.0.
Essaye donc MySQL 5