En primer lugar:no utilice mysql_escape_string , está en desuso (por una razón)!
Si tiene que admitir una aplicación heredada que se conecta a la base de datos a través de mysql extensión (que ha quedado en desuso
), use mysql_real_escape_string
en cambio. De lo contrario, cambie inmediatamente
a mysqli , donde las declaraciones preparadas y los parámetros vinculados proporcionan un mecanismo más sólido para escapar de la entrada del usuario.
Dicho esto, la respuesta se puede encontrar leyendo la descripción de mysql_real_escape_string
y addslashes
:
Diferencia #1
addslashes no sabe nada acerca de las codificaciones de conexión MySql. Si le pasa una cadena que contiene bytes que representan una codificación diferente a la codificación utilizada por la conexión MySql, felizmente escapará todos los bytes que tengan los valores de los caracteres ' , " , \ y \x00 . Esto puede no ser lo mismo que todos los personajes ' , " , \ y \x00 si está utilizando una codificación distinta de las codificaciones de 8 bits y UTF-8. El resultado será que la cadena recibida por MySql se corromperá.
Para desencadenar este error, intente usar iconv
para convertir su variable a UTF-16 y luego escapar con addslashes . Vea lo que recibe su base de datos.
Esta es una de las razones por las que addslashes no debe usarse para escapar.
Diferencia #2
A diferencia de addslashes , mysql_real_escape_string también escapa los caracteres \r , \n y \x1a . Parece que estos caracteres también deben escaparse cuando se habla con MySql, de lo contrario, el resultado puede ser una consulta mal formada
Esta es la otra razón por la que addslashes no debe usarse para escapar.
