dubbi utf-8

[serialkiller]

Dunque, mi sono appena letto circa 100 post del forum che parlano di utf-8 e mi sono venuti 100 dubbi c'è scritto tutto e il contrario di tutto.

Ora, senza rimandarmi ai soliti link che ho già letto, mi piacerebbe chiarirmi le idee in maniera definitiva.

Vediamo se riesco a scrivere un po' tutto....

Le parti che sono fondamentali sono:

- Collation tabella e campi in utf8_general_ci

- Settare il charset su utf-8 nel meta o meglio lato server con:

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

Questo nelle pagine del sito sia nella parte di amministrazione (CMS) in modo che i vari dati passati dai form vengano gestiti appunto in utf-8


Poi iniziano alcuni dubbi, questo perchè leggendo alcuni post, invece di chiarirmi alcune lacune mi si sono incasinate ancora di più.

Non ho mai avuto grossi problemi, ma ora vorrei appunto chiarire questi dubbi.

1) E' necessario mettere subito dobo la selezione del DB la query:

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

?

2) Come gestire i dati nel db? Inserirli nudi e crudi o codificarli per es. con htmlentities?

C'è chi dice di lasciarli nudi e crudi per lasciare puliti i dati inseriti, chi invece dice di convertirli con htmlentities o seplicemente:

htmlentities($testo); 

o

htmlentities($testo,ENT_QUOTES,'UTF-8'); 

Cedo che la seconda sia la più corretta.

A questo punto se li abbiamo codificati con htmlentities in output non dovremmo riconvertirli, altrimenti a che serve?
Quindi in output la frase "pluto è un cane" diventerà: "pluto & egrave; un cane".
Dovremmo riconvertirli con html_entity_decode se andiamo a modificarne il valore tramite CMS in un form.

3) Utilizzando il charset utf-8 o più in generale è meglio usare: mysql_real_escape_string o addslashes per gli escape?

4) Ciò considerato, dovendo magari gestire rss o pdf generati per es. da FPDF (che se non ricordo male non supporta utf-8) come è meglio agire senza complicarsi la vita?

5) Sempre tenendo conto di quanto detto, dovendo gestire un sito in più lingue, se codifico i testi con htmlentities posso avere problemi di sorta?

Vedimo se si riesce a fare una bella discussione e trarne alla fine una conclusione definitiva, perchè io di post ne ho letti un centinaio, ma la lista continuava, quindi sembra essere un problema o un dubbio di molti.

Grazie

[Ht28]

Ti spiego: UTF-8 lo puoi usare ma al posto dei caratteri speciali dovrai inserire i relativi codici, qui trovi la lista http://riemann.unica.it/studenti/guida/caratteri.html

perciò se nel tuo sito devi scrivere "però" se usu UTF-8 dovrai scrivere "per& ograve;" in questo modo sei sicuro che anche es. in Giappone vedono la parola "però" se invece usi charset=iso-8859-1 vedrebbero "per+un quadratino bianco".

Se il tuo sito è visto principalmente qui in occidente ti conviene usare charset=iso-8859-1 così non devi sempre tenere sottocchio la lista dei caratteri speciali

[serialkiller]

Originariamente inviato da Ht28
Ti spiego: UTF-8 lo puoi usare ma al posto dei caratteri speciali dovrai inserire i relativi codici, qui trovi la lista http://riemann.unica.it/studenti/guida/caratteri.html

perciò se nel tuo sito devi scrivere "però" se usu UTF-8 dovrai scrivere "per& ograve;" in questo modo sei sicuro che anche es. in Giappone vedono la parola "però" se invece usi charset=iso-8859-1 vedrebbero "per+un quadratino bianco".

Se il tuo sito è visto principalmente qui in occidente ti conviene usare charset=iso-8859-1 così non devi sempre tenere sottocchio la lista dei caratteri speciali

Secondo me stai sbagliano, o ti sei spiegato male o non ho mai capito niente io fino ad ora.

