Bonjour à tous,

Voici mon problème :
Je dispose d'une base MySQL stockant diverses informations ainsi qu'un moteur de recherche codé en PHP. Le problème survient lorsque je recherche un mot accentué dans la base. Mettons que la base stocke le mot évènement. Si je passe en paramètre à mon moteur le mot évènement, aucun souci, par contre si je recherche le mot evenement, ca ne marche pas. J'utilise la clause like dans ma requete sql. J'ai cherché un peu sur le net et apparamment en utilisant like (au lieu de =) ca marche. Je ne sais pas vraiment d'ou cela peut venir. Si cela peut aider, le champ sur lequel je souhaite faire la recherche et de type text et l'interclassement est latin1_general_ci. Le problème survient aussi avec les majuscules, si je recherche Toto et que le mot stocké dans la base vaut toto, ca ne marche pas non plus...

Par avance merci pour votre aide

hello

ben rien de complique, il faut rechercher les variantes c tout, donc en clair sur ton exemple "evenement", tu dois d'abord prendre le mot que tu recherches et le mettre en minuscules avec strtolower, ensuite dans ta base, pour ta recherche, il faut rechercher :
- évenement
- évènement
- evenement

voila c tout, 1 like a chaque fois et c parti. faut juste que ta requete soit dynamique afin de gerer automatiquement les cas.

d'autre aprt, je te conseille de te mettre en utf-8 de partout

++

ah j'oubliais !!! pour que ca te trouve aussi les pluriels, ajoute des % avant et apres l'expressions recherchee, genre : LIKE '%evenement%' bla bla

voila !

bon courage

Merci grabber pour tes réponses. Le seul problème c'est que ta solution me parait un peu lourdre à mettre en place. Pour une seul lettre accentué ca peut aller, mais rien que la lettre e peut etre remplacée par 3 lettres : é, è, ê. Pour reprendre le mot évènement ou il y a 4 e. Si je veux tester toutes les possibilités, il y en a au total 4!*3 = 72 (si je ne me trompe pas dans mon calcul de proba ). Ca me parait un peu lourd, surtout que je viens de faire des tests sur une autre base (hébergé chez 1and1, la mienne étant hébergé par free), et mon algo de recherche fonctionne très bien avec la clause LIKE. J'utilise comme tu l'a dit une expression de type LIKE '%evenement%'.

trop pas utilises les regexp pour les remplacements de caractere c fait en 1 ligne

