Version imprimable
Bonjour,
Lorsque j'ajoute une chaine dans une base de données protégé par mysql_real_escape_string je me retrouve en base de données avec des / devant les guillemets et simple quote tels que par exemple : l'avenir devient l\'avenir
Est-ce normal ? Et comment fait-on pour afficher par la suite les données correctement. Soit les / ne doivent pas être inséré dans la base de données soit oui mais dans ce cas c'est assez étrange et il faut les enlever à chaque affichage mais de quel manière ?
Slt ,
oui c'est tout à fait normal , celà permet d'échapper les caractères spéciaux afin d'éviter les injections sql .
Ensuite pour l'affichage , il te faudra passer tes données via la fonction :
stripslashes()
http://fr2.php.net/manual/fr/function.stripslashes.php
cdt,
Ch.
On aurait pas besoin d'appeler stripslashes à l'affichage si l'échappement était correctement réalisé dès le départ.
Vos données ne seraient pas, initialement, des données extérieures (méthode POST, GET, ...) ? Si c'est le cas, vérifier que magic_quotes_gpc n'est pas actif sur votre serveur (dans un phpinfo par exemple) parce que ça va faire un peu double emploi avec mysql_real_escape_string.
Les données sont passées en POST et stockées dans la base de données, je fais désormais uniquement un mysql_escape_string de la zone passé en POST directement en base de données mais celà ajoute un / avant les caractères spéciaux, çà fait bizarre dans la base de données. Est ce vraiment normal d'avoir les données avec des / dans la base de données avant des caractères comme le ' ??? (ex : l'avenir devient l/'avenir)
magic_quotes_gpc est à ON sur notre serveur selon le phpinfo
L'idéal serait donc de désactiver magic_quotes_gpc (d'autant plus qu'à terme cette fonctionnalité n'existera plus).
Parce que, dans le cas des données POST, magic_quotes_gpc réalise un premier échappement et vous en effectuez ensuite un second avec mysql_real_escape_string. D'où les backslahs superflus/indésirables.
Merci pour cette info , :ccool:Citation:
Envoyé par julp
J'utilisais toujours stripslashes à la sortie de données sans réellement faire attention de la provenance de ces slashes !
Ch.