Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je souhaite automatiser la récupération de données de ma base PG SQL dans Excel.
Pour cela, je pensais utiliser OBDC, qui semble correctement installé, puisque je suis arrivé à me connecter à la base avec word en utilisant les fonctionnalités de publipostage.
Dans Excel, j'indique que je veux créer un tableau dynamique en choisissant une connexion ODBC me reliant à la base.
Le test de connexion est OK, mais lors de la récupération des données j'obtiens le message d'erreur suivant :
ERREUR : le caractère Ox--- du codage "UTF8" n'a pas d'équivalent dans "WIN1252";
Error while executing the query.
J'en déduis qu'il y a un problème de prototypage des données UTF8 en WIN1252 pour Excel....
Ma requête me renvoi bien des caractères accentués, je devais les convertir manuellement lorsque je passais par une requete avec pgAdmin, export CSV, import dans Excel.
Que puis je faire pour que les données soient correctement envoyées à Excel ?
J'ai trouvé des fonctions de configuration (\encoding par exemple), mais je ne vois ou placer cette commande puisque ODBC utilise une vue (une requête me poserait le même problème je pense?). Il semble pourtant possible de choisir le type de données du client
http://docs.postgresqlfr.org/8.4/multibyte.html
BD : Postgre SQL 8.4
Excel : 2007
Pilote ODBC pour PG : 8.04.01.00
merci par avance à toute âme charitable,
cébé.
Hors ligne
Il y a certainement un caractère utf8 qui n'est pas imprimable en win1252. C'est quoi le code exact du caractère unicode ?
Marc.
Hors ligne
Bonjour,
merci pour votre réponse,
Le caractère en erreur est 0x0c28c
Apres quelques recherches, je ne trouve que ca comme info :
U+008C c2 8c <control>
http://www.utf8-chartable.de/
Ce qui ne m'aide pas du tout 
Je pensais trouver un caractère accentué ou un truc dans le style...
Hors ligne
Moi aussi, mais ça veut donc dire qu'il y a probablement un caractère parasite.
Le mieux ça serait peut-être d'essayer de le supprimer de la base, avec la fonction replace par exemple.
Sinon, on peut aussi définir une nouvelle conversion, mais c'est un peu l'artillerie lourde, si c'est pour un caractère isolé.
Sinon, je ne me rappelle plus précisément, vu que j'utilise peu windows, mais il me semble qu'il y a deux connecteurs odbc. Un qui produit de la codepage 1252, un qui produit de l'unicode. Peut-être que ça serait intéressant d'essayer l'unicode si ce n'est pas déjà le cas ?
Dernière modification par Marc Cousin (21/04/2011 09:33:36)
Marc.
Hors ligne
J'ai essayé de retrouver le caractère en exportant les résultats au format CSV, je ne l'ai pas trouvé (dans PSP PAD, affichage en héxa, et fonction rechercher)
J'ai fais un programme c cherchant consécutivement les octets 0xc2 et 0c8c, il n'y sont pas.
Enfin, j'essaie d'utiliser la fonction regexp_replace, mais je n'y arrive , je ne sais pas m'en servir Comment passer en parametre mon code 0xC28C ??
Hors ligne
Pas la peine d'utiliser regexp_replace. La fonction replace simple suffit:
SELECT replace(colonne,'\u008C',' ') from tableE;
Le plus simple, c'est d'utiliser la notation \u, qui permet d'entrer le caractère dans sa représentation "code point".
Marc.
Hors ligne
Pas la peine d'utiliser regexp_replace. La fonction replace simple suffit:
SELECT replace(colonne,'\u008C',' ') from tableE;
Le plus simple, c'est d'utiliser la notation \u, qui permet d'entrer le caractère dans sa représentation "code point".
Arf, j'ai buté ce matin sur un problème tout bête :
SELECT replace(colonne,'\u0x8C',' ') from tableE;
J'avais pas fait attention que le 00 était une faute de frappe, mais qu'il fallait comprendre 0x
J'ai donc créé une vue
CREATE VIEW tableE_v AS
SELECT replace(colonne,'\u0xC28C',' ') from tableE;
et je viens chercher les données sur cette vue.
Et bien :
1/ j'ai toujours le problème
2/ PgAdmin me dit que :
ATTENTION: utilisation non standard d'un échappement dans une chaîne littérale
LINE 6: ... replace(facture_fournisseur.commentaire,'\u0xC280'...
^
HINT: Utilisez la syntaxe de la chaîne d'échappement pour les échappements,
c'est-à-dire E'\r\n'.
La requête a été exécutée avec succès en 31 ms, mais ne renvoie aucun résultat.
Hors ligne
Comme le dit PostgreSQL, il faut mettre le E avant. Ainsi :
CREATE VIEW tableE_v AS
SELECT replace(colonne,E'\u0xC28C',' ') from tableE;Guillaume.
Hors ligne
Quel est le caractère en erreur dans le message ? Ce ne doit pas être le même dars le replace: le caractère en erreur affiché dans le message, c'est la version UTF8 (le format interne utilisé par postgres), alors que le message à utiliser en \u est la version «code point» (une autre notation unicode).
Ensuite, le message est juste un message d'avertissement, vous signalant que vous avez utilisé un \ dans une chaine de caractères, et que cela pourrait être une erreur. Ici, ce n'en est pas une (enfin je pense). Vous pouvez vous débarrasser du message en positionnant escape_string_warning à off dans le paramétrage. Ou bien en utilisant la notation E'\u008C', pour lui signifier que c'est bien une chaîne de caractère au format postgresql et non au format SQL que vous lui passez (avec une séquence d'escape, \u ).
Marc.
Hors ligne
Le caractère en erreur est le 0xC280 que j'utilise dans le replace.
Je suis passé à l'éditeur de requetes de excel pour sélectionner les données, et c'est une saleté de champs commentaire qui est en cause, bourré d'accents, de caractères € n° et tout ça....
Plus trace du 0xC28C.... y'a un truc que je ne sais pas. C'est peut etre parceque je ramène moins de données, juste ce dont j'ai besoin dans excel.
Pour information, j'ai utilisé une autre base avec le même schéma, et cela fonctionne très bien, mais c'est une base beaucoup plus légère (moins de données), et probablement pas d'accents ( et autres) car je n'en met souvent pas...
Hors ligne
Est-ce qu'il n'y 'a pas une fonction, sur le meme principe que replace, qui convertisse directement les résultats d'un codage à l'autre ? C'est ce que j'ai cherché au début mais que je n'ai pas trouvé.
Hors ligne
Dans le message d'erreur il affiche 0xC280 ? Dans ce cas, dans le replace, il faut utiliser E'\u0080', qui est sa représentation code point.
Sinon, si vous voulez directement le faire en hexadécimal, vous pouvez aussi le saisir E'\xc2\x80' (la notation hexa n'accepte que 2 chiffres hexa maximum)
Marc.
Hors ligne
La fonction, sur le même principe, c'est la même que celle que le moteur utilise automatiquement pour faire la conversion entre le client et le serveur. Elle entraînera donc exactement la même erreur.
Marc.
Hors ligne
Youhou !!
Ca fonctionne avec le E'\xc2\x80'
Je n'ai pas bien saisie l'histoire de code point,mais l'essentiel est que ca fonctionne.
C'est pour un outil interne, donc tout va bien.
Merci beaucoup à vous en tout cas !
Tant sur la réponse que la disponibilité et la réactivité !
Hors ligne
Bon, quand même, pour comprendre mieux: il y a plein de façon de représenter unicode (je vais même probablement dire des conneries ou faire des approximations, vu que c'est un peu touffu comme sujet): 8 bits extensibles à 32 (utf8), il y a plusieurs normes en 16 bits (UCS2, avec plusieurs déclinaisons, comme UTF-16BE et UTF-16LE suivant qu'on stocke en big endian ou little endian), UTF32…
La notation en \u et \U c'est une notation 16 ou 32 bits (suivant le nombre de chiffres hexa qu'on met, bien sûr). Alors que la valeur hexa vue dans le message d'erreur, c'est la valeur en UTF8 (encodage interne dans la base). Bref, un joyeux bazar 
Marc.
Hors ligne
Les représentations sont de toute façon un sacré dossier !
Déjà lors de la mise en place de l'intranet, nous avons eut du fil à retordre entre les codages du serveur, de la BD, du client, etc etc
C'est difficile de comprendre qui fait quoi dans tout ca.
Poussé par la curiosité, je suis allé jusqu'au bout, et j'ai recherché les champs qui posaient problème :
SELECT replace(commentaire, E'\xc2\x80', '--------------------------------------------------------------------*******************************************') AS commentaire
FROM facture_fournisseur
C'est une vieille information, qui est passée par diverses conversions et importations à partir de fichiers Excel. A priori, un caractère € qui posait problème. Il n'y avait donc qu'une ligne en défaut, et le caractère était bien sur invisible.
Hors ligne
Ça y ressemble fortement: €, c'est le caractère 80 en hexadécimal, en codepage 1252. Ça ressemble surtout à des données en codepage 1252 importées telles quelles en utf8. Le C2 pouvant correspondre à un  juste avant dans le texte .
Marc.
Hors ligne
Pages : 1