punto interrogativo (?)

[andr3a]

quindi le funzioni utf8_encode ed utf8_decode quando dovrebbero usarsi di preciso ?


altra domanda, qualora avessi un db in latin1 e volessi cambiare layout da ISO ad UTF-8, per mantenere lo stato dei dati testuali equivalente dovrei usare sempre utf8_encode prima di rilasciare l'output dal db e sempre utf8_decode prima di inserire input nel db, almeno questa l'ho detta giusta ?

in realtà io la penso un pò come daniele e non ho mai avuto problemi con utf8 ( se non con un'applicativo JS ) ma mi piacerebbe che ci fosse un pò di luce sulla questione, conosco anche io portali mediamente importanti che si ritrovano i punti di domanda sui caratteri male interpretati ... un pò come è per questo:

<?php
header("Content-type: text/html; charset=UTF-8");
echo "àèìòù";
?>

piuttosto che

<?php
header("Content-type: text/html; charset=UTF-8");
echo utf8_encode("àèìòù");
?>

[edit]
per i mods, non sarebbe meglio cambiare il titolo in uno più interessante e ricercabile ?
tipo
[UTF8] punto interrogativo e caratteri multi bytes

[daniele_dll]

in realtà non è sicuro ... io la prova non l'ho mai fatta e dipende ... xche può essere che cambiando la conversione lui aggiorni anche il contenuto

Uhm.. ma tu sei fissato con il browser eh?
Ma chi ti dice che lui inserisce i dati dal browser

ehm ... ... ... le uniche volte che capita che che non vengono inseriti dati provienienti da browser e quando si devono inserire dati tramite client testuale (nemmeno phpmyadmin perché basta dirgli di lavorare con utf8) e, sinceramente, mi è capitato di usare il client manuale soltanto per lavorare con i dump e basta sinceramente

inoltre credo che mysql esegua la conversione dei dati quando si inviano/ricevono (ovviamente dipende dal tipo del campo) dati dato che è possibile impostare sia il tipo di codifica usata per la connessione sia il tipo di codifica usata nella tabella

[skidx]

Originariamente inviato da daniele_dll
水 -> & #x6C34 ;

questo è un carattere cinese, utilizza 2 byte

I caratteri cinesi in utf-8 richiedono 3 byte, così come tutti quelli dei paesi dall'India in poi (andando verso est).

andrea, i siti nei quali vedi in giro i punti di domanda non è detto che sbaglino codifica, può essere infatti che il font utilizzato non abbia la rappresentazione per quel particolare carattere.

Ad esempio, se provi ad aprire un sito giapponese senza il supporto per le lingue orientali correttamente installato avrai una pagina di punti di domanda, anche se il sito ha fatto tutto correttamente.

Altra causa comune di errore sono le costanti stringa scritte direttamente nei sorgenti, laddove ci si dimentica di settare anche il sorgente stesso con codifica utf-8 (utilizzando editor che consentano di farlo).

[daniele_dll]

Originariamente inviato da skidx
I caratteri cinesi in utf-8 richiedono 3 byte, così come tutti quelli dei paesi dall'India in poi (andando verso est).

io ho usato 2 byte per definire quei caratteri

水 -> & # x 6C 34 ;

6C e 43 e la coppia di byte utilizzati per rappresentare il simbolo ... ovviamente sono rappresentati in codici esadecimali

[skidx]

Originariamente inviato da daniele_dll
io ho usato 2 byte per definire quei caratteri

水 -> & # x 6C 34 ;

6C e 43 e la coppia di byte utilizzati per rappresentare il simbolo ... ovviamente sono rappresentati in codici esadecimali

Non devi confondere il codice unicode che usi per identificarlo con la rappresentazione effettiva in utf-8.

Quel codice che tu hai scritto viene rappresentato su 3 byte in utf-8, perché nel primo byte sono presenti le informazioni sulla lunghezza del carattere.

[andr3a]

anche perchè se non erro utf-8 arriva fino a 4 bytes per carattere, giusto ?
( ditemi di si o mi sparo )



skidx, non parlavo di siti giappotti ovviamente ... ma di siti anche italiani, dove se metti un commento o leggi dei testi ogni tanto scappa fuori il ? ...


ma a questo punto, per evitare problemi, non converrebbe lavorare sempre in UTF-8 ?

passa la paura, o no ?

[skidx]

Originariamente inviato da andr3a
anche perchè se non erro utf-8 arriva fino a 4 bytes per carattere, giusto ?
( ditemi di si o mi sparo )

esatto, ma 4 nella pratica non li troverai praticamente mai perché su 4 byte rappresenta solo i "piani astrali". Comunque è corretto dire che va da 1 a 4 byte.

skidx, non parlavo di siti giappotti ovviamente ... ma di siti anche italiani, dove se metti un commento o leggi dei testi ogni tanto scappa fuori il ? ...

Boh, allora si vede che avranno fatto cagate

ma a questo punto, per evitare problemi, non converrebbe lavorare sempre in UTF-8 ?
passa la paura, o no ?

Sì, certo, se solo il PHP lo supportasse nativamente e gli hoster installassero MySQL in versione 4.1 o superiore e charset impostato a utf-8

Il problema del supporto del PHP lo hai nel momento in cui devi smandruppare sulle stringhe. Buona parte delle funzioni native non funzionano sui multibyte, quindi senza mb_string devi usare funzioni scritte in php che quindi rallentano e complicano il tutto.

Il mancato supporto su MySQL crea problemi più che altro in fase di ricerca e ordinamento.

Per il resto, per il classico leggi/scrivi dal database non c'è alcun problema, quindi in linea di massima secondo me, sul web, utf-8 è la scelta migliore.

[andr3a]

Originariamente inviato da skidx
esatto, ma 4 nella pratica non li troverai praticamente mai perché su 4 byte rappresenta solo i "piani astrali"

:master:



& # x FF FF ; ... l'orsa maggiore

[skidx]

Originariamente inviato da andr3a



:master:

& # x FF FF ; ... l'orsa maggiore

non astrali in quel senso

Sono chiamati così in maniera scherzosa... sono i piani che rappresentano caratteri rari e spesso non più usati, tipo, chessò, i vecchi caratteri italici o i simboli musicali bizantini.

[daniele_dll]

Originariamente inviato da skidx
Non devi confondere il codice unicode che usi per identificarlo con la rappresentazione effettiva in utf-8.

Quel codice che tu hai scritto viene rappresentato su 3 byte in utf-8, perché nel primo byte sono presenti le informazioni sulla lunghezza del carattere.

pardon, dopo il tuo post ho approfondito un po la cosa ^^

però non tutto vien per nuocere ... se impostassi il file con codifica UTF-16, che è quasi totalmente compatibile con ucs-2, posso visualizzare quel carattere utilizzando solo 2 byte

---

cmq, tornando al discorso principale, le entità html eventualmente possono correre in soccorso anche se io comunque rimango del parere che:
- inviando dati in UTF8
- ricevendo dati in UTF8
- impostando le tabelle e la connessione in UTF8

il 90% delle problematiche multi-lingua si aggirano

se poi ci aggiungiamo che possiamo utilizzare pure le mb_string e impostare l'internal_encoding su utf8 ... tutto verrebbe gestito in utf8 in maniera totalmente trasparente