problemas de codificación con ogr2ogr y base de datos Postgis / PostgreSQL

StackOverflow https://stackoverflow.com/questions/1377662

Pregunta

En nuestra organización, nos ocupamos de contenido SIG en diferentes formatos de archivo. Tengo que poner estos archivos en una base de datos PostGIS, y que se realiza mediante ogr2ogr. El problema es que la base de datos se codifica UTF8, y los archivos podría tener una codificación diferente.

Me encontrado descripciones de cómo puedo especificar la codificación mediante la adición de un parámetro de opciones para org2ogr, pero appearantly que no tiene un efecto. 

ogr2ogr -f PostgreSQL PG:"host=localhost user=username dbname=dbname \
password=password options='-c client_encoding=latin1'" sourcefile;

El error que recibo es: 

ERROR 1: ALTER TABLE "soer_vd" ADD COLUMN "målsætning" CHAR(10)
ERROR: invalid byte sequence for encoding "UTF8": 0xe56c73
HINT: This error can also happen if the byte sequence does not match the 
encoding expected by the server, which is controlled by "client_encoding".

ERROR 1: ALTER TABLE "soer_vd" ADD COLUMN "påvirkning" CHAR(10)
ERROR: invalid byte sequence for encoding "UTF8": 0xe57669
HINT: This error can also happen if the byte sequence does not match the 
encoding expected by the server, which is controlled by "client_encoding".

ERROR 1: INSERT command for new feature failed.
ERROR: invalid byte sequence for encoding "UTF8": 0xf8
HINT: This error can also happen if the byte sequence does not match the 
encoding expected by the server, which is controlled by "client_encoding".

En la actualidad, mi archivo fuente es un archivo de forma y estoy bastante seguro, que se codifica Latin1.

¿Qué estoy haciendo mal aquí y usted me puede ayudar?

Saludos cordiales, Casper

¿Fue útil?

Solución

Eso suena como que sería establecer la codificación del cliente para LATIN1. Exactamente qué error se puede conseguir?

Sólo en caso de ogr2ogr no pasa a lo largo adecuadamente, también puede intentar establecer el entorno PGCLIENTENCODING variable para latin1.

Le sugiero que vuelva a comprobar que en realidad son LATIN1. Simplemente ejecutando file en que le dará una buena idea, asumiendo que es en realidad constante dentro del archivo. También puede tratar de enviarlo a través iconv para convertirlo en cualquiera LATIN1 o UTF-8.

Otros consejos

Magnus es correcto y que se discutirá la solución aquí.

He visto la opción de informar sobre PostgreSQL codificación de caracteres, options=’-c client_encoding=xxx’, utilizan muchos lugares, pero no parece tener ningún efecto. Si alguien sabe cómo esta parte está trabajando, no dude en entrar en detalles.

Magnus sugirió para establecer el entorno PGCLIENTENCODING variable para LATIN1. Esto puede, de acuerdo con una lista de correo He preguntado, se realiza modificando la llamada a ogr2ogr: 

ogr2ogr -–config PGCLIENTENCODING LATIN1 –f PostgreSQL 
PG:”host=hostname user=username dbname=databasename password=password” inputfile

Esto no hizo nada para mí. Lo que funcionó para mí fue que, antes de la llamada a ogr2ogr, a: 

SET PGCLIENTENCODING=LATIN1

Sería bueno escuchar más detalles de los usuarios con experiencia y espero que pueda ayudar a los demás:)

Actualmente, OGR de GDAL no realiza ninguna recodificación de los datos de carácter durante la traducción entre los formatos vectoriales. El equipo ha preparado RFC 23.1: El soporte Unicode en el documento OGR que discute el apoyo de la recodificación de OGR los conductores. El RFC 23 se adoptó y la funcionalidad básica ya estaba lanzado en GDAL 1.6.0. Sin embargo, la mayoría de los conductores OGR no se han actualizado, incluyendo Shapefile controlador .

Por el momento, yo describiría como OGR codificación agnóstica e ignorante. Significa, OGR embargo, toma lo que recibe y lo envía a cabo sin ningún tipo de procesamiento. OGR utiliza tipo char para manipular los datos textuales. Esto está bien para manejar cadenas codificadas de múltiples bytes (como UTF-8) -. Es sólo un flujo normal de bytes almacenados como matriz de elementos de char

Se recomienda que los desarrolladores de controladores de OGR deben devolver cadenas UTF-8 codificados de valores de atributos, sin embargo, esta regla no ha sido ampliamente adoptados a través de los conductores de OGR, con lo que esta funcionalidad no termina el usuario está listo todavía.

Usted tiene que escribir su línea de comando como este: 

PGCLIENTENCODING=LATIN1 ogr2ogr -f PostgreSQL PG:"dbname=...

En las ventanas es un comando

  

SET PGCLIENTENCODING = LATIN1

En Linux

  

exportación PGCLIENTENCODING = LATIN1

o

  

PGCLIENTENCODING = LATIN1

Por otra parte esta discusión me ayude:

https: //gis.stackexchange .com / preguntas / 218443 / ogr2ogr-codificación-en-windows-utilizando-os4geo-shell-con-censo-datos

En las ventanas

  

SET PGCLIENTENCODING = LATIN1 ogr2ogr ...

No me da ningún error, pero no lo hacen ogr2ogr obras ... Tengo que cambiar la variable de sistema (por ejemplo, Sistema -> Configuración avanzada del sistema -> Variables de entorno -> Nueva variable del sistema) reiniciar el sistema y a continuación, ejecutar

  

ogr2ogr ...

He resuelto este problema mediante este comando: 

pg_restore --host localhost --port 5432 --username postgres --dbname {DBNAME} --schema public --verbose "{FILE_PATH to import}"

No sé si esta es la solución correcta, pero funcionó para mí.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top