Newsgroup: it.comp.software.database
Titolo: Trasferimento di dati tra DBMS e charset...

Intanto scusate il X-post ma non mi sono saputo decidere su dove 
postare, dato che il topic coinvolge diversi aspetti.
Cerco di descrivervi la situazione: ho per le mani un dump di alcune 
tabelle effettuato da un DB2/400 in flat files (ASCII per quanto ne so), 
  che vengono impacchettati in un file -jar e spediti via ftp.
Io ricevo questo file e devo importarlo in un DB PostgreSQL.
La procedura sarebbe:
- lo unzippo con opzione -aa (per mettere i linefeed a posto)
- per ogni file che ricevo, carico i dati dentro PSQL con il comando 
"COPY ... FROM ..."
Ma c'e' qualcosa che non mi torna con il charset, in alcuni ambienti. La 
causa sono le "famigerate" lettere accentate "à", "ì" eccetera.
La procedura sopra descritta funziona tranquillamente sotto una Mandrake 
10, e anche sotto una vetusta RH 7.3; se la provo sotto una Suse 9.3, 
per qualche strano motivo dopo l'unzip al posto delle lettere in 
questione trovo qualche sequenza "strana" (l'editor di KDE non mi fa 
proprio vedere nessun carattere, se lo apro da interfaccia carattere 
vedo una 'X' al loro posto, se provo a fare la copy mi prendo un 
pernacchione del tipo 'carattere non valido alla riga xxx...'.
Il principale sospetto è il fatto che la Suse usa un locale con .UTF-8. 
Ma questo dovrebbe aiutare la gestione delle lettere accentate, non 
impedirla... e oltretutto ho creato anche il DB sotto postgres in 
unicode, quindi dovrebbe "capire" senza problemi i caratteri in questione.
Ovviamente potrei fregarmene del problema e eliminare la Suse di torno, 
ma a parte che l'ho appena installata e nel complesso mi garberebbe 
tenermela, poi comunque voglio capirci di più su questa cosa.
Qualcuno ha qualche suggerimento su quale sia il punto in cui questi 
caratteri vengono "paciugati" male?? O magari un workaround?
Thanx.
-- 
Fabrizio "Hermooz" Ermini

 
Mi rispondo da solo per il workaround: ho settato Yast perchč il locale 
non venisse piů settato come .UTF8 e rigenerato il DB di postgres in 
encoding SQL_ASCII e cosě funziona. Continuo a non capirci granchč in 
questa faccenda, ma sopravvivero'...
-- 
Fabrizio "Hermooz" Ermini


Non capisce un ben niente se non gli dici in che character set sono
codificati i dati che gli stai mandando.
PSQL permette di settare il client encoding.
Fai degli esperimenti per vedere quale e' quello giusto.
Oppure leggi la documentazione di DB2/400.
Saluti  Manlio Perillo

 PSQL permette di settare il client encoding.
Huh? Come? Pensavo che si regolasse solo con i valori di locale 
dell'ambiente in cui gira. Comunque, non uso psql, ma un programmino ad 
hoc linkato con la pqlib.h (che č la stessa che usa psql).
-- 
Fabrizio "Hermooz" Ermini

hoc linkato con la pqlib.h (che è la stessa che usa psql).
SET client_encoding TO ...
Saluti  Manlio Perillo

 questa faccenda, ma sopravvivero'...
Per capire cosa non andava devi capire come funziona utf8.
utf8 e' un sistema di codifica multibyte (utilizza un numero di byte
variabile per codificare i caratteri). Per semplificare la vita agli
americani lo standard utf8 dice che i caratteri che sono compresi nella
tabella ascii a 7bit sono mappati 1 a 1 su un byte utf8, mentre dal,
credo, tutti gli altri caratteri sono mappati su piu' byte (credo che piu'
sia un numero tra 2 e 3, 4, non so di preciso).
Probabilmente il file che ti arriva dall'as/400 e' codificato in latin-1
(o iso8859-1) e per indicare la lettera à utilizza il codice 224. Ma se
te cerchi di interpretare quel file come se fosse codificato in utf-8 il
decoder incontrando il codice 224 cerca di leggere almeno un
altro byte per interpretare il carattere.
La soluzione al tuo problema e' di convertire il file che viene
dall'as/400 in utf-8, non so quale software lo faccia ma te la puoi cavare
con due linee di python:
<< codice non testato>>
out = file(nuovonome, 'w')
for line in file(nomefile):
    uline = line.decode('latin-1')
    nline = uline.encode('utf8')
    out.write(nline)
out.close()
<< ----- >>
HTH
david