2011-08-23 14 views
7

Recibo un nuevo error que nunca antes recibí cuando me conecté de R a una base de datos PostgreSQL de GreenPlum usando RODBC. He recibido el error usando EMACS/ESS y RStudio, y la llamada RODBC ha funcionado como lo hizo en el pasado.error de codificación de caracteres rodbc con PostgreSQL

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: acaba de intentar consultar otra mesa y lo hicieron obtener resultados. Así que supongo que no es un problema de RODBC sino un problema de codificación de tabla de 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 
> 
+0

¿Funciona en una sesión normal de R? La salida de 'sessionInfo()' podría ser útil en este caso. Parece que algo ha cambiado de tal manera que uno o ambos sistemas locales/codificaciones han cambiado. (Por cierto, no es que un error tipográfico en el argumento nombre 'believeNRows' en la llamada' odbcConnect() '?) –

+0

@Gavin no, no funciona desde la sesión R normal, simplemente lo intenté. Acabo de agregar el resultado de sessionInfo() y solucioné el error tipográfico. – wahalulu

Respuesta

4

En primer lugar, el problema se debe a que R intenta convertir a una configuración regional de Windows que admita UTF8. Desafortunadamente, Brian Ripley ha informado en numerosas ocasiones que Windows no tiene configuraciones regionales UTF8. De horas dedicadas a buscar en la web, StackOverflow, Microsoft, etc., he llegado a la conclusión de que Microsoft odia a UTF-8 Windows no admitirá UTF8.

Como resultado, no estoy seguro de que haya una solución fácil para esto, si existe alguna solución. Lo mejor que puedo recomendar es ajustar algún tipo de conversión en el lado del servidor, fíjese en filtrar los datos si puede, o pruebe en otro idioma, si corresponde (por ejemplo, chino, japonés o coreano).

Si decide envolver un convertidor, unicode.org recommendsthis ICU toolkit.

+0

gracias. No sé por qué obtengo caracteres originales en los datos, todo es inglés y la tabla que consulto es toda agregación. Lo miraré. – wahalulu

+0

+1 para la MS odia a UTF8 :) – wahalulu

+0

Shhhh, no digas eso explícitamente. Deberías escribirlo en una jerigonza o nos pondrás a todos en problemas. ;-) Mi algoritmo de encriptación en Windows es simplemente convertir todo a UTF8 - ¡voilá! – Iterator

3

0xc280 es un elemento de control (U + 0080 en Unicode) que causa problemas con bastante frecuencia al usar SQL y los "me gusta". El problema a menudo se encuentra en la cadena de conversión que invariablemente ocurre cuando utiliza diferentes aplicaciones que utilizan diferentes esquemas de codificación. Windows tiene UTF-8 incluido por ahora, por lo que no es estrictamente un problema de Windows. Creo que el problema surge antes de que R lea los datos en.

De hecho, en la cadena, la secuencia de caracteres 0x80 en UNICODE se mapeará a 0xc280 en UTF-8. Se supone que esto es una secuencia de control y no se puede imprimir. Pero es probable que el 0x80 no sea UNICODE, sino Windows Latin-1 o Latin-2. En ese caso, el 0x80 representa el signo del euro. Eso podría explicar cómo termina en tus datos. Comprueba si puedes encontrar algo así en los datos, eso ya explicaría algo.

Supongo que la solución no estará en el extremo R de esta cadena de trabajo, sino antes de eso. Intentará la conversión automática, pero se informa que falla en algunos casos (también para SQL y Oracle por cierto). Compruebe en qué codificación está trabajando en Postgresql e intente utilizar cualquiera de los tipos latinos. Puede haber otros enlaces involucrados (una masilla o terminal similar, por ejemplo). Estoy bastante seguro de que todas las codificaciones allí son ISO8859-1, que es Latin-1. En algún lugar UTF-8 se tira en el medio, y cuando el personaje 0x80 se asigna erróneamente a 0xc280, obtienes problemas.

Compruebe las codificaciones en su cadena de trabajo completa y asegúrese de que todas coincidan. Si no lo hacen, la conversión automática realizada entre cada paso dará problemas a algunos personajes.

Espero que esto ayude.

+0

gracias por la explicación. Creo que el origen del problema es que un campo en la tabla contiene cadenas de consulta url que pueden contener caracteres internacionales extraños. Sin embargo, he podido consultar esta tabla utilizando otros clientes a través de ODBC, como PgAdmin y RazorSQL. Extraño... – wahalulu

0

Por defecto, Greenplum usa UTF8 para la codificación de caracteres. Puede verificar esto iniciando sesión en el servidor Greenplum y ejecutando psql - console client para Greenplum. En esta aplicación de consola puede emitir el comando: \l para listar todas las bases de datos configuradas en Greenplum; esto también debe describir el conjunto de caracteres para la base de datos.

Creo que su problema es que R no es compatible con UTF8 para los caracteres (utiliza una configuración regional diferente) Pero podría utilizar la transcodificación sobre la marcha en el controlador ODBC.No estoy seguro acerca de todos los controladores ODBC, pero los controladores DataDirect admiten una opción adicional en el archivo odbc.ini (generalmente ubicado en el directorio de inicio del usuario) - IANAAppCodePage.

se puede encontrar código apropiado para este parámetro en este enlace: http://www.iana.org/assignments/character-sets

Aquí está el ejemplo desde el contenido 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 
1

que podría haber publicado esta respuesta en otras partes, pero aquí va.

Recibo un error similar cuando me conecto a Postgres DB desde el cliente de administración de MS SQL. Tyring para arreglar los datos de origen es casi imposible en mi caso.

Mi Escenario:

  1. intentar conectar con Postgress uso de MS SQL objetos vinculados a través de un ODBC DSN de sistema, y ​​ver los errores como "ERROR: Carácter 0xc280 de codifican 'UTF-8' no tiene equivalente en "WIN1252";
  2. instrucciones SELECT en algunas mesas de trabajo y otros tiran este error

Fix:. Utilice un controlador ODBC que soporta Unicode que estoy utilizando un controlador ODBC de PostgreSQL Global Development G. roup Vaya a Configurar DSN/Administrar DSN y seleccione el controlador Unicode.

Buena suerte.

Cuestiones relacionadas