sinon moi jferais ca direct sur la requete en elle meme avec un truc genre : [eéèê]v[eéèê]nement ou encore : ?v?nement (tu vois le genre de truc...)
je sais pas quelle est la focntion qui fait ca mais ca doit se trouver la chaine de recherche telle qu'elle est, tu peux la creer avec les regexp, avec un truc genre : si je rencontre un accent, alors je remplace l'accent par [eéèê] (dans le cas d'un e accentué)
ca tu le fais en 1 ligne donc au final tu ne crees bien qu'une seule requete sur ta base. c'est sur que si tu genere 200 like ca va pas le faire, mais faut utiliser un truc un peu plus pousse jpense et la tu vas avoir des temps de reponse interessants, surtout si tu as colle des index sur tes tables aux bons endroits

a creuser donc, mais si tu pars la dedans, jveux bien la syntaxe, le coup des crochets il me semble avoir vu un truc dans le genre mais pas sur...

a voir aussi sur kel base tu es, apparemment du mysql, moi chui sur postgres, donc je vais meme pas avoir la meme syntaxe jpense, mais ptet qu'en sql de base tout simplement ca roule, a voir, mais jpense que la soluce elle est la

c'est bon j'ai trouve

alors tu fais comme je t'ai dit avec la regexp pour modifier un caractere accentue par son equivalent comme cela : [eéèêë]

donc en clair dans ton code, tu vas prendre la chaine qui est recherchee, puis tu fais un switch sur l'interception des caracteres accentues. dans chaque case de ton switch, tu gere tous les cas, donc soit la lettre est un E, soit A, soit I, soit O, soit U. de ca tu en ressort la chaine recherchee en version transformer que tu vas injecter directement dans ta requete.

(oups 1ere etape, mettre la chaine recherchee en minuscules absolument !!!)

ta requete va donc ressembler pour "évènement" à :
SELECT nom_du_champs FROM table_destination WHERE nom_du_champs LIKE '[éèeêë]v[éèeêë]nement';

et voila le travail !

qu'est ce que t'en dit ?

et si tu veux meme aller plus loin, tu peux au lieu d'utiliser les crochets avec toutes les valeurs possibles dedans, tu peux directement mettre un underscore a la place des lettres accentuees ca marche, par contre la c un caractere joker donc dans un mot court, ca va chier dans la colle, exemple :
"paté" : avec un underscore t'as la recherche suivante : "pat_" et pour ca, pati (du verbe patir) va ressortir alors qu'avec l'intervalle avec les crochets il ressortira pas

U understand dude

Après avoir fais un test rapide avec ta méthode, sans résultat (suis je mauvais?? ), je me suis penché sur un problème de collation. Voici un trés bon tuto que j'ai déniché et qui m'as permis de résoudre mon problème :
http://antoun.developpez.com/mysql5/jeux-collations/Jeux_et_Collations.pdf

Ca venait bien du jeux de caractère qui était "accent sensitive" (j'avais déjà tenté de le changer mais j'avais du choisir que des accent sensitive, la poisse ), je l'ai donc échangé contre un qui ne l'est pas. Tout marche niquel. Qu'est ce que t'en dis dude?

Merci pour ton aide en tout cas

hello

content que tu aies reussi pour le charset, je t'en avais parle des mon 1er post dans ce topic regardes bein.... UTF-8

sinon ben tant que ca marche c ok qu'st ce que tu n'es pas arrive a faire marcher avec ma methode ? c'est pourtant apparemment simple non ? les regexp ?

et merci a toi aussi, c'est sympa pour une fois de ne pas repondre "ajoutes un ; a la fin de la ligne"

si je peux juste te donner un conseil, c'est de ne bosser qu'en utf8, je bossais pour une chaine de tv europeenne en 7 langues... si tu vois de qui je parle, je leur ai fait leur intranet l'annee derniere... inutile de te dire que sans utf8 j'etais mort avant de commencer, avec, aucun probleme depuis je decolere pas ! tout a l'utf-8 !!!! bases, code, tout !!!

Là, grabber, excuse-moi mais je ne suis pas du tout d'accord avec ton histoire d'expressions régulières.

D'une part, les collations, c'est fait pour ça.

D'autre part, avec ta méthode, est-ce que ça veut dire que pour n'importe quelle lettre (on peut pouvoir chercher sans accents un mot stocké avec), il faut sortir cette artillerie ? Avec ça, si tu ajoutes une langue (mettons l'espagnol), il faut aller modifier ton code pour ajouter les nouveaux caractères (mettons un ñ). Et il faut penser à tout (comme le ç ou le ä).

Bon, enfin, mon but, c'est pas de casser du grabber, c'est juste que ça me choque ^^

ok je t'explique, pas de soucis

il n'y a aucune "artillerie", je te detaille la chose... :

- l'expression reguliere n'a qu'une seule vocation, celle de creer la requete, par exemple, si on reprend le mot "évènement", la regexp ne va servir en php qu'a generer une requete du type :
SELECT machin FROM truc WHERE bidule LIKE "[eéèêë]v[eéèêë]nement";

en clair ce n'est qu'un remplacement de caractere permettant de generer la bonne requete.

- en ce qui concerne collation ou pas collation, je n'utilise pas cette methode car d'une part je n'en ai pas l'habitude et que d'autre part je travaille sous postgres et non sous mysql5 (le tuto est pour mysql5 il me semble... a verif...). je ne sais pas si ce type d'operation existe sous postgres, probablement d'ailleurs, mais mon choix reste celui que j'ai enonce car ce choix permet de generer du sql pur et donc totalement independant du sgbd utilise
pour completer, j'utilise pear db, couche d'abstraction (bien connue), c'est pourquoi j'essaye au maximum de rester proche du sql pur et d'eviter les specificites de tel ou tel sgbd car malheureusement ils en ont tous

- dernier point sur ta remarque concernant les autres caracteres type "ñ". je comprends ton propos, cela dit... si tu ajoutes une langue, comme dans ton exemple l'espagnol, il te suffit de creer la ligne de regexp qui va bien pour le "n" comme tu l'as fait pour le "e", cela ne me semble pas tres complique, un copier coller en somme. d'autre part, il n'y a pas 36 lettres accentuees par langue donc finalement je pense que c'est assez restreint, sans oublier aussi les caracteres que l'on a pas en francais, genre comme les allemands avec le ß. au pire, on a 26 lettres, rajoutes en mettons 5 que l'on a pas en francais, ca te fait au pire 31 regexp a generer, ce qui n'est pas enorme pour un moteur de recherche.

enfin cela dit ce qui compte c'est le resultat !!! et s'il a trouve son bonheur c'est le but si j'ai 5 minutes, je regarderai plus en detail cette histoire de collation sous postgres, mais ca pourrait etre interessant (genre de truc qu'on fera jamais mais bon...) de bencher l'efficacite des 2 solutions, voir ce qui consomme le plus car la j'en ai aucune idee...

dernier point et j'insiste, meme si ce n'etait pas le sujet de ta reponse, mon conseil est de toujours utiliser l'utf-8 de partout. oui je radote !

et tkt pas ya pas de cassage, c'est interessant de pouvoir confronter 2 idees, tu sais moi je cherche aussi des trucs toute la journee pour le taf, alors meme si j'ai pas trop l'habitude d'utiliser le forum pour demander c'est pas pour autant que je sais tout faire, loin s'en faut moi je suis tres google car google apporte justement le choix de differentes solutions pour un meme probleme, de pouvoir confronter ces differentes solutions afin de tirer dans chacune d'elles le detail positif qui va permettre de pouvoir optimiser la version de ce que moi je veux faire, en ce moment par exemple je me documente sur les sessions securisees... vaste sujet... ben typiquement, plein de techniques differentes sont utilisees et comme d'habitude, aucune n'est vraiment la bonne, mais en faisant une mixture de tous les points positifs on arrive a des trucs top enfin pour notre utilisation perso d'ailleurs, un truc pour ceux que le php interesse, il y a une newsletter journaliere de phpclasses, je sais pas si vous connaissez... bref, c'est un site sur les classes en php ! forcement ! tous les jours ils envoient 2 classes sur des sujets divers et varies, c'est super interessant de voir les sujets traites, ya par exemple de la geoloc ip, des ptis trucs en ajax tout cons genre triage de colonne, plein de couches d'abstraction de base, des captchas, enfin plein de choses diverses du monde entier, les gars qui envoient les classes sont hyper dispo, y repondent aux mails, ils corrigent quand tu leur donne des bugs, ils font meme pour certains les ameliorations que tu leur suggere, si tant est que l'amelioration soit pertinente !!! enfin bref, je conseille vraiment cette newsletter qui pour moi est tous les jours instructive. bon ce qui est chiant c que quand c un portugais qui code et que le naze met tout en portugais meme les variables, tu panes rien au debut !!! y'a un temps d'adaptation !!!

enfin bref

Tu m'as donné une grande réponse, je vais essayer d'en être digne

• sur le côté Unicode, je suis complètement d'accord avec toi.
  
• les deux gros avantages que je vois à la collation, ce sont
  
  
  • tout est prêt, il n'y a presque rien à faire dans le code (voir inconvénients des Regex) et dans la base de données (une fois et c'est fini), et en plus, ça se base sur un standard. C'est transparent et prévisible.
    
  • l'optimisation n'est pas notre problème mais celui du SGBD. S'il y a une façon d'optimiser ça, ils (MySQL, Postgre - qui supporte aussi la collation, ...) l'ont sûrement utilisée, et on peut imaginer qu'il le font bien et que ça peut évoluer. Bref, c'est entre de meilleures mains que les nôtres.
  
  
• les inconvénients de l'expression régulière
  • le code: c'est vrai, on parle de quelque chose de simple. Sauf que... Il reste que chaque fois que tu veux modifier quelque chose, il faut que tu modifies - donc patche - ton code. C'est une perte de temps et un risque d'erreur à mon avis.
    
  • la performance: une regex, ce n'est pas un simple strcmp. Oui, ça va être léger pour le code PHP, le moteur PHP n'a que quelques substitutions et concaténations à faire. Mais le SGBD, lui, il faut qu'il sorte le moteur Regex, et je ne sais pas ce que ça vaut à côté d'un comparateur de texte Unicode basé sur les classes. Effectivement, il faut laisser parler la poudre et les benchs.
  
  

Je ne sais pas si j'ai été convaincant, mais c'était de bonne fois .

Et je ne m'y risquerai pas dans ton topic "sécurité": je laisse ça aux vrais !

hello

merci pour te reponse complete. je susi assez d'accord avec ta vision, pour le bench je crois qu'il faudra repasser car moi non plus je n'ai pas trop le temps. je vais essayer de creuser cette question concernant la collation sous postgres, ca m'interesse
dernier point concernant les regexp, j'ai peut etre aussi la sale habitude d'utiliser les regexp comme le messie, deformation d'independant qui fait que souvent tu reutilises pas mal ton code / tes techniques c'est vrai que parfois ca n'aide pas a l'ouverture !

merci en tout cas d'avoir pris le temps de me repondre

oliv

Le 15 avril 2007 - 09 h 31, grabber a écrit : dernier point concernant les regexp, j'ai peut etre aussi la sale habitude d'utiliser les regexp comme le messie

moi aussi
à ce propos, si tu ne la connais pas, je te suggère la Bible: "Maîtrise des Expressions Régulières" de Jeffrey Friedl. Je vois que l'optimisation t'intéresse aussi, et il y a de quoi se faire plaisir dans ce bouquin !

o'reilly
jpasserai jeter un oeil a la fnac merci du tuyau