codifica caratteri - utf8 encode o trim + str replace???

[markzzz]

salve. ultimamente, lavorando al mio sito, mi son imbattuto in problemi nell'inserimento nel database mysql di caratteri speciali (quali, per esempio, il semplice apice ').

ho sempre usato il classico $var=trim(str_replace("'", "\'", $var));

poi però mi son dovuto imbattere in un altro problema : dei caratteri proveniente da dei file di testo che li codificava in caratteri strani (es. ö=�).

ho risolto utilizzando il metodo $var=utf8_encode($var) , ed ho notato che utilizzando quel metodo anche gli apici me li gestisce in maniera ottimale (senza dover ricorrere al trim + str replace. quello che mi chiedo è :

quello che mi sembra strano è che girando in internet tutti consiglino questo metodo per i caratteri di escape, soprattutto per apici e database, quando l'utf8 encode è molto più pratico e prende in considerazione molti più caratteri. mi sfugge qualcosa oppure è davvero molto più pratico?

saluti

[bubi1]

str_replace("'", "\\'", $var)

girando in internet tutti consiglino questo metodo per i caratteri di escape

sono abbastanza convinto che tutti consigliano addslashes(), e non str_replace..

Per i caratteri strani, ti consiglio vivamente di leggere qualche guida sulle codifiche php/browser, collations del mysql, etc.

E per l'apice, se te lo ha inserito senza l'escape, o era un apostrofo tipografico/extended ascii/altro carattere e non un apice ascii 39, o hai le magic_quotes on, o avevi i values nella query racchiusi tra le virgolette doppie, quindi senza bisogno di escape di quelle singole, o qualche altra stranezza.

Non e' una questione di php, mysql semplicemente non ti fara' mai fare una query tipo insert into table (campo) values('aaa ' aaa'); . E vale per qualsiasi programma che prende qualcosa in input: non si possono passare i delimitatori dell'input allinterno dell'input stesso senza fare un escape.

Codificare l'apice vero in utf-8 non lo cambia per nulla, perche' in utf-8 (o iso-8859-1) qualsiasi byte minore di 128 e' rappresentato da un simbolo ascii con lo stesso codice.

[markzzz]

grazie mille per la risposta ben dettagliata! allora, per quanto riguarda l'apice, non ho nessuna delle ipotesi che hai suggerito : il simbolo ascii era quello caratteristico inserito da tastiera, magic_quotes sicuramente off visto che è la prima volta che le sento nominare; per i values con virgolette doppie non credo, la query è questa :

$smex=utf8_encode($smex);
$insert = mysql_query("INSERT INTO suggestions (usersugg, mexsugg, date) VALUES ('".$_SESSION['nickname']."','$smex','$date')",$mydb); 

infatti mi è sembrato molto strano anche a me questa cosa, soprattutto perchè una volta inserito nel database non c'era nessuna "codifica" strana ai caratteri normali (compreso l'apice).

sarebbe interessante sapere perchè succede questo (anche perchè in un altra pagina ho il problema che con una query contenente caratteri provenienti da un txt, utf8 e basta non funziona, devo aggiungere trim + str_replace).

se volete aiutarmi, ne sarei grato. innanzitutto grazie a bubi1 per il supporto!

[markzzz]

uhm, ripensandoci, molto probabilmente il problema è perchè inserisco le variabili in questo modo nella query dove mi dà problemi : '".$hours[$nrt]."'

infatti nelle altre query inserisco tramite '$smex' , senza i doppi apici prima...

può essere colpa dei doppi apici?

perchè appunto ripeto se inserisco tramite '$smex' e $smex ha degli apici, la utf8 basta (sostituisce anche la str replace)...

[bubi1]

Guarda, ti aiuterei volentieri, ma stiamo sfiorando l'assurdo..
Cio' che ti ho detto prima sull'impossibilita di mandare al server mysql certi caratteri senza escape, e su come utf8 codifica gli apici - sono degli assiomi. Quindi deve esserci qualcosa di particolare nei dati che inserisci. Dovresti fare un po di debug, ad esempio fare un var_dump dei dati che inserisci, prima dell'encode e dopo.. e anche della query stessa come risultato finale, e provare ad eseguirla a mano.. etc.
Ad esempio fai una prova: imposta la $smex ad un valore predefinito con apici, es. $smex = "anch'io" . Cosi ti convinci che utf8_encode non cambia nulla sull'apice.
E per curiosita', fai un echo get_magic_quotes_gpc(); echo ini_get('magic_quotes_sybase'); , se ti restituiscono valori come 1, ON, TRUE si spiegano molte cose..

[markzzz]

sisi in effetti hai ragione... dovrò testare i vari casi e rendermi conto di come reagiscono.

oppure, ho visto che esiste questa funzioncina in php : mysql_real_escape_string();

ho provato, e và alla grande, si arrangia lei con i caratteri di escape (anche perchè non credo ci siano solo gli apici. anche le " danno problemi.). quindi evitando di scoprire tutti i vari problemi, mi affiderei ad essa.

ora quello che mi interesserebbe sapere è questo : visto che ormai ho già scritto decine e decine di query, e i dati da fare l'escape provengono tutti da POST/GET/SESSION, non mi basterebbe aggiungere questa funzioncina alla pagina generale (visto che per ogni sezione del sito carico sempre quella e a seconda degli include mostro varie zone) che mi codifica l'intero array della request? magari sarebbe più comodo...

[bubi1]

Comodo si, ma solo se non hai eccezioni. Ad esempio se alcuni dati li devi inserire non nel database ma in un file di testo.

[markzzz]

uhm no, ho solo inserimenti nel database, nessuno sul file di testo. (o forse in futuro, ma basta settare delle variabili per esempio if($_GET['paginachevoglioescapare'] ==> funzioncina... in teoria)

[markzzz]

alla fine ho risolto così :

<script type="text/javascript">
	// attendo completamento caricamento pagina
	$(document).ready(function() {
		// stampo i dati prelevati dal database nelle input box
		$("#inpute").val("<?= addslashes($event) ?>");
	});
</script>


<input type="text" size="73" id="inpute" name="event" />

aggiungo carattere di escape al momento della stampa!

solo una cosa : è vero che gli script è sempre meglio inserirli nell'header? perchè questo ad esempio lo ho inserito fuori e dopo...