Проблемы с кодировкой в ​​базе данных ogr2ogr и Postgis/PostgreSQL

В нашей организации мы обрабатываем ГИС-контент в различных форматах файлов. Мне нужно поместить эти файлы в базу данных PostGIS, и это делается с помощью ogr2ogr. Проблема в том, что база данных имеет кодировку UTF8, а файлы могут иметь другую кодировку.

Я нашел описание того, как я могу указать кодировку, добавив параметр options в org2ogr, но, похоже, это не имеет никакого эффекта.

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

Ошибка, которую я получаю:

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".

В настоящее время мой исходный файл представляет собой файл Shape, и я почти уверен, что он закодирован в Latin1.

Что я здесь делаю не так, и вы можете мне помочь?

С уважением, Каспер


person Chau    schedule 04.09.2009    source источник


Ответы (6)


Это звучит так, как будто клиентская кодировка установлена ​​​​на LATIN1. Какую именно ошибку вы получаете?

На всякий случай, если ogr2ogr не передает его должным образом, вы также можете попробовать установить переменную окружения PGCLIENTENCODING в latin1.

Я предлагаю вам дважды проверить, что они на самом деле LATIN1. Просто запустив на нем file, вы получите хорошую идею, предполагая, что она действительно непротиворечива в файле. Вы также можете попробовать отправить его через iconv, чтобы преобразовать его в LATIN1 или UTF8.

person Magnus Hagander    schedule 05.09.2009
comment
Я пробовал как client_encoding, так и PGCLIENTENCODING, чтобы выбрать схему кодирования. Ни один из них не решил мою проблему. Поскольку я не нашел способа определить точную кодировку символов моих шейп-файлов, я попробовал LATIN1, LATIN9, WIN1250 и WIN1252, но безуспешно. Все еще ищу, как заставить iconv работать... - person Chau; 07.09.2009

Магнус прав, и я обсужу решение здесь.

Я видел возможность сообщить PostgreSQL о кодировке символов, options=’-c client_encoding=xxx’, используется во многих местах, но, похоже, это не имеет никакого эффекта. Если кто-то знает, как работает эта часть, не стесняйтесь уточнить.

Магнус предложил установить для переменной окружения PGCLIENTENCODING значение LATIN1. Согласно списку рассылки, который я запросил, это можно сделать, изменив вызов ogr2ogr:

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

Это ничего не дало мне. Что сработало для меня, так это то, что перед вызовом ogr2ogr:

SET PGCLIENTENCODING=LATIN1

Было бы здорово услышать больше подробностей от опытных пользователей, и я надеюсь, что это может помочь другим :)

person Chau    schedule 08.09.2009
comment
Мне кажется, что команда SET специфична для Windows. Здесь есть аналогичная тема: gis.stackexchange.com/questions/15912/, и они предложили команду EXPORT под Linux. Но, может быть, я ошибаюсь. Во всяком случае, SET работал у меня под Windows. - person Rauni Lillemets; 16.02.2016

В настоящее время OGR из GDAL не выполняет никакого перекодирования символьных данных во время преобразования между векторными форматами. Команда подготовила документ RFC 23.1: поддержка Unicode в OGR, в котором обсуждается поддержка перекодирования для OGR. водители. Был принят RFC 23, и основные функции уже выпущен в GDAL 1.6.0. Однако большинство драйверов OGR не были обновлены, включая драйвер шейп-файла.

На данный момент я бы назвал OGR независимым от кодирования и невежественным. Это означает, что OGR берет то, что получает, и отправляет без какой-либо обработки. OGR использует тип char для управления текстовыми данными. Это нормально для обработки многобайтовых закодированных строк (например, UTF-8) - это просто поток байтов, хранящихся в виде массива элементов char.

Разработчикам драйверов OGR рекомендуется возвращать строки значений атрибутов в кодировке UTF-8, однако это правило не получило широкого распространения в драйверах OGR, что делает эту функциональность еще не готовой для конечного пользователя.

person mloskot    schedule 22.01.2010

Вам нужно написать свою командную строку следующим образом:

PGCLIENTENCODING=LATIN1 ogr2ogr -f PostgreSQL PG:"dbname=...
person Sylvain    schedule 15.03.2012
comment
Я не понимаю, как ваш ответ предоставляет дополнительную информацию по сравнению с уже опубликованными ответами? - person Chau; 15.03.2012
comment
Для меня SET PGCLIENTENCODING=LATIN1 не сработало. Этот ответ помог мне. - person Nicolas Boisteault; 06.08.2015

В винде есть команда

УСТАНОВИТЬ PGCLIENTENCODING=LATIN1

В Linux

экспорт PGCLIENTENCODING=LATIN1

or

PGCLIENTENCODING=LATIN1

Кроме того, это обсуждение помогает мне:

https://gis.stackexchange.com/questions/218443/ogr2ogr-encoding-on-windows-using-os4geo-shell-with-census-data

На окнах

SET PGCLIENTENCODING=LATIN1 ogr2ogr...

не выдает никаких ошибок, но ogr2ogr не работает... Мне нужно изменить системную переменную (например, Система--> Дополнительные параметры системы--> Переменные среды -> Новая системная переменная) перезагрузить систему и запустить

огр2огр...

person Roberto Marzocchi    schedule 09.01.2019

Я решил эту проблему с помощью этой команды:

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

Не знаю, правильное ли это решение, но мне помогло.

person Sivaguru    schedule 10.04.2012