Newsgroup: it.comp.www.php
Titolo: problema grosso con le accentate..

Ciao all, ho uno strano problema con la visulizzazione delle lettere
accentate. Non so se il problema sia in php/apache/mysql..
Spiego: ho fatto il dump di un db (con phpmyadmin), su un altro pc ho
ricreato il db e importato i dati "dumpati" senza errori.
Le collation sono giuste (latin1_bin) però se visulizzo i dati in
phpmyadmin o comunque in un browser le accentate sono tutte cannate.
Se accedo a mysql dalla console, i dati vengono visualizzati
correttamente.
Se cambio manualmente la codifica nel browser impostandola a utf-8 vedo
bene i dati provenienti dal DB ma non gli altri, (stringhe dentro gli
script php). Se guardo l'html generato la situazione si inverte: ok i
dati dal db, cannati quelli degli script...
La sensazione è che ci sia un encoding sbagliato per i dati forniti dal
DB, il problema è che non so dove cercare: Ripeto le collation del DB
sono corrette, le versioni di mysql simili: 5.0.26->5.0.45 così come
apache (2.2.3->2.2.4) e php (5.2.0->5.2.4).
OS suse-10.2->suse-10.3
In passato non ho mai avuto problemi in questo genere di operazioni,
adesso non so più dove guardare..
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 Spiego: ho fatto il dump di un db (con phpmyadmin), su un altro pc ho
sarebbe bene usare i caratteri html tipo &egrave; al posto di è ecc...

 ricreato il db e importato i dati "dumpati" senza errori.
Ok, mi rispondo da solo. il problema stava proprio nel dump fatto da
phpMyAdmin; dump fatto in utf-8. Adesso l'ho rifatto da console con:
mysqldump --skip-set-charset mydb > mydb.sql
e i problemi sono spariti.
Mi pare strano però che non si possa fare da phpMyAdmin o c'è il
trucco ?


 sarebbe bene usare i caratteri html tipo &egrave; al posto di è ecc...
Assolutamente NO. :) Non è il modo giusto di risolvere un problema, ma 
è solo un modo per aggirarlo.
Bisogna imparare a scorporare il contenuto di un database, con la sua 
possibile rappresentazione: non necessariamente un campo di una tabella 
sarà sempre visualizzato come html. Potrei, con lo stesso campo, farci 
duemila cose diverse.
Ecco perchè, in un db, la "è" accentata deve rimanere "è", e non 
"&egrave;".
Quanto a Daniele, il problema dei charset è sempre una cosa 
fastidiosissima: si rischia di sbattere la testa per ore, anzi giorni, 
senza risultato.
Son contento comunque che tu abbia risolto. Era evidentemente un 
problema di charset, ma come tu stesso hai notato....vai a capire DOVE 
era! :)
Nello specifico, se non erro in phpmyadmin potrebbe essere possibile 
specificare il charset del dump (se non erro).
Tutto è bene quel che finisce bene. ;)
-- 
rob4you

nintesa wrote:

In fase di visualizzazione però, i dati nel db devono restare il
più "puri" possibile.
Comunque vedi altro mio post per la "soluzione".


 duemila cose diverse.
Contesto! Ma discutiamone...
Il mio ragionamento parte dal presupposto che si parli di php e mysql e 
che i dati possano essere usati per pagine html, invio per email o 
trasferimento ad applicativi non web tramite diverso interfacciamento.
Ad esempio se vanno sul web su un sito multilingue dovranno essere 
visualizzabili contemporaneamente da un italiano e da un tedesco che 
usano dei charset diversi.
Visto che il php ha apposite funzioni per passare da è a &egrave; e 
viceversa, in ogni momento e ogni volta ne ho voglia... mi sembra la 
soluzione migliore. Anche perché in ogni caso, prima di mettere i dati 
nel db devo fare un escape (tipo addslashes) ed il contrario quando li 
prelevo...
Che soluzione consiglieresti?

 prelevo...
addslashes non va mai usato. E` il male. Mai! Mai! Mai! A meno che tu 
non sia assolutamente sicuro che non puoi farne a meno.
I dati in database si salvano con mysql_real_escape_string() e simili. 
Meglio ancora con PDO, cosi` non si dimentica l'escaping.
Quando li tiri fuori, se hai fatto le cose per bene (cioe` uniformato 
tutto a utf-8), basta scriverli sullo stdout, e saranno gia` pronti. E 
saranno pronti anche per email, xml, json, ecc.
Se sai che dei dati ti arrivano in iso-8859-1 (per esempio da un utente 
Mac su un CD), li converti in utf-8 al momento di inserirli in DB. Se 
ti arrivano in win-1252, stessa cosa.
Tranne che per browser antichissimi o pessimi (no, qui IE, dalla 6 in 
poi, non c'entra, per fortuna) vivi tranquillo. Forse avrai problemi 
con qualche utente Mosaic su Windows 3.11, ma nel 2007 (quasi 2008) 
potrei dire "cazzi suoi"... :)
Bye.

Quindi mi dici...
in tutte le pagine imposto charset utf8, e prima di buttare i dati nel 
db li passo con mysql_realescape_string
ora una domanda stupida: se negli header imposto charset utf8, i dati 
inseriti nei form mi arrivano in utf8 indipendentemente dal browser che 
usa l'utente... dico bene?
Grazie per la spiegazione.

 usa l'utente... dico bene?
Esatto anche qui.
Bye.

 Esatto anche qui.
Aggiungo solo che nel caso dei form, può essere specificato un 
attributo "accept-charset".
Maggiori info a riguardo:
http://www.w3.org/TR/html4/interact/forms.html#adef-accept-charset
-- 
rob4you