[ captPicard @ 03.09.2012. 10:49 ] @
Dakle, imam tablicu na serveru u kojoj su podaci u jednome polju npr: TRGOVAČKI OBRT "TEST"

Problem se javlja kod prikaza tog podatka u tablici (dvostruki navodnici). Evo primjera:

Code:
<td><input type="text" name="txtNaziv" size="20" value="<?=$objResult["naziv"];?>"></td>


Sam prikaz sam riješio na slijedeći način:

Code:
$naziv = $objResult["naziv"];
$naziv = str_replace ("\"", "",$naziv);


Code:
td><input type="text" name="txtNaziv" size="50" value="<?=$naziv?>"></td>


I to mi rješava problem sa prikazom, međutim, meni je taj podatak potreban u izvornom obliku jer ga koristim za editiranje tog polja u bazi. Ako kasnije napravim update tog polja, podatak će se zapisati bez navodnika, a to nije ispravno.

Ukratko, kako se rješava problem zapisa sa duplim navodnicima?

Hvala!
[ captPicard @ 03.09.2012. 11:00 ] @
Mislim da sam pronašao rješenje:

Code:
htmlspecialchars();


ali ipak neka mi netko kaže ako je ovo loša praksa ili se to tako inače radi.
[ plus_minus @ 03.09.2012. 12:18 ] @
Najbolji i najfunkcionalniji način za saniranje svih mogućih problema koji mogu da se vežu za sigurnost ili samu sintaksu u bazi ili source kodu, jeste ako se to uradi pri samom unosu podataka. Ne kasnije.
Don't let it in without check, Luke. No exceptions.

Zašto ti navodnici nisu prevedeni u entitet u toku upisa, pre samog upisa u bazu?

Recimo, kada u utf-8 html-u upišeš &quot; pretraživač kaže "
Baza je logično, utf-8 po svim merilima i lejerima.

Najbolji i najlaganiji način jeste

Code (php):


$inputFieldWithQuotes = htmlentities($_POST['inputField'], ENT_QUOTES, "UTF-8");

# ...
# ....
# Pre nego što na red dođe upis u bazu

$var= array($inputFieldWithQuotes,$inputWithoutQuotes, $SomeOthervar);
$your_var_ForDb = base64_encode(serialize($var));

# Za raspakivanje ide obrnut proces

$retrieveYour_array_FromDb = unserialize(base64_decode($yourPackedVarFromDb));

 


Nebitno je koliki je array. Jedna stavka/string ili mali milion njih.
base64_encode/decode() sa un/serialize() 'eskejpuje' sve singl i doublq.

[Ovu poruku je menjao plus_minus dana 03.09.2012. u 13:31 GMT+1]
[ bantu @ 03.09.2012. 14:50 ] @
@plus_minus
Kako onda sa tako encodovanim podacima manipulišeš u bazi pretraga, sortiranje, itd...

@captPicard
Nisi naveo o kojoj bazi je riječ. Pretpostavljam da je MySQL, ukoliko jeste, pogledaj funkcije mysqli->real_escape_string() i mysql_real_escape_string().
[ plus_minus @ 03.09.2012. 15:20 ] @
^^

Može, jedan foreach loop koji se odnosi samo na obrnut proces un/base64_decode i eventualno ..
recimo, jedan ternarni operator, na pravom mestu, ukoliko nisu sva polja u tabeli takva.
Za baratanje sa oracle ili bilo kojim drugim sql rešenjem base64_encode/serialize nije baš 'fleksibilan' način (s' tim se slažem i ja) i može imati performance impact prilikom pretrage ukoliko je parče gde se pretražuje - huge.

Ali, može i tako. Za deo baze gde se nalaze logovi, uname, pass, itd..

Za deo baze gde nema toga, može lepo da radi samo base64_encode/decode bez serijalizacije gde bi se tražilo kroz base64.
Maltene isto kao sa md5('match') npr. s' tim što se logično 'decode' vrši samo pri ispisu podataka.
[ captPicard @ 04.09.2012. 11:14 ] @
Citat:
bantu:
@captPicard
Nisi naveo o kojoj bazi je riječ. Pretpostavljam da je MySQL, ukoliko jeste, pogledaj funkcije mysqli->real_escape_string() i mysql_real_escape_string().


Je, MySQL je u pitanju. Hvala! :)

I hvala obojici na pojašnjenju!