Mi è capitata tra le mani una vecchia webapp che avevo scritto in PHP e che usava un database PostgreSQL.
Curioso di verificare se funzionasse ancora e, lo confesso, nostalgico dei vecchi tempi ho provato ad installarla sulla mia Linux Box.
Ok, decomprimiamo, creiamo un host su apache, si.. ok, è attivo.
Bene procediamo a caricare un vecchio dump del database dell’applicazione in esame.
Opsss … sembra che il database usi la codifica SQL_ASCII, shit!
Vabbè… proviamo creando un database con tale codifica e procediamo:
createdb <nome_database> -E SQL_ASCII -T template0
Fatto, carichiamo il database.. ok, fatto.
Bene adesso vediamo se la mia vecchia webapp funziona ancora dovere!
…
…
Dopo ore di improperi, eresie e bestemmie, combattendo con codice scritto su PHP 4, riesco a farla funzionare: soddisfazione!
Domanda: e se dovessi aggiornare la webapp per far si che funzioni ad oggi e per gli anni a venire?
Beh… a livello PHP, conviene riscrivere tutto! Usando un moderno framework si otterrebbe sicuramente un risultato migliore e si risparmierebbe molto tempo.
Ok e col database come facciamo? Beh si potrebbe convertirlo a UTF-8… mai provato, facciamolo!
Parto con una prova che so già non funzionerà: carico direttamente il dump con encoding SQL-ASCII su un database creato in UTF-8.
Come supponevo già in fase di caricamento sorgono i primi errori:
ERROR: invalid byte sequence for encoding "UTF8": 0xe96365"
Ok, prevedibile! meglio convertire il dump in UTF-8 prima di caricarlo!
Beh potrei provare a creare un dump in UTF-8 del database già caricato per poi ricaricarlo su un database UTF-8.
Creiamo il dump:
pg_dump --encoding utf8 <nome_database> -f <nome_database_utf8>
il risultato DOVREBBE essere un dump con encoding UTF-8 ma usando l’utility file scopro che non è così:
ISO-8859 text, with very long lines, with CRLF, LF line terminators
In pratica non ha dumpato nel formato richiesto! Bene!
Beh, posso rimediare con l’utility recode:
sudo apt-get install recode cat <nome_database_utf8> | recode iso-8859-1..u8 > <nome_nuovo_database_utf8>
Ok, proviamo a testare il risultato con l’utility file:
UTF-8 Unicode text, with very long lines, with CRLF, LF line terminators
mmm, molto meglio! proviamo ora a caricare il database… perfetto!
O meglio sembra perfetto ma in realtà alcuni caratteri non sono stati convertiti correttamente, dannazione!!!
Ravanando un po’ in giro scopro che l’encoding SQL_ASCII è in pratica… un non encoding! In sostanza i caratteri dei dati vengono scritti senza tanti controlli… quello che è stato inserito viene riportato pari pari nel database…. no bene!
Inizialmente pensavo che SQL_ASCII potesse essere assimilabile all’iso-8859 ma sembra più affine ad un cp1252 (windows-1252, latin 1): bene riproviamo la conversione ma stavolta usiamo iconv.
iconv -c -f "windows-1252" -t "UTF-8" <nome_database> -o <nome_nuovo_database_utf8>
Noterete che iconv è stata usato con l’opzione -c … purtroppo la conversione non sarà mai perfetta. C’è la forte possibilità di incappare in caratteri non convertibili pertanto l’unica è skipparli!
ah dimenticavo: qualcuno mi ha fatto notare che nel dump c’è un riferimento preciso all’encoding usato: va convertito anche quello ovviamente!
Quindi questo:
SET client_encoding = 'SQL_ASCII';
diventerà questo:
SET client_encoding = 'UTF8';
Proviamo finalmente a caricare il database e…..Missione compiuta!!!
Non mi serve a niente, ma se dovesse mai capitarmi di doverlo fare per lavoro, da oggi so come fare 😉