Tout d'abord :n'utilisez pas mysql_escape_string , il est obsolète (pour une raison) !
Si vous devez prendre en charge une application héritée qui se connecte à la base de données via mysql extension (qui a été obsolète
), utilisez mysql_real_escape_string
Au lieu. Sinon basculer immédiatement
vers mysqli , où les instructions préparées et les paramètres liés fournissent un mécanisme plus robuste pour échapper à l'entrée de l'utilisateur.
Cela dit, la réponse peut être trouvée en lisant la description de mysql_real_escape_string
et addslashes
:
Différence #1
addslashes ne sait rien des encodages de connexion MySql. Si vous lui passez une chaîne contenant des octets représentant un encodage autre que l'encodage utilisé par la connexion MySql, il échappera volontiers tous les octets ayant les valeurs des caractères ' , " , \ et \x00 . Cela peut ne pas être le même que tous les personnages ' , " , \ et \x00 si vous utilisez un encodage autre que les encodages 8 bits et UTF-8. Le résultat sera que la chaîne reçue par MySql sera corrompue.
Pour déclencher ce bogue, essayez d'utiliser iconv
pour convertir votre variable en UTF-16 puis l'échapper avec addslashes . Voyez ce que votre base de données reçoit.
C'est l'une des raisons pour lesquelles addslashes ne doit pas être utilisé pour s'échapper.
Différence #2
Contrairement à addslashes , mysql_real_escape_string échappe également les caractères \r , \n , et \x1a . Il semble que ces caractères doivent également être échappés lorsque vous parlez à MySql, sinon une requête mal formée peut en résulter
C'est l'autre raison pour laquelle addslashes ne doit pas être utilisé pour s'échapper.
