Първо:не използвайте mysql_escape_string , той е отхвърлен (по причина)!
Ако трябва да поддържате наследено приложение, което се свързва с базата данни чрез mysql разширение (което е оттеглено
), използвайте mysql_real_escape_string
вместо. В противен случай превключете незабавно
към mysqli , където подготвените оператори и свързаните параметри осигуряват по-стабилен механизъм за избягване на въвеждането на потребителя.
Въпреки това, отговорът може да бъде намерен, като прочетете описанието на mysql_real_escape_string
и addslashes
:
Разлика №1
addslashes не знае нищо за кодирането на връзката на MySql. Ако му предадете низ, съдържащ байтове, представляващи кодиране, различно от кодирането, използвано от връзката MySql, той с радост ще избяга всички байтове със стойностите на знаците ' , " , \ и \x00 . Това може да не е същото като всички знаци ' , " , \ и \x00 ако използвате кодиране, различно от 8-битово кодиране и UTF-8. Резултатът ще бъде, че низът, получен от MySql, ще бъде повреден.
За да задействате тази грешка, опитайте да използвате iconv
за да преобразувате вашата променлива в UTF-16 и след това да я екранирате с addslashes . Вижте какво получава вашата база данни.
Това е една от причините addslashes не трябва да се използва за бягство.
Разлика №2
За разлика от addslashes , mysql_real_escape_string също така избягва символите \r , \n и \x1a . Изглежда, че тези знаци също трябва да бъдат екранирани, когато се говори с MySql, в противен случай резултатът може да бъде неправилно оформена заявка
Това е другата причина, поради която addslashes не трябва да се използва за бягство.
