un chiarimento finale su UTF-8 :: confusione o verità

[daniele_dll]

Originariamente inviato da webus
Non per una situazione ideale, ma reale. Fatto salvo che tutto ciò che dici sui problemi lagati al servire dati in utf-8 con PHP è giusto, per me il punto principale resta l'integrità dei dati, mentre il veicolo con cui servirli è solo un veicolo.

php, come mysql, sono si solo un metodo per conservare i dati ma comunque i dati vengono immessi e conservati tramite loro e sempre tramite loro vengono di nuovo acquisiti e visualizzati quindi perché torturarsi la vita ed aggiungere possibili problemi per il futuro?

inoltre il dato rimane esattamente cosi com'è ... cambia solo lo schema di conservazione

Oltretutto pure da un punto di vista etico i dati non sono di mia proprietà ma dell'azienda, del cliente, a differenza del codice che invece posso elaborare e cambiare secondo necessità.

non vedo cosa c'entri l'etica in questo discorso? :master: i dati non vengono alterati in nessun modo vengono soltanto conservati in base ad uno schema ben preciso ... ovvero latin1 + entità html

i dati sono sempre li e ci sono sempre tutti ed il cliente ha sempre la possibilità di accederci senza alcun problema -.-'

Spostare la soluzioni dei problemi derivati dal veicolo modificando l'origine dei dati mi pare poco corretto, pure se riconosco che nella maggior parte delle situazioni di database dedicati esclusivamente alla pubblicazione web siano più semplici da gestire, almeno nell'immediato.

guarda che il tuo discorso è fallace a priori per un motivo molto semplice: con eventuali applicativi esterni non si deve ASSOLUTAMENTE accedere direttamente al database ma, al massimo, se ti serve leggere dati o modificarli, devi accedere a dei webservice!
Accedendo direttamente al database si sbatte nei problemi che dici tu oltre a problemi di sicurezza: il software del client ha all'interno i dati di accesso al database per leggere e scrivere ... ed inoltre se i dati nel database vanno magari scritti aggiornando altre tabelle di contorno (statistiche/dati precalcolati) devi duplicare il codice per fare anche questo!

[bland]

CASPITA!!!!
avevi ragione

echo 'Codifica corrente: [b]' . mysql_client_encoding() . '[/b]
'; 

mi restituisce latin1 !!!!
ma è normale? anche se ho settato il db da phpmyadmin in utf8??

ho provato a mettere la funzione

mysql_set_charset('utf8'); 

ma mi da errore! è corretto scritto così?

[daniele_dll]

è presente in php dalla versione 5.2.3, alternativamente, come sta scritto sui commenti, puoi lanciare una query che setti il charset per la connessione

mysql_query('SET CHARACTER SET utf8');

[bland]

beh ho scritto cosi ma non cambia nulla....
che sbaglio?

$conn = mysql_connect("xxxxxx","xxxxxxx","xxxxxx") ;
mysql_select_db("xxxxxxxxx",$conn) or die("Errore");
echo 'Codifica corrente: [b]' . mysql_client_encoding() . '[/b]
';
mysql_query('SET CHARACTER SET utf8');
echo 'Codifica corrente: [b]' . mysql_client_encoding() . '[/b]
'; 

[webus]

Originariamente inviato da daniele_dll
guarda che il tuo discorso è fallace a priori per un motivo molto semplice: con eventuali applicativi esterni non si deve ASSOLUTAMENTE accedere direttamente al database ma, al massimo, se ti serve leggere dati o modificarli, devi accedere a dei webservice!
Accedendo direttamente al database si sbatte nei problemi che dici tu oltre a problemi di sicurezza: il software del client ha all'interno i dati di accesso al database per leggere e scrivere ... ed inoltre se i dati nel database vanno magari scritti aggiornando altre tabelle di contorno (statistiche/dati precalcolati) devi duplicare il codice per fare anche questo!

Webservice? Beh, ci sono casi in cui impiego i webservice, ma se ad esempio il database in questione è parte del gestionale interno all'azienda certamente non mi metto ad impostare il lavoro d'ufficio attraverso un webservice.
Come dicevo prima PHP per me è solo uno tra i tanti strumenti che mi permettono di accedere ai dati. E nemmeno il più importante. È per questo che sostengo che intervenire sui dati piuttosto che sul veicolo - quando è il veicolo ad avere problemi - mi pare poco corretto.

Poi, torno a dire, nel caso siano dati che supportano solo un sito web allora si tratta di una soluzione più comoda, e ne convengo. Ma si ferma lì.

[daniele_dll]

Originariamente inviato da webus
Webservice? Beh, ci sono casi in cui impiego i webservice, ma se ad esempio il database in questione è parte del gestionale interno all'azienda certamente non mi metto ad impostare il lavoro d'ufficio attraverso un webservice.

