Input escape - mysql_real_escape_string

[bluesman]

Da li neko može da mi objasni koja je prava razlika između:

mysql_real_escape_string
mysql_escape_string
addslashes

osim što mysql_real_escape_string proverava charset u bazi (znači zahteva link do konekcije) ja nisam primetio da se drugačije escape-uju stringovi. Interesuju me praktični primeri.

[dee]

addslashes escape-a: ' , " , NULL , \

mysql_real_escape_string: \x00, \n, \r, \, ', " and \x1a

mysql_escape_string:

This function is deprecated.This function is identical to mysql_real_escape_string() except that mysql_real_escape_string() takes a connection handler and escapes the string according to the current character set. mysql_escape_string() does not take a connection argument and does not respect the current charset setting.

[Ivan]

Sto se sigurnosti tice najbolje je koristiti mysql_real_escape_string (http://shiflett.org/archive/184). Mada u nekim slucajevima (http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html) postoji mogucnost i da se ova zastita zaobidje.

[bluesman]

Da li se mysql_real_escape_string svaki put poveze na bazu kada god pozoves funkciju? Ako je tako - to mi ne zvuci kao beznacajno usporenje.

[ivanhoe]

koliko sam uspeo da shvatim, ukoliko koristis latin ili utf8 enkoding, razlike nema (jer utf8 ima takav raspored karaktera da nema sanse da se baza "zbuni"). Ukoliko koristis neke druge enkodinge onda addslashes ne radi jer nije safe za rad sa multibajt karakterima, a takodje ni mysql_escape_string, jer on valjda koristi enkoding veze, a ne enkoding baze...

Sto se efikasnosti mysql_real_escape_string tice bilo bi logicno da drajveri za bazu kesiraju te podatke, a cak i da ne kesiraju, enkoding je meta podatak koji svaka tabela "zna napamet", tako da je provera toga u bazi veoma brza, pogotovo kad je baza u lokalu...

ima raznih perfomance freakova na netu, a nikad nisam cuo da neko kritikuje mysql_real_escape_string, tako da sumnjam da tu ima nekog problema...

[srdjevic]

mysql_escape_string je zastarela.
mysql_real_escape_string koristis za eskejpovanje podataka za koriscenje u upitima. (pa se jos provlaci kroz addcslashes() za koriscenje u LIKE segmentima upita)
addslashes() se koristi za generalno eskejpovanje, i vrlo se retko koristi u praksi, s obzirom da se u bazi sve drzi...

[bluesman]

srdjevic: to je ono sto svi znamo (mada se ne slazem za addslashes a i srocio si vrlo cudno sva 3 objasnjenja), mene interesuje neki praktican primer.

[Ivan]

Ako hoces primere poseti ona dva linka koja sam ostavio u proslom postu ...

[bluesman]

Posetio sam te linkove odmah, medjutim to nije nesto sto me je zainteresovalo. Tu se radi o specificnom slucaju sa kineskim charsetom i moze da odgovori na deo pitanja, medjutim interesuje me prica o "pravom zivotu" a ne ove fantazije.

[ivanhoe]

kao sto sam vec napisao, za plain ascii i za utf8 nema ama bas nikakve razlike sta ces koristiti...

[bluesman]

To sam i mislio, i na osnovu svih mojih testova nisam primetio nikakvu znacajnu razliku, ali sam hteo da proverim.

[Ilija Studen]

Sa #9 si "ubio" diskusiju pošto su upravo "fantazije" situacije gde se addslashes() i mysql_real_escape_string() razlikuju.

Ima par zanimljivih stvari u SitePoint diskusiji (http://www.sitepoint.com/forums/showthread.php?t=337881) koji je Chris Shiflett linkovao u addslashes() Versus mysql_real_escape_string() (http://shiflett.org/archive/184) članku (prvi link u Ivanovom postu (http://www.devprotalk.com/showpost.php?p=31872&postcount=3)). Jedna od zanimljivijih je upravo poreklo funkcije: addslashes() je deo PHP-a i može se reći da je funkcija opšte namene dok je za mysql_real_escape_string() odgovoran MySQL community i specijalizovan je za rad sa MySQL-om.

Uostalom, ne vidim neki veliki problem ovde. Manje više stvar ukusa, a ako ne želiš da razmišljaš o ovakvim stvarima koristiš preporučeno rešenje i uživaš.