inserimento sul DB - ma chi esegue la codifica?

[markzzz]

salve. non ho mai capito bene questa cosa :

ho la mia pagina index, e nell'head ho il mio :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

ora, in fondo alla pagina ho un form. inserisco delle stringhe nel form e le invio;
queste arrivano lato server, faccio i miei controlli (es. mysql_real_escape_string) e poi le inserisco nel database (che per i dati in questione, nel mio caso, anche se può sembrare stupido, è latin1, con collation latin1_general_ci).

ora, quando vado a pescare queste stringhe e le stampo a video, effettivamente noto che è stata applicata la codifica utf-8, perchè vengono stampate in maniera corretta.

quindi, chi diavolo è stato a fare la conversione? il browser riconosce la codifica tramite il tag <meta>, ma fà anche la conversione (in uscita) grazie a questo tag? o chi è che lo fà?

mi ha sempre lasciato perplesso...

saluti

[bubi1]

qui ci sono tutte le risposte che cerchi: http://dev.mysql.com/doc/refman/5.1/...onnection.html

sintetizzando: oltre alla codifica client (tuo browser) e codifica server (mysql), subentra anche la codifica della connessione tra di loro.

[markzzz]

ho letto la guida...però non mi è molto chiara

allora :

1 - io quando faccio la connessione (intendo la connessione tra il "client lato server" al "server lato server") non stabilisco mai il tipo di codifica;
2 - se inserisco del testo da un form (client lato client), lo spedisco, lo inserisco nel DB, risulta essere codificato effettivamente in utf-8. se lato server importo del testo da un tx, e lo inserisco nel DB, non risulta essere codificato in utf-8, cosa che dovrebbe fare vista la connessione (che è la medesima). infatti prima di un operazione del genere (cioè prima di un inserimento con testo preso da txt lato server) avviene l'effettiva conversione se filtro le mie var con la funzione utf8_encode().
3 - la codifica "browser" dovrebbe (spero) avvenire solo all'atto della visualizzazione della pagina all'utente e basta; se invio dei dati tramite browser (es. con un form) non dovrebbe codificarli all'invio... (anche perchè altrimenti non potrei gestire le varie possibile codifiche dei vari possibili browser dei vari possibili utenti).

[bubi1]

Originariamente inviato da markzzz
ho letto la guida...però non mi è molto chiara

allora :

1 - io quando faccio la connessione (intendo la connessione tra il "client lato server" al "server lato server") non stabilisco mai il tipo di codifica;

Che tu la stabilisca o meno, le variabili character_set_connection/character_set_client esistono comunque e influenzano il trasporto dei dati tra php e mysql. Se non le specifichi, vengono semplicemente utilizzati i valori di default.

2 - se inserisco del testo da un form (client lato client), lo spedisco, lo inserisco nel DB, risulta essere codificato effettivamente in utf-8. se lato server importo del testo da un tx, e lo inserisco nel DB, non risulta essere codificato in utf-8, cosa che dovrebbe fare vista la connessione (che è la medesima). infatti prima di un operazione del genere (cioè prima di un inserimento con testo preso da txt lato server) avviene l'effettiva conversione se filtro le mie var con la funzione utf8_encode().

Significa che il tuo txt non e' in utf8, tutto qui

3 - la codifica "browser" dovrebbe (spero) avvenire solo all'atto della visualizzazione della pagina all'utente e basta; se invio dei dati tramite browser (es. con un form) non dovrebbe codificarli all'invio... (anche perchè altrimenti non potrei gestire le varie possibile codifiche dei vari possibili browser dei vari possibili utenti).

Il browser non codifica nulla, se non prendiamo in considerazione il fatto che i normali input nei form con action post e enctype non multipart vengono url-encoded-ificati, cosa che pero' e' normalmente trasparente per te.
Il browser ti invia i dati esattamente nella codifica in cui l'utente vede la pagina. Per intenderci: se uno guarda la pagina nella codifica cinese, ti inviera i caratteri big5, se invece lo guarda nella utf8 te li inviera' in utf8.
Comunque sei tu che imposti la codifica con cui l'utente vede la pagina. Se uno forza un altra codifica - beh, se per te questo e' un problema, dovresti controllare che la codifica dei dati in arrivo corrisponda a quella che ti aspetti, ad esempio con mb_check_encoding o roba simile.

[markzzz]

