Кодирование проблем с ogr2ogr и базой данных Postgis/PostgreSQL
Глобальные переменные прекрасны в небольших программах, но ужасные, если используется тот же путь в больших.
Это означает, что можно легко привыкнуть использовать их при изучении. Это - то, от чего Ваш преподаватель пытается защитить Вас.
, Когда Вы более опытны, будет легче изучить, когда они будут хорошо.
3 ответа
Звучит так, как будто клиентская кодировка устанавливается на LATIN1. Какую именно ошибку вы получаете?
На тот случай, если ogr2ogr не передает ее должным образом, вы также можете попробовать установить для переменной среды PGCLIENTENCODING значение latin1 .
I Предлагаем вам дважды проверить, что они на самом деле LATIN1. Простое выполнение файла на нем даст вам хорошее представление, если предположить, что он действительно согласован внутри файла. Вы также можете попробовать отправить его через iconv , чтобы преобразовать его в LATIN1 или UTF8.
Магнус прав, и я буду обсуждать здесь решение.
Я видел возможность сообщить 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
Было бы здорово услышать больше подробностей от опытных пользователей, и я надеюсь, что это поможет другим :)
В настоящее время OGR из GDAL не выполняет никакого перекодирования данных символов во время перевода между вектором форматы. Команда подготовила RFC 23.1: поддержка Unicode в документе Ogr , который обсуждает поддержку перекодирования водителей OGR. Был принят RFC 23 , а основная функциональность уже была выпущена в GDAL 1.6.0. Тем не менее, большинство водителей огня не обновлялись, в том числе водитель Sharpfile .
На данный момент я бы назвал Огром как кодирование агностики и невежественным. Это означает, что Ogr делает то, что он получает и отправляет его без какой-либо обработки. OGR использует тип CHAR для манипулирования текстуальными данными. Это нормально, чтобы обрабатывать многобайтовые кодированные строки (например, UTF-8) - это просто простой поток байтов, хранящихся как массив элементов Char.
рекомендуется, чтобы разработчики драйверов OGR должны вернуть utf-8 кодированные строки значений атрибутов, однако это правило не было широко принято по всему драйверам Огрова, что делает эту функциональность, не готовую еще не конец.