Newsgroup: it.comp.www.php
Titolo: caratteri speciali

Per risolvere il problema dei caratteri speciali inseriti dentro a un
db:
Tra le varie soluzioni direttamente sulle variabili:
1. addslashes    e   stripslashes
2. mysql_real_escape_string
3. htmlspecialchars
e quelle sul file di configurazione php.ini
4. magic_quotes_runtime = on
5. magic_quotes_gpc_= on
Quale è quella che va usata per risolvere senza inconvenienti il
problema?
Ipotizzo che l'agire sul file di configurazione sia la soluzione piu'
semplice in modo che poi non bisogna
dentro al codice php preoccuparsi piu' di aggiungere le funzioni
correttive; pero' poi tale configurazione
facile a fre in locale si puo' fare anche su hosting? (o dipende dal
provider) ?
Tale problema di caratteri speciali è solo un problema di MySql o
comunque di altri db tipo Firebird, Oracle, Postgresql; etc?
GRazie

 comunque di altri db tipo Firebird, Oracle, Postgresql; etc?
E' un problema per tutti i DB che utilizzano i caratteri single quote
('), double quote ("), backslash (\) and NUL (the NULL byte) in qualche
modo speciale.
Io ho risolto cosi':
function safe_set (&$var_true, $var_false="")
{
	if (isset ($var_true))
	{ $var_true = $var_false; }
	return $var_true;
}
function safe_db_set(&$var_true,$var_false="")
{ 
	safe_set ($var_true, $var_false);
	$var_true = stripslashes ($var_true);
	return $var_true;
}
function safe_slash_set (&$var_true, $var_false="")
{
	safe_set ($var_true, $var_false);
	if (!(get_magic_quotes_gpc () || get_magic_quotes_runtime ()))
	{ $var_true = mysql_escape_string ($var_true); }
	return $var_true;
}
// esempi di utilizzo
safe_set ($_GET["testo"], ""); 
// cosi' ho la sicurezza che $_GET["testo"] sia valorizzato e posso 
// utilizzarlo con sicurezza all'interno dello script (niente notice 
// undefinded etc.). 
safe_slash_set ($_GET["testo"], ""); 
// cosi' ho la sicurezza che $_GET["testo"] abbia l'escape e posso
// utilizzarlo con sicurezza nei DB
safe_db_set ($_row["testo"], "");
// cosi' ho la sicurezza che $_row["testo"] sia valorizzato e senza 
// escape 
Saluti.
-- 
I'am what I'am, I do what I can
Sei un newbie? Leggi questo 
http://url.repository.biz/go/1

 }
Una volta č successo che un notice mi abbia mostrato dove commettevo
l'errore aiutandomi cosě a risolverlo.
Tutto č successo dopo aver cancellato il safe_set.
Con questa funzione gli errori non passano...
Dato che ho avuto modo di testare piů volte la tua cultura in merito mi
chiedo cos'č che non ho capito?
Perchč ritengo utile vedere i notice?
Grazie come sempre

 Perchh ritengo utile vedere i notice?
Ho l'error_reporting impostato ad E_ALL, anche io ritengo utile
visualizzare i notice, ma non certo rischiare che l'utente finale del
mio sito/prodotto li visualizzi.
Ecco perche' utilizzo safe_set. 
Mi permette di avere la certezza che le variabili che utilizzo nello
script siano sempre valorizzate (sia con register globals attivato o
meno). Inoltre posso tranquillamente testare gli script bypassando
safe_set con un semplice commento.
Il problema che ti affligge probabilmente deriva dall'utilizzare
funzioni sviluppate da altri senza aver compreso fino in fondo le
necessita' e le motivazioni che ne hanno motivato la scrittura.


Quindi concordi con me se in fase di sviluppo non uso safe set?
Trovo giusto e utile aggiungerlo dopo...

 Trovo giusto e utile aggiungerlo dopo...
Se te preferisci non utilizzarlo, e' una tua scelta dettata
probabilmente dal tuo modo di sviluppare.
Personalmente lo mantengo attivo anche in fase di sviluppo, tanto gli
errori li trovo comunque =)


 mio sito/prodotto li visualizzi.
Infatti.. in produzione non è nemmeno una cattiva idea mettere 
l'error_reporting a 0.
Volendo nel php.ini.. ma meglio, nella maggior parte dei casi, in testa 
allo script.
$debug_mode = 0;
if ($debug_mode == 0) {
     error_reporting(0);
} else {
     error_reporting (E_ALL);
}
---
Le proposte sono sempre capite dagli altri in maniera diversa da come le 
concepisce chi le fa.

 modo speciale.
Il modo con il quale i database memorizzino i dati non ha molto a che fare
con il perchč ne facciamo l'escaping.
Gli unici caratteri da 'escapare' per i server SQL sono i caratteri
'significativi', ovvero quelli che per il motore che legge la sintassi SQL
significano qualcosa di diverso rispetto al carattere stesso.
Il carattere ' (apice) indica la fine di stringhe, il carattere %
(percentuale) č una wildcard, etc etc. Un server in grado di leggere
l'encoding UTF-8 dei caratteri non ha bisogno di escaping se non per quei
caratteri che hanno un significato speciale. Se inserisco un carattere
cinese, non ci saranno problemi.
Il problema, riassumendo, non riguarda la stranezza del carattere ma il
fatto che questo assuma signficati speciali.
MySQL dalla versione 4.1 ha cambiato un po' di cose. E' cmq in grado di
memorizzare caratteri di qualsiasi genere.
Tutti i browser (Mozilla Firebird, ie, etc) lavorano molto bene con Unicode
e UTF-8 e con gli encoding piů diffusi; nessun problema.
Sta a chi fa la pagina web specificare il charset corretto, ma qui sono in
pochi che ci sanno fare davvero.
A titolo esemplificativo, se guardi una pagina in Coreano (che non usi
UTF-8) e guardi il sorgente con IE non vedrai molto. Con Mozilla (che ha un
visualizzatore di source in grado di usare gli encoding) vedrai il sorgente
perfetto.
Concludendo:
Tutti (xml, html, etc etc) coloro che usano dei caratteri speciali
all'interno del loro ambiente (apici, backslash, %, * etc etc) hanno un modo
alternativo di rappresentarli detti escape-chars, entity etc etc
I caratteri DAVVERO speciali sono un'altra cosa e l'unico problema di cui ti
devi preoccupare č del fatto che, non potendo digitarli sulla tastiera, devi
usare un codice (Unicode UCS-2) corrispondente.
Per quanto riguarda Php, non so se dentro il codice Php puoi scrivere le
variabili in UTF-8 come in altri linguaggi (Java, Coldfusion, etc) che ti
permettono di dare un nome cinese ad una var usando i caratteri cinesi.
Ciao
J

PS:
Strings
A string is series of characters. In PHP, a character is the same as a byte,
that is, there are exactly 256 different characters possible. This also
implies that PHP has no native support of Unicode. See utf8_encode() and
utf8_decode() for some Unicode support
http://it.php.net/types.string
Julien

 il fatto che questo assuma signficati speciali.
Come ho scritto sopra.



Aspe', la prima frase è tua, la seconda è mia :-D
J