$new = htmlspecialchars($string_do_bazy, ENT_QUOTES);
Czy to mnie zabezpieczy przed wstrzyknieciem kodu poprzez formularz jakis ?
0
0
Przed wrzutem do bazy MySQL: mysql_real_escape_string()
PDO: PDOStatement::bindValue()
Przy wyświetlaniu: htmlentities($string, ENT_COMPAT, 'utf-8'); //ja tak tego używam (dla utf8)
0
no teoretycznie tak, jeszcze dochodzą przypadki kiedy nie zamkniesz wejścia w cudzysłów (np wartości liczbowe), które musisz konwertować na liczbę, a ogólnie powinieneś jednak skorzystać z funkcji do tego przeznaczonych, np dla mysql jest funkcja mysql_real_escape_string która jest trochę bardziej złożona no i nie zmienia cudzysłowów na inne znaczki jak w tym przypadku
0
ale liczby tez mozna w cudzysłowie zamknąć
0
tylko po co, zeby mysql sie nie nudzil i konwertowal?
0
żeby uprościć implementację?
równie dobrze można usunąć wszystkie entery w kodzie php, żeby interpreter miał mniej bajtów do przetwarzania...
0
z tego co sie orientuje, to php kompiluje skrypty do bajtkodu, wiec enetery zbyt duzo nie zmienia, a rzopoznawanie liczby i stringow dla mySQL moze znacznie skrocic czas. oczywiscie dla prostych operacji to nie ma znaczenia, ale lepiej wyrabiac w sobie dobre nawyki, jezeli to nic nas nie kosztuje.
0
przykład z enterami moze troche z tylka dalem, ale idea chyba jasna.
hgfhgfh napisał(a)
nie zamkniesz wejścia w cudzysłów (np wartości liczbowe), które musisz konwertować na liczbę
wyjasnilem, ze nie musisz.
Poza tym owszem - mozna skupiać sie na nieznaczących optymalizacjach, ale chyba nie za to nam płacą? Inna sprawa - jeżeli dajemy np. inserty ręcznie, przez mysql_query to prawda - elegancko jest dawać inty jako liczby, ale jeżeli robi to za nas automat (np. klasa przyjmujaca arraya i robiaca z niego zapytanie) to można sobie dać spokój - imho w bazie są zaimplementowane optymalne algorytmy wykrywania i konwersji string->int i wyważać otwartych drzwi nie ma sensu...