Discussion :

[cydream]

Bonjour

J'ai developpé un moteur de recherche fulltext en MySQL sur plusieurs champs. Le problème, c'est que certains de ces champs sont issues de textarea générées par tinymce (un javascript wysiwig qui sauvegarde donc du HTML).

Ceci me pose des problemes notamment dans la recherche des mots avec des accents. Comment pourrais solutionner ce probleme ?

Par ailleurs, je souhaiterai que lorsqu'une personne fasse une recherche avec plusieurs mots, il ne fasse pas une recherche en OU mais une recherche en ET

Merci d'avance pour vos reponses sur ces deux questions

CyDr€@m

D'une maniere générale, je suis preneur de tout article traitant de la bonne facon de faire un moteur de recherche en MySQL.

[Léortien]

pour les accents :
cela peut dépendre de qui remplit les champs dans tinymce.

Disons qu'avec du html_entities_decode() tu décodes en général ce que te renvoie tinymce (si c'est du genre fckeditor? avec fck ça suffit)
si tu regardes dans la doc, tu devrais avoir l'encodage qui est précisé
(si tu as le temps tu peux meme désaxctiver le codage dans tinymce, perso pas eu le courage avec fck dont j'ai décodé comme un bourrin.. j'ai une excuse c'est une toute petite appli)

et là tu obtients du code html propre.
mais (et oui il y a un mais), intégrer du code html bourrinement dans une base mysql. ça marche pas bien
et pour ça y'a mysql_real_escape_string()
et avec ça quand tu regardes le contenu de ton champ tu as du pur html sans encodage
c'est une idée pour avoir tous tes champs en clair et te simplifier la vie...


par contre il y a un hic (désolé)
c'est que du code html rentré en clair dans l'éditeur deviendra du html à l'affichage (ex tu rentres <i>toto</i> et tu obtiens toto, avant tu rentres <i>toto</i> et tu obtient <i>toto</i> à l'affichage (en raison de l'encodage des caractère spéciaux...)
donc ça gène si tu veux écrire du code, si quelqu'un rentre des choses génantes telles que : <!-- , ou encore <b (avec les navigateurs qui interprètent et complètent ça fait comme si une balise <b> était ouverte et pas fermé...) etc...

après tu peux encoder juste les caractère génants (< en &lt; surtout, je ne sais pas si y'en a d'autre) et pas les accents, ainsi les recherche de texte pur seront sans prise de texte.



bon j'avoue je suis sur ce genre de reflexion en ce moment, je ne sais pas si c'est le plus propre mais voilà ça te donne une piste



et pour le fulltext, j'ai pas de réponses, je suis arrivé ici car je me pose les mêmes questions que toi

[SQLpro]

Normalement tout SGBDR devrait respecter le principe des collations qui permet de résoudre votre problème. Cepandant je ne sais si MySQL qui est un SGBD assez limité permet d'utiliser les collations.

Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...er/collations/

A +

[Léortien]

[hors sujet]

Normalement tout SGBDR devrait respecter le principe des collations qui permet de résoudre votre problème. Cepandant je ne sais si MySQL qui est un SGBD assez limité permet d'utiliser les collations.

2 secondes de google me permettent de dire oui. (c'est pas très pro de dénigrer sans vérifier) Mysql n'est donc pas si limité que ça
(et c'est aussi résitant quand je vois ce que d'autres équipes en font, mais j'avoue que cela a des limites pour nos très très grosses bases c'est oracle.)
[/hors sujet]

Et donc oui les collations, je n'avais pas vu le problème des accents de ce point là.
Je pensais plus au problème des accents au format html, avec &eacute; pour é en raison de l'origine des données.


et pour la recherche j'ai trouvé là (c'était si évidement de chercher ici lol) :
http://omiossec.developpez.com/mysql/fulltext/etudes/
(et sinon directement sur le site mysql encore plus détaillé sur les options pour la recherche)

pour le mode ET il faut faire une recherche en mode booleen
(tu peux aussi faire du NON, du ET et du NON, de la recherche d'une chaine de caractère, priviliégier un mot par rapport à un autre, etc...)