[MYSQL 4.0.x - MYSQL 5.x] Migrazione latin1 - utf8. Problema di conversione caratteri

[Gil Mour]

Rieccomi qua a scontrarmi con un problema che mi era già capitato un paio di anni fa.

In sintesi, devo migrare un intero db da mysql 4.0 a mysql 5.x. Ora, il problema è che mysql 4.0 non supportava utf8 e tutti i campi contenenti caratteri (varchar, char, text, etc) avevano una codifica iso-8859-1 (volgarmente detta latin1).

Il problema è molto diffuso, nel senso che in rete c'è molta documentazione e molti articoli che ne parlano, nessuno dei quali però mi ha risolto il problema. Sto quindi cercando la mia strada verso la luce.

Vediamo un attimo cosa mi succede, ed i passi che sto seguendo per effettuare questa procedura.

PASSO 1
Esporto il database con mysqldump in formato latin1

mysqldump -u user -p --default-character-set=latin1 database tabella > /path/to/dump/dump.sql

PASSO 2
Apro il dump con un editor di testo (PSPAD) e controllo che formato ha il file.
Sembra avere davvero la codifica con cui lo ho esportato: supponiamo che il dump sia composto da questa linea.

insert into tab values ('La vita è una cosa meravigliòsa');

Editandolo in modalità esadecimale vedo che effettivamente i caratteri sembrano codificati correttamente, in particolare: la "è" è codificata dal byte E8, la "ò" dal byte F2.

PASSO 3
Converto il dump utilizzando iconv.

iconv -f latin1 -t UTF-8 /path/to/dump/dump.sql > /path/to/dump/dump.utf8.sql

PASSO 4
Come al passo due, do una controllata alla codifica del file. La conversione sembra avvenuta
correttamente, in particolare il carattere "è" è codificato come 0xE8.

PASSO 5
Importo il dump in mysql5, che utilizza come codifica default per *tutto* (client, connessione, db, etc) utf8.

mysql -u root -p localhost database_nuovo  < /path/to/dump/dump.utf8.sql

PASSO 6
Verifico. Apro il browser e lancio l'applicazione. I caratteri incriminati (in questo caso "è" e "ò") sono visualizzati rispettivamente come Atilde e qualcosaltro che non mi ricordo piu.



Vado a controllare le tabelle di codifica utf8 (http://kellyjones.netfirms.com/webto...f8_table.shtml) e mi accorgo che c'è qualcosa di importante che mi sfugge:

Il carattere "è" ha una codifica esadecimale che è 0xE8, mentre la codifica UTF8 è 0xC3,0xA8. Continuo a cercare e scopro che la fottuta Atilde ( Ã ) che mi rimpiazza le "è" guarda caso ha una codifica binaria di 0xC3 e 0xC3,0x83 in UTF8.
Questo sembra dimostrare palesemente che al momento dell'import mysql ha fatto una conversione trasformando il mio 0XE8 in un bel 0xC3 (questo è solo l'esempio della "è", la cosa avviene praticamente per tutto ciò che non è alfanumerico o segno di interpunzione principale).

Prima domanda: che conversione fa mysql?

Seconda domanda: ma che cavolo vuol dire che la codifica della "è" utf8 è 0xC3,0xA8!? Voglio dire, in memoria che diavolo c'è scritto: E8 o C3?

[piero.mac]

Non so se rispondo a quanto chiedi, ma ti posso dire come ho fatto con successo su almeno tre server.

Porto tutti i dati aggiornati come struttura e con il loro charset alla versione 5.1 di mysql.
Eseguo il backup (singolarmente per prudenza) dei database in latin1.
Apro il file .sql con un editor come PSPAD e verifico che la formattazione riconosciuta sia ANSI.

sostituisco con il replace tutte le ricorrenze latin1 con utf8, tutte le collation con le loro corrispondenti utf8. Salvo il file come database_utf8.sql

Rinomino sempre per prudenza il database in nome_latin1.
Creo un nuovo database (utf8) con lo stesso nome del precedente e ricarico il backup_utf8.

Aggiorno nell'header html (meta) il charset in 'UTF-8' e faccio le mie prove. Di solito e' finita li, tutto OK.

Per il dump/restore utilizzo le ultime versioni di phpmyadmin e/o mysql administrator. Non utilizzo l'eseguibile di mysql. Eseguo backup e restore sempre tramite le stesse versioni apache/php/mysql.

Poi dai un lungo sguardo a mbstring

http://it.php.net/manual/en/mbstring.configuration.php