Prima di tutto:non usare mysql_escape_string , è obsoleto (per un motivo)!
Se devi supportare un'applicazione legacy che si connette al database tramite mysql estensione (che è stata ritirata
), usa mysql_real_escape_string
invece. Altrimenti passa immediatamente
a mysqli , dove le istruzioni preparate e i parametri associati forniscono un meccanismo più robusto per l'escape dell'input dell'utente.
Detto questo, la risposta può essere trovata leggendo la descrizione di mysql_real_escape_string
e addslashes
:
Differenza n. 1
addslashes non sa nulla delle codifiche di connessione MySql. Se gli passi una stringa contenente byte che rappresentano una codifica diversa da quella utilizzata dalla connessione MySql, sfuggirà felicemente a tutti i byte aventi i valori dei caratteri ' , " , \ e \x00 . Potrebbe non essere uguale a tutti i personaggi ' , " , \ e \x00 se stai usando una codifica diversa dalle codifiche a 8 bit e UTF-8. Il risultato sarà che la stringa ricevuta da MySql sarà danneggiata.
Per attivare questo bug, prova a utilizzare iconv
per convertire la tua variabile in UTF-16 e poi eseguirne l'escape con addslashes . Guarda cosa riceve il tuo database.
Questo è uno dei motivi per cui addslashes non deve essere utilizzato per la fuga.
Differenza n. 2
A differenza di addslashes , mysql_real_escape_string esegue anche l'escape dei caratteri \r , \n e \x1a . Sembra che anche questi caratteri debbano essere sottoposti a escape quando si parla con MySql, altrimenti il risultato potrebbe essere una query errata
Questo è l'altro motivo per cui addslashes non deve essere utilizzato per la fuga.
