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.
]]>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
]]>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é !
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)
]]>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...
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 ).
]]>CREATE VIEW tableE_v AS
SELECT replace(colonne,E'\u0xC28C',' ') from tableE;
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.
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".
]]>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 ?
]]>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...