Errore di codifica del carattere rodbc con PostgreSQL

Question

Viene visualizzato un nuovo errore che non ho mai ottenuto prima durante la connessione da R a un database GreenPlum PostgreSQL tramite RODBC. Ho ricevuto l'errore utilizzando EMACS/ESS e RStudio e la chiamata RODBC ha funzionato come in passato.

library(RODBC) 
gp <- odbcConnect("greenplum", believeNRows = FALSE) 
data <- sqlQuery(gp, "select * from mytable") 

> data 
[1] "22P05 7 ERROR: character 0xc280 of encoding \"UTF8\" has no equivalent in "WIN1252\";\nError while executing the query" 
[2] "[RODBC] ERROR: Could not SQLExecDirect 'select * from mytable'" 

EDIT: appena provato l'interrogazione di un altro tavolo e ha fatto ottenere risultati. Quindi penso che non sia un problema RODBC ma un problema di codifica della tabella PostgreSQL.

R version 2.13.0 (2011-04-13) 
Platform: i386-pc-mingw32/i386 (32-bit) 

locale: 
[1] LC_COLLATE=English_United States.1252 
[2] LC_CTYPE=English_United States.1252 
[3] LC_MONETARY=English_United States.1252 
[4] LC_NUMERIC=C       
[5] LC_TIME=English_United States.1252  

attached base packages: 
[1] stats  graphics grDevices utils  datasets methods base  

other attached packages: 
[1] RODBC_1.3-2 
> 

Answer 1

In primo luogo, la questione si pone in quanto R sta cercando di convertire in un locale di Windows che supporta UTF-8. Sfortunatamente, Brian Ripley ha riportato numerose volte che Windows non ha localizzazioni UTF8. Dalle ore trascorse a cercare sul Web, StackOverflow, Microsoft, ecc., Sono giunto alla conclusione che Microsoft odia UTF-8 Windows non supporterà UTF8.

Come risultato, non sono sicuro che ci sia una soluzione semplice a questo, se c'è qualche soluzione. La cosa migliore che posso raccomandare è di avvolgere un qualche tipo di conversione sul lato server, guarda filtrare i dati se puoi, o provare una lingua diversa, se appropriato (ad esempio cinese, giapponese, coreano).

Se si decide di avvolgere un convertitore, unicode.org recommendsthis ICU toolkit.

Answer 2

0xc280 è un elemento di controllo (U + 0080 in Unicode) che causa problemi molto spesso quando si utilizza SQL e simili. Il problema si trova spesso nella catena di conversione che si verifica invariabilmente quando si utilizzano applicazioni diverse che utilizzano schemi di codifica differenti. Windows ora include UTF-8, quindi non è un problema di Windows. Credo che il problema sorga prima che R legga i dati.

Infatti, nella catena la sequenza di caratteri 0x80 in UNICODE verrà mappata su 0xc280 in UTF-8. Questa dovrebbe essere una sequenza di controllo e non può essere stampata. Ma è probabile che il 0x80 non sia in realtà UNICODE, ma Windows Latin-1 o Latin-2. In tal caso, il 0x80 rappresenta il simbolo dell'euro. Questo potrebbe spiegare come finisce nei tuoi dati. Controlla se riesci a trovare qualcosa di simile nei dati, che spiegherebbe già qualcosa.

La mia ipotesi è che la soluzione non si troverà all'estremità R di questa catena, ma prima. Proverà la conversione automatica, ma in alcuni casi si dice che questo fallisce (anche per SQL e Oracle btw). Verifica in quale codifica stai lavorando in Postgresql e prova a utilizzare uno qualsiasi dei tipi latini. Potrebbero esserci altri collegamenti coinvolti (ad esempio un terminale Putty o simile). Sono abbastanza sicuro che tutte le codifiche siano ISO8859-1, che è Latin-1. Da qualche parte l'UTF-8 viene gettata in mezzo, e quando il carattere 0x80 viene mappato erroneamente a 0xc280, si hanno problemi.

Quindi controlla le codifiche nella tua workchain completa e assicurati che corrispondano tutte. Se non lo fanno, la conversione automatica effettuata tra ogni passaggio è destinata a dare problemi ad alcuni personaggi.

Spero che questo aiuti.

Answer 3

Per impostazione predefinita Greenplum utilizza UTF8 per la codifica dei caratteri. È possibile verificare ciò accedendo al server Greenplum e avviando psql - client console per Greenplum. In questa applicazione della console è possibile emettere il comando: \l per elencare tutti i database configurati in Greenplum - questo dovrebbe anche descrivere il set di caratteri per il database.

Penso che il tuo prblem sia che R non supporta UTF8 per i caratteri (si utilizzano impostazioni internazionali diverse) Ma è possibile utilizzare la transcodifica Al volo nel driver ODBC.Non sono sicuro di tutti i driver ODBC, ma i driver DataDirect supportano l'opzione extra nel file odbc.ini (che di solito si trova nella directory home dell'utente) - IANAAppCodePage.

Si potrebbe trovare di codice appropriato per questo parametro su questo link: http://www.iana.org/assignments/character-sets

Ecco l'esempio od contenuti ODBC.ini:

[ODBC] 
Driver=/opt/odbc/lib/S0gplm60.so 
IANAAppCodePage=2252 
AlternateServers= 
ApplicationUsingThreads=1 
ConnectionReset=0 
ConnectionRetryCount=0 
ConnectionRetryDelay=3 
Database=mysdb 
EnableDescribeParam=1 
ExtendedColumnMetadata=0 
FailoverGranularity=0 
FailoverMode=0 
FailoverPreconnect=0 
FetchRefCursor=1 
FetchTSWTZasTimestamp=0 
FetchTWFSasTime=0 
HostName=192.168.1.100 
InitializationString= 
LoadBalanceTimeout=0 
LoadBalancing=0 
LoginTimeout=15 
LogonID= 
MaxPoolSize=100 
MinPoolSize=0 
Password= 
Pooling=0 
PortNumber=5432 
QueryTimeout=0 
ReportCodepageConversionErrors=0 
TransactionErrorBehavior=1 
XMLDescribeType=-10 

Answer 4

avrei potuto postato questa risposta elswhere ma qui va.

Ricevo un errore simile durante la connessione a Postgres DB dal client MS SQL Management. Tentare di correggere i dati di origine è quasi impossibile nel mio caso.

mio Scenario:

1. tentativo di connessione al Postgress utilizzando MS SQL Oggetti collegati tramite un ODBC DSN di sistema, e vedi errori come "ERROR: carattere 0xc280 di codificanti "UTF8" non ha equivalenti "WIN1252";
2. istruzioni Select su alcuni tavoli di lavoro e gli altri gettano questo errore

Fix:. Utilizzare un driver ODBC che supporta Unicode sto utilizzando un driver ODBC da PostgreSQL Global Development G. ruppo. Vai a Configura DSN/Gestisci DSN e seleziona il driver Unicode.

Buona fortuna.