sinceramente, sia per motivi di sicurezza sia per motivi di duplicazione del codice, evito di accedere direttamente al database con C# (che è quello che uso per il software desktop)

lo sviluppo di un webservice in php basato su XML-RPC è velocissimo e richiede pochissimo tempo.

Come dicevo prima PHP per me è solo tra i tanti strumenti che mi permettono di accedere ai dati. E nemmeno il più importante. È per questo che sostengo che intervenire sui dati piuttosto che sul veicolo - quando è uno di questi ad avere problemi - mi pare poco corretto.

Tenere i dati in UTF8 senza entità può trovare ragione quando c'ho solo il database e non devo mostrarlo in un sito, ma quando lo scopo primario è quella della visualizzazione tramite browser seguo quella linea e tramite webservice bypasso il problema, ovvero prendo il testo e converto le entità in UTF8

il grandissimo dramma di php è che non supposta i caratteri multibyte (se ci fai caso in java/c# e simili esiste il tipo carattere, stringa e byte ... perché il carattere è un insieme di byte, la stringa un insieme di caratteri) e quindi non conviene avere il tutto sotto utf8

Poi, torno a dire, nel caso siano dati che supportano solo un sito web allora si tratta di una soluzione più comoda, e ne convengo. Ma si ferma lì.

è normale che se i dati non devono essere visualizzati principalmente e/o esclusivamente su un sito web, non tengo manco io il contenuto encodato perché carico inutilmente i webservice senza motivo

poi come sempre TUTTO dipende da quello che uno deve farci con i dati ^^

[daniele_dll]

Originariamente inviato da bland
beh ho scritto cosi ma non cambia nulla....
che sbaglio?

$conn = mysql_connect("xxxxxx","xxxxxxx","xxxxxx") ;
mysql_select_db("xxxxxxxxx",$conn) or die("Errore");
echo 'Codifica corrente: [b]' . mysql_client_encoding() . '[/b]
';
mysql_query('SET CHARACTER SET utf8');
echo 'Codifica corrente: [b]' . mysql_client_encoding() . '[/b]
'; 

pardon, avevo guardato solo i commenti, ma non il manuale mysql

SET NAMES 'utf8' COLLATE 'utf8_general_ci'

l'ho provato e setta la codifica corretta

[bland]

beh....
la funzione qualcosa fa...

echo 'Codifica corrente: [b]' . mysql_client_encoding() . '[/b]
';
mysql_query("SET NAMES 'utf8' COLLATE 'utf8_general_ci'");
echo 'Codifica corrente: [b]' . mysql_client_encoding() . '[/b]
'; 

ma mi restituisce sempre latin1 sia nel primo echo che nel secondo..
e mi cambia qualcosa nella pagina.. un carattere e cioè ° mi diventa ° ... come mai?
comincio ad essere ancora più confuso.. :master:

Quello che accade in parole povere cos'e'?
il db è correttamente in utf8 ma nella letture del client (browser) la lettura è in latin1?
con questa funzione diventa veramente in utf8 e quindi vedo cosi?

[daniele_dll]

Originariamente inviato da bland
beh....
la funzione qualcosa fa...

echo 'Codifica corrente: [b]' . mysql_client_encoding() . '[/b]
';
mysql_query("SET NAMES 'utf8' COLLATE 'utf8_general_ci'");
echo 'Codifica corrente: [b]' . mysql_client_encoding() . '[/b]
'; 

ma mi restituisce sempre latin1 sia nel primo echo che nel secondo..
e mi cambia qualcosa nella pagina.. un carattere e cioè ° mi diventa ° ... come mai?
comincio ad essere ancora più confuso.. :master:

Quello che accade in parole povere cos'e'?
il db è correttamente in utf8 ma nella letture del client (browser) la lettura è in latin1?
con questa funzione diventa veramente in utf8 e quindi vedo cosi?

mysql_client_encoding forse legge le informazioni internamente

ecco, ora stai gestendo a tutti gli effetti i dati in formato utf8

[bland]

quindi la conversione è corretta ma quello che si vede no?
Perche il simbolo del ° è cambiato??
devo fare qualche decode?

...............

beh forse ho risolto cosi...

1) lascio i dati in utf8 sul server senza codificarli
2) aggiungo nella connessione del DB

mysql_query("SET NAMES 'utf8' COLLATE 'utf8_general_ci'"); 

e adesso quando immetto i dati sul db dal client PHP cambia qualcosa..
In più i campi del DB che prima risultavano scritti cosi

L\'offerta è valida per la notte del 14.02.08

ma in lettura erano convertiti correttamente, adesso diventano

L\'offerta è valida per la notte del 14.02.08

Mi chiedo solo se non è una cosa in più..
nel senso che anche senza questa cosa funzionava bene, ho fatto vedere anche ad altri..

Che ne dici?