Originariamente inviato da bubi1
Il browser ti invia i dati esattamente nella codifica in cui l'utente vede la pagina. Per intenderci: se uno guarda la pagina nella codifica cinese, ti inviera i caratteri big5, se invece lo guarda nella utf8 te li inviera' in utf8.

ah ecco!!! allora è il browser che fà la codifica delle stringhe "nuove" che l'utente per esempio inserisce e poi invia.

ma questa codifica è in base a come è impostato il browser (dai parametri che un utente setta sul proprio browser, che non ho idea se si possano settare) o si adagia/adatta (spero) in base al charset impostato nel tag <meta> ?

[bubi1]

Si, il browser obbedisce al charset meta (ci sono casi quando non lo fa, dipende dalla configurazione del server, ma e' una situazione particolare).

L'utente puo' forzare un altra codifica, andando su visualizza->codifica caratteri->qualsiasi altra (e' il percorso firefox, ma ogni browser ha questa funzionalita').

[markzzz]

uhm...questo è interessante. quindi affidarsi al semplice <meta> non è sufficente.

nel senso : se io mi aspetto dei soli dati in utf8 e l'utente cambia la codifica, arrivano dei dati che non sono utf8, e questo potrebbe essere un problema. quindi (come dici te) poteri verificare il tipo di codifica, e se non fosse utf8, convertirlo in utf8;

però quì vorrei sottolineare un altra cosa :

supponiamo che un utente abbia codifica big5, faccio il controllo, e codifico in utf8. in realtà faccio una codifica a una codifica. quindi poi i dati saranno big5 o utf8? nel senso...se applico un altra codifica la codifica precendente viene annullata o ho una doppia codifica? perchè se è come nel secondo caso ...potrebbe esserci un problema nella visualizzazione dei contenuti...

[bubi1]

Non bisogna cadere nella paranoia pero'. Forzare la codepage e' un azione voluta, non casuale

Ad esempio io sono un utente cazzone, adesso mando i seguenti caratteri cirillici:

абвгд

e li mando utf-8 forzando la codifica della pagina:

il server invece si aspetta una codifica iso-8859-1, quindi trattera' questi caratteri come bytes di questa codepage, non del cirillico, di conseguenza tu sotto vedrai caratteri strani al posto del cirillico:

абвгд

E che cosa ci guadagno? nulla. Non mi aiuta per nessun tipo di attacco.

Quindi dipende tutto dalla tua applicazione reale:
- Hai un applicazione in iso-8859-1, che si collega al db con un charset latin1, e salva i dati in un campo latin1, e i dati ti arrivano in utf8? Avrai un bel errore mysql, e gli errori mysql dovresti comunque gestire, indipendentemente dal motivo.
- Stai scrivendo un guestbook/forum ? Beh, avrai sicuramente una moderazione, e cancellerai i messaggi strani, se sono un problema.
- Stai facendo un sito di cui contenuti provengono dal backend? Si suppone che l'admin del sito non faccia il cazzone.
- Si tratta di un form contatti che manda i dati via mail? Potrebbe essere un problema, ma potrebbe anche non esserlo - in fondo se uno ti manda dati strani, li ignori.

Quindi non c'e' da preoccuparsi troppo di questo aspetto.

PS: per voler essere pignoli, esistevano una volta degli attacchi xss basati sulle vulnerabilita' presenti nei charset, ma da quello che so i browser si sono adeguati da un bel po'.

PPS: no, non esistono doppie codifiche, e se hai pensato a questo, significa che hai le idee un po' confuse su cosa sia una codifica

[markzzz]

Originariamente inviato da bubi1
Non bisogna cadere nella paranoia pero'. Forzare la codepage e' un azione voluta, non casuale

Ad esempio io sono un utente cazzone, adesso mando i seguenti caratteri cirillici:

абвгд

e li mando utf-8 forzando la codifica della pagina:

il server invece si aspetta una codifica iso-8859-1, quindi trattera' questi caratteri come bytes di questa codepage, non del cirillico, di conseguenza tu sotto vedrai caratteri strani al posto del cirillico:

абвгд

E che cosa ci guadagno? nulla. Non mi aiuta per nessun tipo di attacco.

sei stato chiarissimo

Originariamente inviato da bubi1
Quindi dipende tutto dalla tua applicazione reale:
- Hai un applicazione in iso-8859-1, che si collega al db con un charset latin1, e salva i dati in un campo latin1, e i dati ti arrivano in utf8? Avrai un bel errore mysql, e gli errori mysql dovresti comunque gestire, indipendentemente dal motivo.

quì però c'è una cosa che non capisco. nel mio meta io ho un charset utf8. quindi la mia applicazione (tranne eventuali modifiche da parte dell'utente nel browser) lavora con utf-8. nel mio db i miei dati sono (non chiedermi il perchè, devo documentarmi anche su questo) salvati in latin1; eppure non ho nessun tipo di errore mysql

