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

[bland]

beh si ... conosco la funzione... ma usarla in che caso?

Salvo nei campi i dati convertiti con htmlentities() e poi per l'estrazione prima di stamparli li mando a

html_entity_decode($a); 

non credo di risolvere cosi ...

Ho provato adesso e non funziona..
in realtà non fa nessuna codifica..

è

resta cosi con o senza la funzione...

[daniele_dll]

asp ...

ricordati che quando li tagli e li hai in utf8 hai le entità composte da 2 byte e php non gestisce correttamente queste situazioni quindi lo devi fare da database il taglio

[webus]

Originariamente inviato da bland
quindi mi dici che sarebbe meglio convertire con le entities nel db i caratteri speciali?

Nel database ti direi di inserire i dati così come sono, assolutamente. Dopotutto non puoi dare per scontato a priori che li mostrerai sempre e solo attraverso un browser web.
Se hai problemi a visualizzarli con altri client è probabilmente perché la connessione o il driver di connessione usano un altra codifica. Non dimentichiamo che HTTP1.1 definisce ISO-8859-1 come codifica di default.

è meglio mettere

header('Content-type: text/html;charset=utf-8'); 

oppure

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

o tutti e 2?

Quello che conta maggiormente è la codifica che è predefinita nel server e in caso la sua capacità di servire la codifica giusta, come richiesta dal documento da servire. Spesso infatti i problemi nascono non dal documento, ma da server configurati male.
Altri problemi poi possono derivare dalla pratica in uso in explorer (fino al 6, non so per il 7) di eseguire uno sniffing del documento, violando la regola delle specifiche HTTP 1.1 che lo vieterebbero espressamente.

Riguardo le due header sopra, anche se identiche nella forma, stando alla mia esperienza sembra che quella in Php riesca a influire più profondamente sul server, ma vale sempre la regola che è bene verificare le header che vengono realmente trasmesse.
Verificare anche che pure il file php sia salvato con la codifica corretta, così come eventuali file inclusi.

[daniele_dll]

per prima cosa ... html_entity_decode non fa la codifica ma la decodifica, ovvero portà una entità html nei rispettivi byte di conseguenza è normale che non ti codifichi nulla.

per quanto riguarda il mio penultimo post: è compongono per esempio una lettera accentata, mettiamo la à (solo per fare un esempio)

E' sbagliato dire che le stringhe di php sono formate di "caratteri" perché un carattere varia di dimensione in base al contesto, in un formato unicode ogni "carattere" è composto da 2 byte ... in formato utf8 ogni carattere è composto da almeno un byte e può arrivare fino a 4 ... in utf16 da 2 byte a 4 e cosi via.

Quindi se estrai una stringa in utf8 la vedrai correttamente visualizzata nel browser perché ovviamente quest'ultimo vede arrivarsi questi 2 byte, sa che la codifica è UTF8 e quindi li interpreta come il carattere à, ma PHP, che non fa distinzione, perché non ha il concetto di carattere ma solo di byte o insieme di byte (stringa) fa casini effettuando tagli ...

se tu metti una stringa "àbc" in UTF8 estratta dal database e gli dici di fare un strlen non restituirà 3 ma 4, perché la stringa è composta di 3 caratteri ma 4 byte (per via del primo carattere composto da 2 byte) ... se fai un substr($stringa, 1) tu vedrai come primo carattere uno strano risultato

ovviamente se prendi e dentro php stesso fai la prova funzionerà tutto perché la à viene scritta sul disco in formato latin1 (o iso-xxxx-1/15 o cp1250/cp1252 che sono più o meno uguali) e quindi, essendo mono byte, tu la vedrai tagliata correttamente

<?php

mysql_connect("localhost", "root", "");
mysql_select_db("test");
echo 'Codifica corrente: ' . mysql_client_encoding() . '
';
mysql_set_charset('utf8');
echo 'Nuova codifica: ' . mysql_client_encoding() . '
';
echo '
';

$query = mysql_query("SELECT stringa FROM test");

while($row = mysql_fetch_object($query))
{
    echo strlen($row->stringa) . ' - ' . $row->stringa . '
';
}

mysql_close();

?>

con questo codice d'esempio, dove dico di mantenere tutto in utf8 e di non convertire nulla quando arriva la roba a php esce fuori

Codifica corrente: latin1
Nuova codifica: utf8

10 - à èìòù
4 - Ã bc

ho dovuto forzare la cosa perché php, di default, setta il charset latin1 e quindi ti mangia della roba

PS: ovviamente la tabella test, in questo caso, deve avere la collation/charset su utf8

[daniele_dll]

