Po pierwsze:nie używaj mysql_escape_string , jest przestarzałe (z jakiegoś powodu)!
Jeśli musisz obsługiwać starszą aplikację, która łączy się z bazą danych przez mysql rozszerzenie (które zostało przestarzałe
), użyj mysql_real_escape_string
zamiast. W przeciwnym razie przełącz się natychmiast
do mysqli , gdzie przygotowane instrukcje i powiązane parametry zapewniają bardziej niezawodny mechanizm unikania danych wprowadzanych przez użytkownika.
To powiedziawszy, odpowiedź można znaleźć, czytając opis mysql_real_escape_string
i addslashes
:
Różnica nr 1
addslashes nie wie nic o kodowaniu połączeń MySql. Jeśli przekażesz mu ciąg zawierający bajty reprezentujące kodowanie inne niż kodowanie używane przez połączenie MySql, szczęśliwie uniknie wszystkich bajtów mających wartości znaków ' , " , \ i \x00 . To może nie być to samo, co wszystkie znaki ' , " , \ i \x00 jeśli używasz kodowania innego niż kodowanie 8-bitowe i UTF-8. W rezultacie ciąg otrzymany przez MySql będzie uszkodzony.
Aby wywołać ten błąd, spróbuj użyć iconv
aby przekonwertować twoją zmienną na UTF-16, a następnie zmienić ją za pomocą addslashes . Zobacz, co otrzymuje Twoja baza danych.
To jeden z powodów, dla których addslashes nie powinien być używany do ucieczki.
Różnica nr 2
W przeciwieństwie do addslashes , mysql_real_escape_string zmienia również znaczenie znaków \r , \n i \x1a . Wygląda na to, że te znaki również muszą zostać zmienione podczas rozmowy z MySql, w przeciwnym razie wynikiem może być źle sformułowane zapytanie
To kolejny powód, dla którego addslashes nie powinien być używany do ucieczki.
