Символ с кодировкой UTF8 не имеет эквивалента в WIN1252

Ответ 1

Что вы будете делать, когда получите это сообщение? Вы импортируете файл в Postgres? Как сказал devstuff, это характер спецификации. Это символ, который Windows записывает как первый текстовый файл, когда он сохраняется в кодировке UTF8 - это невидимый символ ширины 0, поэтому вы не увидите его при открытии его в текстовом редакторе.

Попробуйте открыть этот файл, например, в Блокноте, сохранить как в кодировке ANSI и добавить (или заменить аналогичную) строку set client_encoding to 'WIN1252' в вашем файле.

Ответ 2

У меня была аналогичная проблема, и я решил, установив кодировку в UTF8 с \encoding UTF8 на клиенте, прежде чем пытаться выполнить INSERT INTO foo (SELECT * from bar WHERE x=y);. Мой клиент использовал кодировку WIN1252, но база данных находилась в UTF8, поэтому ошибка.

Дополнительная информация доступна на Wiki в PostgreSQL под Поддержка набора символов (devel docs).

Ответ 3

Не уничтожайте персонажей, они настоящие и используются по уважительным причинам. Вместо этого устраните Win1252.

Ответ 4

Это выглядит как байтовая последовательность 0xBD, 0xBF, 0xEF как мало-конечное целое число. Это кодированная UTF8 форма символа символа байта Unicode (BOM) 0xFEFF.

Я не уверен, что такое нормальное поведение Postgre, но спецификация обычно используется только для обнаружения кодировки в начале входного потока и обычно не возвращается как часть результата.

В любом случае ваше исключение связано с тем, что этот код не имеет сопоставления на кодовой странице Win1252. Это произойдет и для большинства других нелатинских символов, например, для азиатских скриптов.

Можете ли вы изменить кодировку базы данных как UTF8 вместо 1252? Это позволит столбцам содержать почти любой символ.

Ответ 5

Мне удалось обойти это, используя функцию подстроки Postgres и выбрав это вместо:

select substring(comments from 1 for 200) from billing

Комментарий о том, что специальный символ начал каждое поле, помог ему в окончательном разрешении.

Ответ 6

У меня была очень похожая проблема. У меня был связанный сервер из SQL Server в базу данных PostgreSQL. Некоторые данные, которые у меня были в таблице, которую я выбирал при использовании инструкции openquery, имели некоторый символ, который не имел эквивалента в Win1252. Проблема заключалась в том, что запись System DSN (которую можно найти в разделе "Администратор источника данных ODBC" ), который я использовал для подключения, был настроен на использование PostgreSQL ANSI (x64), а не PostgreSQL Unicode (x64). Создание нового источника данных с поддержкой Unicode и создание нового модифицированного связанного сервера и обращение к новому связанному серверу в вашем openquery разрешили проблему для меня. Счастливые дни.

Ответ 7

Эта проблема появилась для нас около 19/11/2016, когда наше старое приложение Access 97 получило доступ к базе данных postgresql 9.1.

Это было решено путем изменения драйвера на UNICODE вместо ANSI (см. комментарий plang).

Ответ 8

Вот что сработало для меня: 1 включить специальные запросы в sp_configure. 2 добавьте ODBC DSN для вашего связанного сервера PostgreSQL. 3 убедитесь, что у вас есть драйверы ANSI и Unicode (x64) (попробуйте оба). 4 выполните запрос, как показано ниже: измените UID, IP-адрес сервера, имя и пароль db. 5 просто сохраните запрос в последней строке в формате postgreSQL.

EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
EXEC sp_configure 'ad hoc distributed queries', 1
RECONFIGURE
GO

SELECT * FROM OPENROWSET('MSDASQL', 
'Driver=PostgreSQL Unicode(x64); 
uid=loginid;
Server=1.2.3.41;
port=5432;
database=dbname;
pwd=password',

'select * FROM table_name limit 10;')