Le caractère avec encodage UTF8 N'a pas d'équivalent dans WIN1252

j'ai eu un problème similaire, et j'ai résolu en définissant l'encodage en UTF8 \encoding UTF8 dans le client avant d'essayer un INSERT INTO foo (SELECT * from bar WHERE x=y);. Mon client utilisait L'encodage WIN1252 mais la base de données était en UTF8, d'où l'erreur.

plus d'informations sont disponibles sur le wiki PostgreSQL sous Charge Du Jeu De Caractères (devel docs).

ne pas effacer les caractères, ils sont réels et utilisés pour de bonnes raisons. Au lieu de cela, eridicate Win1252.

cela ressemble à la séquence octet 0xBD, 0xBF, 0xEF comme un entier little-endian. Il s'agit de la forme codée UTF8 du caractère octet-ordre-marque (BOM) Unicode 0xFEFF.

Je ne sais pas quel est le comportement normal de Postgre, mais le BOM est normalement utilisé uniquement pour encoder la détection au début d'un flux d'entrée, et n'est généralement pas retourné dans le cadre du résultat.

dans tous les cas, votre exception est due à ce point de code n'ayant pas de mappage dans le code Win1252 page. Cela se produira aussi avec la plupart des autres caractères non latins, comme ceux utilisés dans les scripts asiatiques.

pouvez-vous changer L'encodage de la base de données en UTF8 au lieu de 1252? Cela permettra à vos colonnes de contenir presque n'importe quel caractère.

j'ai été en mesure de se déplacer par l'utilisation de la Postgres' fonction de sous-chaîne et de la sélectionner à la place:

select substring(comments from 1 for 200) from billing

le commentaire que le caractère spécial a commencé chaque champ a été d'une grande aide pour le résoudre finalement.

j'ai eu un problème similaire. J'avais un serveur lié depuis SQL Server vers une base de données PostgreSQL. Certaines données que j'avais dans le tableau que je sélectionnais en utilisant une instruction openquery avaient un caractère qui n'avait pas d'équivalent dans Win1252. Le problème était que l'entrée DSN système (qui se trouve sous L'administrateur source de données ODBC) que j'avais utilisé pour la connexion était configurée pour utiliser PostgreSQL ANSI(x64) plutôt que PostgreSQL Unicode(x64). Création d'une nouvelle source de données avec L'Unicode la prise en charge et la création d'un nouveau serveur lié modifié et le référencement du nouveau serveur lié dans votre openquery ont résolu le problème pour moi. Les jours heureux.

ce problème nous est apparu vers le 19/11/2016 avec notre ancienne application Access 97 accédant à un postgresql 9.1 DB.

ceci a été résolu en changeant le pilote en UNICODE au lieu de ANSI (voir le commentaire de plang).

Voici ce qui a fonctionné pour moi : 1 activer les requêtes ad-hoc dans sp_configure. 2 Ajouter ODBC DSN pour votre serveur PostgreSQL lié. 3 Assurez-vous d'avoir les pilotes ANSI et Unicode (x64) (essayez avec les deux). 4 exécutez la requête comme ceci ci-dessous-changez L'UID, l'ip du serveur, le nom de la base de données et le mot de passe. 5 Il suffit de garder la requête dans la dernière ligne au format 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;')