htmlentities in šumniki

Imam eno težavo. Ko uporabnik submita formo, uporabim htmlentities. Tako se izognem javascript hekom in preprečim da bi uporabnik vnesel kak style.

htmlentities($_POST['vsebina'], ENT_COMPAT, "UTF-8");

Problem pa je, ker mi ta funkcija converta tudi šumnike. Iz Rogaška tako nastane rogaška.

Ima kdo kako idejo kako bo obdržal to funkcijo, vendar da mi ne bi spremenilo šumnike? Obstaja kaka podobna rešitev?

Hvala

7 odgovorov

A to, da ti tut š-je converta predstavlja kakšno posebno oviro? Sej browser brez problema prikaže črko š namesto š.
Drugače pa napiši še eno funkcijo, ki ti zamenja š s črko š pa je ;)

Ovira ja ker moram primerjati vrednosti iz druge tabele. Sicer sem imel v mislih da napišem še eno funkcijo. Zanima me samo če sem kaj spregledal, če obstaja kaka druga podobna funkcija ali kak dodaten parameter, ki bi rešil to brez dodatne funkcije.

1

Če prav razumem, se problema mogoče lotevaš narobe. htmlentities() in htmlspecialchars() sta funkciji, ki jih kličeš nad podatki, ki gredo od tebe k uporabniku, torej, ko sestavljaš HTML, ne pa, ko podatke vpisuješ v bazo. Tam moraš narediti SQL escaping, kar je nekaj čisto drugega.

Primer:
- uporabnik vpiše: <script>'š'</script>
- podatek, ki ga daš v query: <script>\'š\'</script>
- iz selecta dobiš: <script>'š'</script>
- uporabniku pošlješ html escaped: <script>'š'</script> (oz. karkoli že pride ven)

1

hvala za rešitev.

fatg zakaj pa da ne bi že pri vpisovanju v bazo uporabil htmlspecialchars? Imam mini funkcijo, ki hkrati naredi SQL escaping in gre hkrati htmlspecialchars. Podatki se namreč prikazujejo na strani editprofile.php in na strani profile.php. Tako na strani profile.php ne potrebujem več klicati htmlspecialchars in je koda preglednejša.

Gre za to, da imaš podatke v bazi take, kot morajo biti, torej v obliki, ki ni odvisna od konteksta. HTML escaping je bil narejen izključno za potrebe izpisa v HTML, če boš podatke metal kam drugam (datoteka, javascript, css, ...), jih boš moral dodatno obdelovati. Pa da ti dela iskanje po recimo O'Rielly, namesto da bi imel v bazi O'Rielly in podobne finte. Pač, podatke naj bi v bazi imel v "čisti" obliki in jih po potrebi escapal glede na to, kam jih daš, ko jih daš.

2

Ja to pa ima zelo prav fatg,
dva zlata pravila:
escape when saving
encode while outputting

1