Forum d'entraide PHPFrance

Bonchour !

comme le titre l'indique, je fais une recherche dans la base de données mysql.

J'ai un champs qui contient des balises, puisque ce sont des articles insérés via fckEditor (editeur wysiwig). Les informations envoyées sont traitées avec htmlspecialchars avant l'entrée dans ce champs.

Mon problème est simple : j'aimerais pouvoir effectuer une recherche uniquement sur le texte, pas sur les balises, dans mysql.

Possible ?

Merci à vous.

Ça doit pouvoir se faire avec REGEXP en excluant les balises HTML

voui je n'en doute pas.

Je suis un peu allergique aux expressions régulières ...

j'fais comment

La question est :
- quel est l'intérêt d'avoir laisser entrer dans la base du texte contenant des balises si c'est pour traiter les chevrons avec htmlspecialchars ?
ON se trouve dès lors avec un affichage de texte rempli de balises html non interprètées.
En gros un truc sûrement dégueu à l'affichage.

Bref expliques ce que tu cherches vraiment à faire.

Bonjour,

non, je ne traite pas le contenu avec les htmlspecialchars. Je le traite en entrée dans la base avec htmlentities, puis en sortie avec htmlentitiedecode.

Dans la base même, étant donné que j'utilise un éditeur wysiwig pour les entrées d'articles, je me retrouve avec du code html. Des balises insérées par l'éditeur, traitées ensuite par le navigateur.

Je voulais juste une expression mysql qui éliminait les balises ainsi que leur contenu, puis qui recherchait uniquement sur le contenu.

Merci de votre aide.

Bonjour,

non, je ne traite pas le contenu avec les htmlspecialchars. Je le traite en entrée dans la base avec htmlentities, puis en sortie avec htmlentitiedecode.

Bah oui c'est bien ce que je pensais, à la différence près que htmlentities() est pire que htmlspecialchars() car utiliser dans 99,99% des cas à mauvais escient.

De plus, dis-moi pourquoi faire un htmlentities() à l'entrée de la table pour faire un htmlentitiesdecode() à la sortie ?

Ne crois-tu pas que c'est complètement stupide ?

Sur une problématique similaire j'avais opter pour un champs supplémentaire dans la table dans le quel je stockais le texte seul à l'aide d'un petit passage par strip_tags().

vois si ça peu t'aider

Bah oui c'est bien ce que je pensais, à la différence près que htmlentities() est pire que htmlspecialchars() car utiliser dans 99,99% des cas à mauvais escient.

De plus, dis-moi pourquoi faire un htmlentities() à l'entrée de la table pour faire un htmlentitiesdecode() à la sortie ?

Ne crois-tu pas que c'est complètement stupide ?

Hum,

Ce n'est pas moi qui génère les entrées en base de données. Les Htmlspecialchars, que j'utilise en général, ne traitaient pas certaines caractères à l'exécution de la requête. Notamment les quotes, qui me posaient quelques problèmes d'erreur de requête. Donc j'ai utilisé l'option ENT_QUOTES.

M'enfin, ça ne change rien au problème : j'ai besoin d'éliminer mes balises html lors de la recherche, dans mysql. Elles y sont, parce qu'un éditeur les y a mises, et ce même éditeur est suffisamment performant, modulable et fonctionnel pour que je n'ai pas envie de le changer.

Merci de ton aide.

ps : je jette un oeil aux strip_tags()

À ta place je reverrais la façon dont sont stockées les données :

1. Effectivement, il ne faut pas gérer les entités avant de stocker en bdd. Les données en BDD doivent être brutes, et c'est PHP qui doit (ou non) transformer le texte à volonté avant affichage. Les quotes ne doivent pas te poser de problème, ou alors c'est que tu n'as pas construit ta requête correctement et que tu as oublié d'utiliser mysql_real_escape_string() par exemple.
Je te défie, quelque soit le contenu de $variable, de trouver une erreur de syntaxe dans la requête suivante

$valeur_champ = mysql_real_escape_string($variable);
$query = "SELECT * FROM ma_table WHERE mon_champ = \"$valeur_champ\"";

Le texte stockée ne doit jamais être un problème n'oublie pas qu'il existe le champ blob capable de stocker du binaire. Donc Mysql n'a que faire que ton texte contienne des guillemets, des coeurs ou des accents, il le traite de façon brute. La seule source d'erreur causée par des quotes, ce sont des erreurs de syntaxe, et elles sont évitées par l'échappement de caractères.

2. Tu veux stocker du texte enrichi, et souhaite effectuer une recherche sur le texte hors enrichissement. C'est un cas typique de besoin d'indexation manuelle ! Si j'étais toi je créerais donc une table dédiée à la recherche contenant deux champs :
- une clé primaire correspondant à l'identifiant de la ligne indéxée
- un champ texte indexé pour la recherche rapide, contenant dans ton cas simplement le résultat de strip_tags sur ton texte enrichi.
En partant de ce principe tu peux même faire un traitement plus complet sur le texte indexé (virer les mots communs comme "le", "la", "les", gérer les pluriels, etc...).
Ceci t'imposera de faire deux requêtes lors des modifications (insertions et update), mais accélèrera et simplifiera ta recherche de façon très importante.

D'accord, mais il faut tout de même que je traite les caractères spéciaux avant l'entrée en base de données.

J'utilise stripslashes ?

Excellente idée, de dupliquer le champs de contenu. Je n'y avais pas songé. Je vais faire ça de suite, la recherche sera effectivement bien meilleure.

Merci de votre aide.

Mathieu.

Sur une problématique similaire j'avais opter pour un champs supplémentaire dans la table dans le quel je stockais le texte seul à l'aide d'un petit passage par strip_tags().

Attention à strip_tags qui présente "une forme de bug".
Moi j'appelle ça "une forme de bug" juste pour marquer le coup auprès des débutants, car en fait, c'est le comportement tout à fait normal de la fonction.

strip_tags() agit sur le chevron ouvrant.
Exemple :

<?php
$chaine='<strong>Texte</strong>';
echo $chaine; 
// affichera => Texte en gras

echo strip_tags($chaine);
// affichera => Texte de façon normale

// la forme de bug...
$chaine='En math, si 10<20 on sait que 12>10';
echo strip_tags($chaine);
// affichera => En math, si 10
?>

D'accord, mais il faut tout de même que je traite les caractères spéciaux avant l'entrée en base de données.

J'utilise stripslashes ?

Didjou ! J'ai pointé mysql_real_escape_string() c'est pas pour rien

sourire.

Voui, j'ai remarqué, après ...

Merci.