Originariamente inviato da bubi1
PPS: no, non esistono doppie codifiche, e se hai pensato a questo, significa che hai le idee un po' confuse su cosa sia una codifica

già non capisco bene come viene gestita questa cosa; ci vorrebbe qualche buona guida o un buon libro...

[bubi1]

Originariamente inviato da markzzz
quì però c'è una cosa che non capisco. nel mio meta io ho un charset utf8. quindi la mia applicazione (tranne eventuali modifiche da parte dell'utente nel browser) lavora con utf-8. nel mio db i miei dati sono (non chiedermi il perchè, devo documentarmi anche su questo) salvati in latin1; eppure non ho nessun tipo di errore mysql

Ripeto: dipende dalla codifica della connessione.

Provo a spiegarti tecnicamente cosa succede al livello basso, pero' mi sa che effettivamente ti dovresti leggere qualche bel manuale/guida per capire tutto il discorso.

La codifica utf8 e' multibyte, e usa da 1 a 4 byte per rappresentare un carattere.
La codifica latin1 e' single-byte, usa uno solo byte per rappresentare un carattere.

La tabella utf8 ha come inizio la tabella us-ascii, quindi i caratteri normali (A-Za-z..) coincidono in entrambe le codifiche, quindi concentriamoci sui caratteri particolari.

Prendiamo il carattere "è". Nella tabella utf8 questo carattere e' costituito da 2 bytes "c3" e "a8". Per chiarezza uso la rappresentazione esadecimale, in quella decimale sarebbe 195 168.

Lo stesso carattere "è" nella tabella latin1 e' rappresentato dal byte e8.

Adesso, a te arriva questo carattere da una pagina utf8. Quindi il php riceve c3a8.
Php si collega al mysql. Il charset di questa connessione e' latin1. Come ti ho gia' detto, il charset della connessione e' molto importante, perche' dice al server mysql come interpretare i dati in ingresso. Non codifica un bel niente, fa solo quello.
Quindi dicevo, essendo la codifica in latin1, mysql vedendo c3a8 non li interpreta come un singolo carattere utf8, ma come 2 caratteri latin1! (questo e' il punto piu' importante di tutto il discorso)
Di conseguenza mysql inserice nel tuo campo latin1 DUE caratteri latin1. c3 nella latin1 corrisponde a "Ã", mentre a8 corrisponde a "¨".
Quindi mysql inserisce nel campo questa stringa: "è" . E li accetta senza problemi, sono entrambi caratteri che sono inclusi nella tabella latin1.

Poi indietro.

Tu vuoi leggere questo dato. Php si collega al mysql. Mysql legge il campo, e manda di nuovo al php 2 caratteri, "Ã" e "¨" (ricordi, e' dovuto alla codifica della connessione).
Php riceve è, con altre parole riceve i due bytes c3a8 e li manda al browser.
Il browser e' in utf8(dovuto al meta o al header content-type), quindi interpreta i due caratteri NON come 2 caratteri latin1 ma come UN carattere utf8, che ridiventa indietro è.

Ecco

Se hai capito qualcosa, a questo punto dovresti realizzare che in realta' non c'e' nessuna conversione a nessun livello, e' tutto un discorso su come le varie parti interpretano la seguenza di bytes.

Se invece il charset della connessione fosse stato correttamente impostato a utf8, mysql s'incazzerebbe. Perche' interpreterebbe c3a8 come un singolo carattere multibyte, e non potrebbe inserirlo nella tabella latin1, fallendo con un messaggio di errore out of range.

In conclusione: per non creare overhead inutili e paradossi poco chiari come sopra, devi avere la pagina, la connessione e la colonna mysql tutti nella stessa codifica.

Ps: lo so che non ti e' ancora tutto chiaro, ma e' impossibile spiegare tutta la teoria dei codepage in un unico post