addslashes, mysql_real_escape_string, htmlentities ?

Je n'utilise pas :
* addslashes : certains caractères pouvant être dangereux ne sont pas échappés avec cette fonction.
* htmlentities : la pire des fonctions !! Elle ne sert strictement à rien mise à part pourrir les données de la base.

Donc, résultat, mysql_real_escape_string suffit amplement.

 

A l'enregistrement en DB, comme Blount : mysql_real_escape_string()
A l'affichage en value="" => htmlentities()

 

Attention, je n'ai jamais dit qu'il ne fallait pas utiliser "htmlentities", la question du sondage concerne l'insertion dans la base de données, et non pas l'affichage des données.

En effet, il faut toujours protéger les chaînes de caractères lors de l'affichage. Pour cela, j'utilise la fonction "htmlspecialchars".

Mais lors de l'insertion en base de données, aucun traitement de ce genre ne doit être fait.

 

d'un coté optimisation, mieux vaut faire le htmlentities (ou special char) une fois a l'insertion que des milliers de fois (voir des millions) à l'affichage pendant des jours, des mois, des années...

Aprés chacun sa philosophie ...

 

Sauf que là, ce n'est plus le même sujet.
Ce dont tu parles, c'est un système de cache.

Une base de données n'est pas une page HTML.
À tout moment d'un projet, il peut peut-être nécessaire de créer une application exploitant la base de données sans même afficher de l'HTML. À ce moment là, tu te retrouveras à traiter des données erronées.

Et j'ai un gros doute sur les impacts sur la performance de l'utilisation de la fonction à chaque affichage.

 

oui, enfin, là sa question est en rapport avec php, donc j'imagine que c'est pour un site, donc du html.

 

Si c'est pour une application HTML ou pas, enregistrer les entités en HTML en BDD n'est pas une bonne technique.
C'est à l'affichage qu'il faut faire le htmlentities/htmlspecialchars.

 

Tu sais qu'il n'y a pas que PHP dans la vie. Il ne parle pas d'une application tournant entièrement avec PHP. Et si même était le cas, il faut toujours voir à long terme.

Java, Python, Perl, C, C++, tout autant de langage utilisable pour concevoir des applications web.
Et tout autant de langage pouvant utiliser simultanément la base de données, peu importe ce qu'il est fait des données.

Après, vous faites ce que vous voulez, mais bon, j'espère ne jamais à devoir repasser derrière vous …

 

Bonjour,
Je suis désolé de déterrer un vieux sujet comme celui-ci mais je ne trouve pas de réponse satisfaisante.

Mon problème est lié aux guillemets et à mysql.
J'utilise

Code:

mysql_real_escape_string

pour faire mes inserts dans ma DB. Et lorsque j'insère du texte avec des " il me stock des "
Déjà est-ce normal ?

C'est à l'affichage que j'ai ensuite des soucis. Pour éviter les failles XSS, j'utilise htmlentities.
Sauf que htmlentities sur du texte contenant des " bah ça ne fonctionne pas très bien

Pour résoudre ce problème je peux faire ça :

Code:

htmlentities(html_entity_decode("mon texte avec des ""))

Mais c'est crade non ? Ce sont deux fonctions inverses.

Est-ce que quelqu'un peut me dire où se situe mon problème ?
Merci.

 

c'est avec addslashes que tu règles le problème des ' pour mysql, pas une fonction qui a un autre usage.

 

Non pas avec addslashes() mais mysql_real_escape_string() si tu codes tjs comme fin 1990 c-a-d sans abstraction de la DB (PDO).
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

 

oups, j'ai lu trop vite :
"mysql_real_escape_string() appelle la fonction mysql_escape_string() de la bibliothèque MySQL qui ajoute un anti-slash aux caractères suivants : NULL, \x00, \n, \r, \, ', " et \x1a. "

donc "j'insère du texte avec des " il me stock des " " est faux, s'il y a des """, c'est que ce n'est pas mysql_real_escape_string qui a été utilisé.

 

Il ne faut pas utiliser htmlentities pour l'affichage mais htmlspecialchars.
Il faut revoir ta façon d'insérer en base de données. À mon avis, il n'y a pas que mysql_real_escape_string d'utilisé, car ce dernier n'applique pas de conversion de chaîne (ex: ' en &quot mais de la protection de chaîne.