ошибка кодирования символов rodbc с PostgreSQL
Я получаю новую ошибку, которую я никогда не получал раньше при подключении от R к базе данных GreenPlum PostgreSQL с помощью RODBC. Я получил ошибку, используя как EMACS / ESS, так и RStudio, и вызов RODBC работал, как и в прошлом.
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'"
изменить: Просто попробовал запросить другую таблицу и получил результаты. Поэтому я думаю, что это не проблема RODBC, а проблема кодирования таблицы 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
>
4 ответов
во-первых, проблема возникает, потому что R пытается преобразовать в локаль Windows, которая поддерживает UTF8. К сожалению, Брайан Рипли неоднократно сообщал, что Windows не имеет локалей UTF8. От часов, потраченных на поиск в интернете, StackOverflow, Microsoft и т. д. Я пришел к выводу, что Microsoft ненавидит UTF-8 Windows не будет поддерживать UTF8.
в результате я не уверен, что есть простое решение для этого, если вообще есть какое-либо решение. Лучшее, что я могу рекомендуется обернуть какое-то преобразование на стороне сервера, посмотреть на фильтрацию данных, если можете, или попробовать другой язык, если это необходимо (например, китайский, японский, корейский).
Если вы решите обернуть конвертер,unicode.org рекомендует этот набор инструментов ICU.
0xc280-это элемент управления (U + 0080 в Unicode), который вызывает проблемы довольно часто при использовании SQL и подобных. Проблема часто заключается в цепочке преобразования, которая неизменно возникает при использовании разных приложений, использующих разные схемы кодирования. Windows имеет UTF-8 включен в настоящее время, так что это не строго проблема Windows. Я считаю, что проблема возникает до того, как R считывает данные.
фактически, в цепочке последовательность символов 0x80 в юникоде будет сопоставлена с 0xc280 в UTF-8. Предполагается, что это управляющая последовательность, и ее нельзя распечатать. Но велики шансы, что 0x80 на самом деле не UNICODE, а Windows Latin-1 или Latin-2. В этом случае 0x80 представляет знак евро. Это может объяснить, как он попадает в ваши данные. Проверьте, можете ли вы найти что-то подобное в данных, это уже что-то объясняет.
Я предполагаю, что решение не будет лежать в R-конце этой рабочей цепочки, но до этого. Он будет пытаться автоматически преобразование, но в некоторых случаях это не удается (также для SQL и Oracle btw). Проверьте, в какой кодировке вы работаете в Postgresql, и попробуйте использовать любой из латинских типов. Могут быть и другие ссылки (например, Шпатлевка или аналогичный терминал). Я уверен, что все кодировки есть ISO8859-1, который является латинским-1. Где-то UTF-8 попадает между ними, и когда символ 0x80 неправильно сопоставляется с 0xc280, вы получаете проблемы.
поэтому проверьте кодировки в вашем завершите workchain и убедитесь, что все они совпадают. Если они этого не делают, автоматическое преобразование, выполняемое между каждым шагом, обязательно вызовет проблемы для некоторых символов.
надеюсь, что это помогает.
Я мог бы опубликовать этот ответ elswhere, но здесь идет.
Я получаю аналогичную ошибку при подключении к Postgres DB от клиента управления MS SQL. Tyring исправить исходные данные почти невозможно в моем случае.
Мой Сценарий:
- попытка подключения к Postgress с помощью связанных объектов MS SQL через ODBC System DSN и см. Такие ошибки, как " ошибка: символ 0xc280 кодировка "UTF8"не имеет эквивалента в"WIN1252";
- выберите операторы в некоторых таблицах работают, а другие выдают эту ошибку.
Fix: используйте драйвер ODBC, который поддерживает Unicode. Я использую драйвер ODBC из глобальной группы разработки PostgreSQL. Перейдите к настройке DSN/управление DSN и выберите драйвер Unicode.
удачи.
по умолчанию Greenplum использует UTF8 для кодирования символов. Вы можете проверить это, войдя на сервер Greenplum и запустив клиент psql - консоли для Greenplum.
В этом консольном приложении вы можете выполнить команду:\l
перечислить все базы данных, настроенные в Greenplum - это также должно описывать набор символов для базы данных.
Я думаю, что ваша prblem заключается в том, что R не поддерживает UTF8 для символов (вы используете другую локаль) Но вы можете использовать транскодирование на лету в ODBC водитель. Не уверен во всех драйверах ODBC, но драйверы DataDirect поддерживают дополнительную опцию в odbc.ini-файл (обычно находится в домашнем каталоге пользователя) - IANAAppCodePage.
вы можете найти соответствующий код для этого параметра по этой ссылке: http://www.iana.org/assignments/character-sets
вот пример od 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