Jak zauważyli inni, nr 2 jest poprawną odpowiedzią. Pozostaw to „surowe”, dopóki nie będziesz tego potrzebować, a następnie odpowiednio ucieknij.
Aby wyjaśnić dlaczego (i powtórzę/podsumuję inne posty), weźmy scenariusz 1 do jego logicznego ekstremum.
Co się stanie, gdy ktoś wpisze „ ' OR 1=1 <other SQL injection> -- ". Teraz może zdecydujesz, że skoro używasz SQL, powinieneś kodować dla SQL (może dlatego, że nie używałeś sparametryzowanych instrukcji). Więc teraz musisz mieszać (lub zdecydować się) na kodowanie SQL i HTML.
Nagle twój szef postanawia, że również chce uzyskać dane wyjściowe w formacie XML. Teraz, aby zachować spójność wzoru, musisz również go zakodować.
Następny CSV - o nie! A jeśli w tekście występują cudzysłowy i przecinki? Więcej ucieczek!
Hej - co powiesz na fajny, interaktywny interfejs AJAX? Teraz prawdopodobnie chcesz zacząć wysyłać JSON z powrotem do przeglądarki, więc teraz {, [ itp. wszystkie muszą być brane pod uwagę. POMOCY!!
Tak więc wyraźnie przechowuj dane zgodnie z podanymi (oczywiście z zastrzeżeniem ograniczeń domeny) i zakoduj odpowiednio do wyników w momencie, gdy ich potrzebujesz . Twoje dane wyjściowe nie są takie same jak dane.
Mam nadzieję, że ta odpowiedź nie jest zbyt protekcjonalna. Podziękowania dla innych respondentów.