utf-8 e iso-8859-1 sono semplicemente due tipi di codifica dei caratteri.
Le entità come "& ograve;" non centrano niente e servono appunto per rappresentare caratteri speciali o non compresi in questa o quella codifica.
Le entità comunque hanno il loro limiti ovvero non esistono entità per qualsiasi carattere e comunque le entità (rimanendo nei due casi utf-8 e iso-8859-1), vengono servite ed interpretate correttamente con entrambe le codifiche in quetione.
Semmai è proprio il contrario iso-8859-1 non ha nel suo set tutta una serie di caratteri e per poterli rendere devi ricorrere alle entità, diversamente utf-8 ne racchiude a migliaia quindi anche se scrivi in cirillico, japponese o cinese a video li vedaria correttamente a patto che tu li inserisca tramite un form in utf-8, quindi con una pagina servita come utf-8, il form prenderà la medesma codifica della pagina, che il tuo DB abbia collation della tabella e dei campi utf-8 e che la connessione con Mysql sia in utf-8, insomma deve essere tutto in utf-8.
Così facendo puoi tranquillamente salvare nel DB la tua stringa senza nessuna entità perchè utf-8 riesce a rappresentare praticamente tutto, non per neinte è consigliato soprattutto per siti in più lingue (es. vedi wikipedia).
Poi anche in utf-8 se vuoi puoi usare le entità, e questo è uno degli elementi di questo post...a cosa serve usare le entità se utf-8 non ne ha bisogno?
Faccio un altro esempio: se provi a scrivere in Word, magari inserisci anche qualche simbolo particolare, poi inseriscilo nel DB da form con un bel copia e incolla, servi tutto come iso-8859-1 e dimmi cosa vedi, poi fai la medesima cosa ma in utf-8 (seguendo tutti i punti sopra descritti) e dimmi cosa vedi? Quale delle due pagine si vede correttamente ed è perfettamente valida anche agli occhi del validatore senza nessun warning o errore di charset e relativa codifica?
Detto questo, quello che chiedevo è: leggendo si trovano pareri contrastanti, come per esempio il tuo che diverge dal mio, e non essendo io supponente e tantomeno non avendo la scienza infusa mi sono trovato, cercando una cosa sul forum, difronte a queste incongruenze ripetute in più post, mi sono quindi posto il dubbio...ho effettivamente sempre fatto le cose correttamente?
Per esempio per me è abbastanza strano inserire stringhe utf-8 in un DB con collation utf-8 e tutto il resto come entità, fare conversioni su conversioni per me è inutilè, ha senso se ho il sito in iso-8859-1 dove certi caratteri non riesco a renderli correttamente e sono obbligato ad usare le entità.
Poi ci sono e potrebbero esserci altri problemi ed infatti son qui a chieder lumi proprio perchè se fin ora ho sbagliato, vorrei correggermi e capire.

[Ht28]

Puoi fare tu stesso una prova con un tuo file, nel DOCTYPE sostituisci iso-8859-1 con UTF-8 e visualizza la pagina...e fammi sapere

[daniele_dll]

Ma in realtà conviene tenere il tutto in UTF-8 perché con estrema semplicità puoi rappresentare vari tipi di caratteri (ad esempio i caratteri speciali di microsoft office word, ergo gli apici singoli/doppi, i maggiori/minoti e cosi via)

Il problema è che in PHP è un pò un dramma gestire le stringhe in formato UTF-8 perché le sue funzioni non supportano correttamente le codifiche. Diciamo che il concetto di carattere è stato parzialmente introdotto da poco e con php 6 (anche se io ho i miei dubbi) sarà supportato a pieno.

Il concetto di carattere e di byte, lo supportano quasi tutti i linguaggi, solo che php lo supporta a metà e quindi si rischia di fare una strage :\

[serialkiller]

Originariamente inviato da Ht28
Puoi fare tu stesso una prova con un tuo file, nel DOCTYPE sostituisci iso-8859-1 con UTF-8 e visualizza la pagina...e fammi sapere

Falla pure tu la prova, io le ho gia fatte mille volte e a tempo debito, non basta cambiare il charset.
Se il DB è in Latin1 o come meglio credi piuttosto che utf-8 comprese le tabelle e la connessione a Mysql, vedrai sempre i quadratini e quant'altro, e secondo me i millemila post che ci sono su questo forum derivano proprio da questo, si pensa basta cambiare il charset per passare da iso-8859-1 a utf-8 ed è sbagliato, se tu salvi dati utf-8 su DB in Latin1 non salvi in utf-8, Mysql non controlla cosa passi, sei tu che devi essere sicuro di cosa salvi e in che modo.
E' com dire, meto la collation del DB su utf8_lithuanian_ci et voilà ho il sito in Lituano.

[Ht28]

Originariamente inviato da serialkiller
Falla pure tu la prova, io le ho gia fatte mille volte e a tempo debito, non basta cambiare il charset.
Se il DB è in Latin1 o come meglio credi piuttosto che utf-8 comprese le tabelle e la connessione a Mysql, vedrai sempre i quadratini e quant'altro, e secondo me i millemila post che ci sono su questo forum derivano proprio da questo, si pensa basta cambiare il charset per passare da iso-8859-1 a utf-8 ed è sbagliato, se tu salvi dati utf-8 su DB in Latin1 non salvi in utf-8, Mysql non controlla cosa passi, sei tu che devi essere sicuro di cosa salvi e in che modo.
E' com dire, meto la collation del DB su utf8_lithuanian_ci et voilà ho il sito in Lituano.

