problème lors d'une recherche en SQL et caractères spéciaux

WRInaute discret
Bonjour à tous !

Pour enregistrer mes champs dans ma BDD je les traite avec un htmlentities() de php.
Jusque là tout va bien.

Par contre lorsque je fais une recherche cela me pose problème :

par exemple je cherche les prénoms qui contiennent "ea", ma requête va me retourner tous les prénoms avec un "é" car il est écrit dans la bdd "é" donc contenant "ea"... Auriez vous une idée sur comment je pourrais traiter cela (une fonction sql ?) ??

Merci d'avance !

Frédéric
 
WRInaute occasionnel
Salut,

Non, il n'y a pas de fonction pour faire ça puise que mysql n'a pas de rapport direct avec html.

Pourquoi insérer les champs encodés ?
Une solution serait de décoder l'ensemble des champs dans la bdd. C'est une grosse base ?
 
WRInaute accro
fraid26 a dit:
Pour enregistrer mes champs dans ma BDD je les traite avec un htmlentities() de php.
Jusque là tout va bien.
Non, tu as tord.
Il ne faut pas enregistrer les entités HTML en BDD, il faut juste utiliser htmlentities à l'affichage.
Et ton problème ne serait pas là.
 
WRInaute discret
OK je vois mieux... je pensais que le htmlentities aider aussi à lutter contre les injections !
du coup je suppose qu'il faut plutôt que j'utilise mysql_real_escape_string ?

Je peux décoder l'ensemble de la base, elle est petite pour le moment. Par contre il me faut recoder l'ensemble de mes pages avec des htmlentities au moment de l'affichage pour le client... et ça, ça fait du boulot !

Merci de votre aide !
 
WRInaute occasionnel
Si tu utilises le même charset sur la bdd et sur le site (ce qui devrait être le cas), tu n'as pas besoin d'ajouter des htmlentities à tout va..

mysql_real_escape_string va ajouter des \ devant les ' et ", ça limite les injections mais ça ne fait pas tout ;)
 
WRInaute accro
J'utilise htmlentities à l'affichage pour que par exemple le & commercial se transforme bien en &, pas du tout pour éviter un problème de charset.
Pour éviter de devoir mettre toutes les vues à jour, rien n’empêche d'appliquer un htmlentities à tous les champs après la lecture SQL.
 
WRInaute discret
oui c'est ce que je vais faire, une boucle sur les colonnes, mais j'ai un grand nombre de pages et de requettes... c'est pour ça que c'est embêtant !
 
WRInaute occasionnel
Pour les caractères spéciaux, oui bien sûr, mais l'exemple de fraid26 porte sur les accents et à mon sens il n'y a pas d’intérêt a les encoder.
 
WRInaute discret
tu dois toujours echapper ce que tu affiches et provient d une base, puisque tu ne sais pas a l avance ce qu il s y touve. On peut bien y glisser du js par exemple, et la c est la catastrophe pour toi.
 
WRInaute occasionnel
Pour "y glisser" du js il faut que ce soit possible, plutôt que d'échapper tout ce qui sort de la bdd il ne serait pas plus judicieux de contrôler ce qui y rentre ?
 
WRInaute occasionnel
Pour afficher 3 < 5 il suffit lors de l'insertion dans la bdd d'inserer 3 &lt; 5 (avec htmlentities). Tous les navigateurs afficheront correctement le symbole.

Je ne comprend pas pourquoi tu dis "par exemple je peux pas car tu vas interdire le caractere '<' " ?
 
WRInaute discret
donc si tu utilises htmlentites a l insertion du champ du formulaire, tu te retrouves avec le probleme evoque dans le premier post: des accents transformes et une recherche qui marche plus.
 
WRInaute accro
poulpe a dit:
donc si tu utilises htmlentites a l insertion du champ du formulaire, tu te retrouves avec le probleme evoque dans le premier post: des accents transformes et une recherche qui marche plus.
pas obligé : il suffit de faire un str_replace(array(">","<"),array("&gt;","&lt;"),$content) et le tour est joué :wink:
 
WRInaute discret
Salut.
c est sur ca marche, mais si un jour par exemple tu veux exporter ta base dans un excel ou autre format qui ne comprend pas les entites html, ben tu vas devoir modifier encore une fois tout ton fichier. A mon sens il est plus simple de garder le contenu original, et le modifier a la volee.
 
Discussions similaires
Haut