La mauvaise réponse :
Pas de manière fiable. Vous faites référence à mysql_escape_string() , qui ne tient pas compte de l'encodage de la connexion (alors que mysql_real_escape_string() fait).
Alors peut-être qu'une chaîne soigneusement conçue, avec un point de code UTF8 incomplet soigneusement conçu devant, pourrait entraîner, par exemple, un guillemet échappé par mysql_escape_string() mais l'échappement lui-même étant ignoré par MySQL puisqu'il le "verra" comme un caractère UTF8.
Ex. :
0xC2' OR 1=1 ;--
serait échappé par mysql_escape_string() comme
0xC2\' OR 1=1 ;--
qui seraient assemblés pour
WHERE password='0xC2\' OR 1=1 ;--';
et vu par MySQL (si le codage de connexion approprié était en vigueur) comme, disons,
WHERE password='€' OR 1=1 ;[--';] <-- the bracketed part is considered a comment and ignored
ce qui serait une injection SQL classique.
Mais cela joue sur le fait que vous avez spécifié, peut-être par distraction, une fonction doublement obsolète . Si vous faisiez vraiment référence à mysql_real_escape_string() , cela ne fonctionnerait pas.
En outre, cela suppose que ni le serveur, ni la couche d'application (par exemple, PHP) n'utilisent de validation de jeu de caractères lors du remplissage de l'entrée. S'ils le faisaient, l'UTF8 invalide serait supprimé à l'arrivée et ne serait même jamais vu par mysql_escape_string , ce qui serait alors bien sûr suffisant.
La vraie réponse :
N'utilisez pas mysql_escape_string (ou mysql_whatever ) du tout. Ils sont obsolètes et votre code peut cesser de fonctionner. Utilisez plutôt les fonctions PDO.