Io la prova l'ho fatta, probabilmente hai qualche codice in conflitto.
La prova falla con un file semplice senza db.

[serialkiller]

Originariamente inviato da daniele_dll
Ma in realtà conviene tenere il tutto in UTF-8 perché con estrema semplicità puoi rappresentare vari tipi di caratteri (ad esempio i caratteri speciali di microsoft office word, ergo gli apici singoli/doppi, i maggiori/minoti e cosi via)

Il problema è che in PHP è un pò un dramma gestire le stringhe in formato UTF-8 perché le sue funzioni non supportano correttamente le codifiche. Diciamo che il concetto di carattere è stato parzialmente introdotto da poco e con php 6 (anche se io ho i miei dubbi) sarà supportato a pieno.

Il concetto di carattere e di byte, lo supportano quasi tutti i linguaggi, solo che php lo supporta a metà e quindi si rischia di fare una strage :\

Quindi ho sempre lavorato correttamente? Ovvero ho sempre tenuto sul DB le stringhe esattamente come vengono inserite, per es. in un modulo di iscrizione o qual si voglia altra funzione, se arrivasse un utente russo piuttosto che cinese, lascio la possibilità di scrivere il suo nome correttamente e lo salvo di conseguenza tale e quale senza nessuna entità, che nel caso del cinese non credo esista un entità per ogni idiogramma

Vorrei approfondire il problema della gestione delle stringhe, dove si potrebbero incontrare problemi? Intendi funzioni tipo "substr"?

[serialkiller]

Originariamente inviato da Ht28
Io la prova l'ho fatta, probabilmente hai qualche codice in conflitto.
La prova falla con un file semplice senza db.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Test</title>
</head>

<body>




però àèéìòù ç § % ת β Ŧ ﻱ ☺ ۩ ۞
</p>

</body>
</html>

Vai in edit per sicurezza, copia il codice e lancia la pagina, vedi quadratini o simboli stani?
Poi cambia il charset in iso-8859-1 e dimmi cosa vedi.

[daniele_dll]

Beh, si, se usi substr per tagliare e prendi il primo byte di un carattere che ne ha due lo tagli, cosi come se usi strtoupper, strtolower, ucwords, ucfirst e compagnia bella ... possono succedere drammi e distruzioni di vario genere!

La codifica UTF-8 funziona che se N bit stanno impostati su 1 in un dato byte vuol dire che il successivo fa parte dello stesso carattere, ma con funzioni come strtoupper, strtolower e simili, che alterano il byte, ovviamente succede un gran casino perché quei N bit che vengono cercati non ci stanno più e non funziona più nulla.

Dai un occhio qua
http://www.nicknettleton.com/zine/ph...f-8-cheatsheet (consigli e suggerimenti per usare utf-8)
http://www.joelonsoftware.com/articles/Unicode.html (ti spiega come funzionano le codifiche unicode e simili, ergo utf8, utf16, utf32)
http://www.sitepoint.com/blogs/2006/...hp-utf-8-tips/
http://www.sitepoint.com/blogs/2006/...-guide-slides/
http://www.sitepoint.com/blogs/2006/...hp-utf-8-tips/

In realtà scriversi un set di funzioni che badi a queste informazioni è molto semplice perché se un dato carattere utilizza più byte si c'è ne accorge confrontando il singolo byte con uno preimpostato. Ad esempio il primo byte nel caso di 2 byte per carattere è una a accentata, se la si trova vuol dire che il carattere non può essere trattato normalmnete.

Ci sono alcune librerie, FOLLI, che per fare queste operazioni convertono le stringhe in degli array, ma potete immaginare il carico portato da ciò (cosa non indifferente)!!!

Se non potete usare le mb* vi conviene cercare qualche libreria o usare dei semplici trucchetti per evitare problemi Ad esempio, personalmente, quando devo tagliare il testo per evitare che superi una data lunghezza lo taglio a parole, cosa che non causa problemi con l'utf8, cosi come se devo rendere tutto minuscolo un testo non lo uso poi per gli inserimenti o visualizzazioni e nel caso di ucwords e ucfirst li uso di rado ed in genere su singole parole che non contengono caratteri utf8 ... certo ... è pericoloso perché se a qualcuno viene il firticchio il carattere si corrompe, ma per quello che mi serve con questi giochini semplici mi evito problemi.

Mi sto scribacchiando una libreria per gestire le stringhe utf8 in modo umano, ma in realtà ne esistono di già pronte!
http://sourceforge.net/project/showf...roup_id=142846
http://cow.neondragon.net/index.php/660-Php-Utf8