Originariamente inviato da webus
Nel database ti direi di inserire i dati così come sono, assolutamente. Dopotutto non puoi dare per scontato a priori che li mostrerai sempre e solo attraverso un browser web.
Se hai problemi a visualizzarli con altri client è probabilmente perché la connessione o il driver di connessione usano un altra codifica. Non dimentichiamo che HTTP1.1 definisce ISO-8859-1 come codifica di default.

questo sarebbe possibile in una situazione "ideale", ma:
* se è in hosting e si ritrova a spostare il sito è un gran casino (parlo per esperienza)
* php, quando fa la connessione, cambia il charset su latin1 di conseguenza si va a mangiare un bel po di caratteri che nella situazione normale non vengono usati ma se si usa UTF8 è perché si vuol star tranquilli con le varie lingue
* cambiando la codifica con php, usando quindi l'utf8, succede un gran casino perché php non gestisce l'entità carattere (byte singolo/multi byte) ma solamente il byte di conseguenza vanno usate le apposite funzioni multibyte che non tutti gli hoster hanno

di conseguenza salvare in formato latin1 con le entità aggira tutto questo set di problemi ed inoltre, ammesso che non li visualizzi tramite browser, situazioni che non capitano ogni giorno, a convertire l'entità nel relativo carattere unicode/utf8 non ci vuole più di tanto

bland, se vuoi un mio consiglio personale, per la situazione ora come ora, conviene tenere TUTTO in formato latin1 e prima di inserire si applica un bel htmlentities e ti risolvi tutti i problemi di visualizzazione, codifica e taglio ... anche perché considera che è errato tagliare a priori il testo a N caratteri! di solito io faccio che certo lo spazio o un carattere di punteggiatura di fine frase più vicino al numero massimo di caratteri cosi da stare tranquillo di prendere tutta la parola per intera e di non tagliare nulla, comprese le entità html

[bland]

Buondì!

ho letto adesso il commento di webus e Daniene ... grz raga!
Beh da come posso capire possono esservi varie ragioni e le capisco.. da quello infatti deriva la mia perplessità....

Allo stato attuale, vuoi per l'hosting che si comporta come dovrebbe (TOPHOST), vuoi per mysql settato in UTF8 e le pagine idem.. sembra funzionare tutto.. senza errori ma l'ho provato solo con il mio computer, anche se con diversi browser (IE7, IE6, IE5, SAFARI, FIREFOX) .. ma voglio vedere che succede con un MAC e con altri PC... Lunedì vi dico...


MA ..... se dovessi veder qualcosa di strano, cambio tutto e buonanotte!
Eventualmente Daniele, devo riportare mysql in latin1 e latin1_general_ci, e converto tutti i caratteri semplicemente con htmlentities() e metto però le pagine in ISO-8859-1 .. ESATTO? :master:

[daniele_dll]

Originariamente inviato da bland
MA ..... se dovessi veder qualcosa di strano, cambio tutto e buonanotte!
Eventualmente Daniele, devo riportare mysql in latin1 e latin1_general_ci, e converto tutti i caratteri semplicemente con htmlentities() e metto però le pagine in ISO-8859-1 .. ESATTO? :master:

si

guarda, per vedere effettivamente cosa arriva al browser metti un semplice
echo 'Codifica corrente: ' . mysql_client_encoding() . '
';

dopo che effettui la connessione

Perché anche se i dati li hai in UTF8 nel database è la codifica utilizzata dal client che conta perché è lui che quando li legge li riceve per come dice (latin1 ad esempio) e di conseguenza non vai a buttar fuori utf8 ma latin1

per vedere cosa succede con il sito usando effettivamente UTF8 metti
mysql_set_charset('utf8');

prima o dopo la selezione del database

[whisher]

Originariamente inviato da daniele_dll

per vedere cosa succede con il sito usando effettivamente UTF8 metti


prima o dopo la selezione del database

Scusa un attimo ma allora se uso

mysql_set_charset('utf8'); 

prima di effettuare una query ho i dati inseriti/restituiti
da mysql in utf-8 ?

[daniele_dll]

si esatto, ma dipende anche dalla configurazione di php

[webus]

Originariamente inviato da daniele_dll
questo sarebbe possibile in una situazione "ideale", ma:
* se è in hosting e si ritrova a spostare il sito è un gran casino (parlo per esperienza)
* php, quando fa la connessione, cambia il charset su latin1 di conseguenza si va a mangiare un bel po di caratteri che nella situazione normale non vengono usati ma se si usa UTF8 è perché si vuol star tranquilli con le varie lingue
* cambiando la codifica con php, usando quindi l'utf8, succede un gran casino perché php non gestisce l'entità carattere (byte singolo/multi byte) ma solamente il byte di conseguenza vanno usate le apposite funzioni multibyte che non tutti gli hoster hanno

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.
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à.

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.