"UTF8" has no equivalent in encoding "LATIN9"

Version imprimable

16/09/2014, 08h48
aurelie.guegan.15

"UTF8" has no equivalent in encoding "LATIN9"
Bonjour,

Je suis face à un problème d'encodage lorsque j'importe mes données de mon fichier .csv dans ma base de donnée postgresql.
Ma base est en UTF8 cependant j'ai parfois des fichiers avec des caractères allemands donc l'emcodage est LATIN1 ou LATIN9.
Mon code est :
Code:

1 2 3 4 5 DELETE FROM copydata; SET client_encoding to'LATIN9' COPY copydata FROM 'C:/Users/AUGU/Documents/GL/DATA/STG_Ahlsdorf_table2.csv' WITH DELIMITER AS ';' HEADER CSV; SELECT * FROM copydata;
J'ai cette erreur que je n'arrive pas à résoudre :

Code:

ERROR: character with byte sequence 0xe2 0x80 0x9e in encoding "UTF8" has no equivalent in encoding "LATIN9"

0xe2 0x80 0x9e est il me semble le caractère suivant :' „'. Le soucie est que si je fais une recherche dans mon fichier pour voir où est ce caractère, il n'existe pas.

Auriez vous une idée de pourquoi cette erreur apparait et de comment la résoudre ?

Merci d'avance pour vos idées et vos conseils !
16/09/2014, 21h57
funtim78

As tu essayé d'utiliser Notepad ++ (ou un autre logiciel) afin de modifier l'encodage?
Encodage > Convertir en UTF-8 dans N++.
17/09/2014, 07h30
aurelie.guegan.15

Citation:

Envoyé par funtim78

As tu essayé d'utiliser Notepad ++ (ou un autre logiciel) afin de modifier l'encodage?
Encodage > Convertir en UTF-8 dans N++.

Non je connais pas du tout Notepad. Le problème c'est que j'ai beaucoup, beaucoup de fichier. De plus je travail sur un projet d'amélioration et simplification du traitement de ses fichiers donc si faut que je rajoute des étapes à mon procésus ca ne m'arrange pas trop. Cependant je vais jetter un coup d'oeil à ce logicel, ca peut qund même me servir !

Merci beaucoup de ta réponse !
Aurélie
17/09/2014, 09h48
SQLpro

Le problème d'un SGBDR comme PostGreSQL à ce niveau est triple :
1) un très faible nombre de collations et dépendantes des jeux de caractères
2) une imbrication jeux de caractères / collations particulièrement imbécile (les deux notions devraient être indépendantes)
3) une dépendance des jeux de caractères (et donc des collations) à l'OS (selon que l'on se trouve sur Linux ou Windows, les possibilité sont différentes.

Donc ton problèmes est impossible à résoudre avec PG.

En comparaison, SQL Server offre près de 4000 collations dont 3800 indépendantes des jeux de caractères et le reste spécifiques à certains jeux (y compris EBCDIC !)

A +
17/09/2014, 09h56
aurelie.guegan.15

Bonjour SQLpro,

Citation:

Donc ton problèmes est impossible à résoudre avec PG

Ohlala tout cela est bien déprimant.

J'ai plusieurs contraintes pour développer ma base de données et postgresql était très bien jusque là. En effet j'ai besoin d'un logiciel libre qui puisse gérer les données géospaciales afin de générer des vues/couches de points sous un logiciel SIG (QGIS) et avec l'extension PostGIS ca marche très bien.

Je vais esayer de trouver un moyen de mofier mes fichiers en amont donc pour que l'importation se face bien.

Merci de vos réponses
17/09/2014, 13h50
SQLpro

Citation:

Envoyé par aurelie.guegan.15;7967322}

Je vais esayer de trouver un moyen de mofier mes fichiers en amont donc pour que l'importation se face bien.

Hélas je crois qu'il n'y a pas beaucoup d'autres solutions....

Éventuellement il existe une version gratuite de SQL Server, mais limitée à des bases de 10 Go (au maximum 32 000 bases, soit 320 To de données).

L'incapacité de gérer les accents est assez récurent dans les produits "libres" car les développeurs sont essentiellement US et en langue anglaise il n'y a pas d'accents, de ligature, cédilles et autres particularités diacritiques ! Par conséquent, ce sujet ne les intéressent pas.

A +
17/09/2014, 14h02
aurelie.guegan.15

Dommage je suis en allemagne ^^ C'est pire lol !

Merci encore !
17/09/2014, 21h39
estofilo

Le SET client_encoding TO 'LATIN9' ne sert à rien pour le COPY car le serveur va ouvrir le fichier lui-même sans transiter par le client. Dans ce cas de figure le client_encoding est ignoré.

Si ce caractère "double guillemet en bas" (U+201E) est arrivé dans la table, c'est qu'il est dans le fichier. Et comme il n'existe pas en LATIN9, c'est que le fichier n'est pas en LATIN9. Le plus plausible, compte-tenu de l'erreur et de la séquence SQL, est qu'il est en UTF-8.

D'après moi , le SET client_encoding TO 'LATIN9' pose problème ici pour 3 raisons (rien que ça):

1) le fichier n'est pas en LATIN9
2) même s'il l'était le client_encoding ne sert à rien pour COPY (contrairement au \copy de psql, qui passe par le client)
3) au moment du SELECT, à cause du client_encoding en LATIN9 PG cherche à convertir le caractère en LATIN9 et ça provoque une erreur puisque ce caractère n'existe pas dans ce jeu de caractères.

Si ma théorie est juste, il suffit de l'enlever et le COPY comme le SELECT passeront sans problème.
18/09/2014, 08h15
aurelie.guegan.15
Bonjour estofilo,

Citation:

1) le fichier n'est pas en LATIN9

Mon fichier est composé de caractère allemand comme "ä" ou encore "ö", ces caractère ne sont pas lu en UTF-8, il me semble. Latin1 ou Latin9 peut cependant les lires.

Citation:

même s'il l'était le client_encoding ne sert à rien pour COPY (contrairement au \copy de psql, qui passe par le client)

Je n'ai pas bein compris. Peux tu me m'expliquer les différences en tre COPY et \COPY ? Peux tu aussi me dire dans quel cas, l'un est préférable à l'autre ?

Citation:

Si ma théorie est juste, il suffit de l'enlever et le COPY comme le SELECT passeront sans problème.

J'ai essayé sans le SET client_encoding, voici mon erreur :
Code:

1 2 FEHLER: ungültige Byte-Sequenz für Kodierung „UTF8“: 0xf6 0x68 0x65 0x3b CONTEXT: COPY copydata, Zeile 1
Traduit cela dit : Séquence de bytes non valide dans la ligneLa ligne 1 pointe sur cette ligne ci où un caractère spéciale se trouve :

1;Existierend;Y:\SAS\A\Ahrensbök\WindPRO\_ATLAS\USER\DWD Travemuende 1976 bis 1993.lib;4.410.378;5.987.181;30,0;Nein;VESTAS;V66 VCS 1.65MW-1.650;1,65;66,0;67,0;VESTAS V66 VCS 1.65MW 1650 66.0 !O! Nabe: 67.0 m (1);USER;WT 1660/01, 106,5dB Ct man.;V 14838;2.556,4;98,8;1,00;2,1;5,84;93;0,0;2.519,2;;6,60;2.240;5,67;2.119;5,0;5,75;2.092;7,4;6,71;2.252;7,4;6,39;2.377;5,0;5,33;2.529;4,9;5,12;2.365;5,9;5,49;2.447;9,7;6,78;2.572;13,8;8,02;2.467;19,6;7,58;2.564;12,3;6,05;2.658;5,7;5,47;2.264;3,3;1.249;0,0;4250 07 03870 67;10,2007;STG Ahrensbök

Pour précision toutes les lignes de mes fichiers ont se type de données. Cependant certaines n'ont pas de caractères spéciaux car ils vienent du nom d'une ville ou d'un village, cela change donc à chaque fichier importé.

Merci pour ta réponse,

Aurélie
18/09/2014, 13h07
estofilo

Si les fichiers sont encodés en LATIN9, et si on revient à l'erreur initiale:

Citation:

ERROR: character WITH byte sequence 0xe2 0x80 0x9e IN encoding "UTF8" has no equivalent IN encoding "LATIN9"

1. Est-ce que cette erreur se produit dans le COPY ou dans le SELECT qui suit?

2. Est-ce que le fichier concerné peut être mis en pièce jointe à la discussion, éventuellement amputé des lignes sans intérêt, tant que ce qui reste permet de reproduire le problème?
18/09/2014, 14h04
aurelie.guegan.15

3 pièce(s) jointe(s)

Citation:

Est-ce que cette erreur se produit dans le COPY ou dans le SELECT qui suit?

Alors l'erreur se produit dans le COPY

Citation:

Est-ce que le fichier concerné peut être mis en pièce jointe

Je joins deux fichiers en format xls car je n'ai pas réussi à joindre les .csv
Je joins également ma table copydata.
18/09/2014, 14h11
estofilo

Bonne idée d'avoir mis la définition de la table, mais en revanche il faudrait le CSV et non le XLS.
Si dvp rejette le csv tel quel, je soupçonne que le mettre dans un ZIP passerait, il me semble avoir vu passer des .ZIP dans certains messages
18/09/2014, 14h15
aurelie.guegan.15

1 pièce(s) jointe(s)

Voici un jeux de donnée en xls et csv. Merci beaucoup :D

Citation:

ERROR: missing data for column "temp_id"
CONTEXT: COPY copydata, line 2: "1;Neu;Y:\SAS\A\Ahlsdorf\STG\_ATLAS\D_NEU\WIESENBU.LIB;4.582.829;5.746.965;;Ja;ENERCON;E-40/6.44-600;..."

Les données de STG_Ahlsdorf_table2.csv contiennent 68 colonnes et la table 70 donc je supprime les 2 dernières colonnes de la table:

Code:

1
2
alter table copydata drop column temp_id;
alter table copydata drop column temp_srid_text;

Après ça j'importe le CSV sans erreur en tant qu'utilisateur postgres:

set client_encoding to 'LATIN9';
COPY copydata FROM '/tmp/STG_Ahlsdorf_table2.csv' WITH DELIMITER AS ';' HEADER CSV;

Résultat tjrs en client_encoding LATIN9 comme la séquence SQL montrée dans la question initiale

select * from copydata;
-[ RECORD 1 ]----------------+------------------------------------------------
temp_label                   | 1
temp_status                  | Neu
temp_access                  | Y:\SAS\A\Ahlsdorf\STG\_ATLAS\D_NEU\WIESENBU.LIB
temp_xtext                   | 4.582.829
temp_ytext                   | 5.746.965
temp_ztext                   | 
temp_valid                   | Ja   
temp_manufactor              | ENERCON             
temp_typegenerator           | E-40/6.44-600
temp_powerrated              | 600
temp_rotordiam               | 44,0
temp_hubheight               | 78,0
temp_description             | ENERCON E-40/6.44 600 44.0 !O! Nabe: 78,0 m
temp_creator                 | USER                
temp_powercurve              | WT1871/01
temp_userlabel               | WEA neu   
temp_result                  | 1.031,8
temp_efficiency              | 100,0
temp_regcorrec               | 1,00
temp_eqroughness             | 2,3
temp_meanwindspeed           | 5,76
temp_hpvalue                 | 96
temp_calprod_wgs             | 0,0
temp_actualwindcorrectenergy | 0,0
temp_goodnessfact            | 
temp_a(sum)                  | 6,50
temp_k(sum)                  | 2.256
temp_a(0)                    | 4,57
temp_k(0)                    | 2.443
temp_f(0)                    | 4,4
temp_a(1)                    | 5,14
temp_k(1)                    | 2.619
temp_f(1)                    | 3,6
temp_a(2)                    | 5,83
temp_k(2)                    | 2.584
temp_f(2)                    | 3,3
temp_a(3)                    | 6,72
temp_k(3)                    | 2.275
temp_f(3)                    | 6,8
temp_a(4)                    | 6,11
temp_k(4)                    | 2.467
temp_f(4)                    | 8,5
temp_a(5)                    | 5,35
temp_k(5)                    | 2.396
temp_f(5)                    | 5,4
temp_a(6)                    | 5,37
temp_k(6)                    | 2.299
temp_f(6)                    | 6,2
temp_a(7)                    | 6,82
temp_k(7)                    | 2.408
temp_f(7)                    | 13,7
temp_a(8)                    | 7,17
temp_k(8)                    | 2.533
temp_f(8)                    | 14,7
temp_a(9)                    | 8,08
temp_k(9)                    | 2.529
temp_f(9)                    | 15,6
temp_a(10)                   | 6,56
temp_k(10)                   | 2.408
temp_f(10)                   | 10,2
temp_a(11)                   | 5,19
temp_k(11)                   | 2.471
temp_f(11)                   | 7,5
temp_airdensity              | 1.230
temp_displacement            | 0,0
temp_projectnumber           | 4250 05 03115 67
temp_date                    | 11,2005
temp_place                   | STG Ahlsdorf

Pas d'erreur et pas de trace d'une séquence 0xe2 0x80 0x9e ...

18/09/2014, 15h45
alassanediakite

Salut
Le problème n'est-il pas dans le nom du fichier: STG_Ahrensbök.xls qui contient ö?
@+
18/09/2014, 15h49
estofilo

Le 1er message indique:
COPY copydata FROM 'C:/Users/AUGU/Documents/GL/DATA/STG_Ahlsdorf_table2.csv'
WITH DELIMITER AS ';' HEADER CSV;

Il n'y a pas d'accent dans ce nom de fichier.
18/09/2014, 16h17
aurelie.guegan.15

1 pièce(s) jointe(s)

QUOTE]Le problème n'est-il pas dans le nom du fichier: STG_Ahrensbök.xls qui contient ö?[/QUOTE]
Il me dit aue je peux pas le lire mais il suffit que le fichier soit enregister avec oe aulieu de ö et il n'y a plus de problème de ce coté la.

Citation:

Pas d'erreur et pas de trace d'une séquence 0xe2 0x80 0x9e ...

Quelle chance ! En pj mon screenshot !
Pièce jointe 156610[
18/09/2014, 16h39
estofilo
Bon. La différence qui peut jouer entre nos environnements est que mon postgres n'est pas en allemand et j'ai l'impression que le tien oui.

Ceci étant je propose une autre approche: depuis PG 9.1 il est possible de préciser l'encodage du fichier de données dans COPY via la directive ENCODING.
Je propose toujours de supprimer le SET client_encoding TO 'LATIN9'
(même faire à la place: SET client_encoding TO 'UTF8' histoire d'être sûr),

et de faire pour le COPY:
Code:

1 2 COPY copydata FROM 'C:/Users/AUGU/Documents/GL/DATA/STG_Ahlsdorf_table2.csv' WITH DELIMITER AS ';' HEADER CSV ENCODING 'LATIN9';
18/09/2014, 16h51
aurelie.guegan.15

estofilo BRAVO !

Alors je sais pas pourquoi mais voici mon retour ::lol:
Query returned successfully: one row affected, 20 ms execution time.

Merci beaucoup ! Vous m'avez sauvé ma journée ! :D
18/09/2014, 18h04
estofilo
Finalement on y arrive... :)

Au vu du fichier qui n'a aucun problème et qui ne contient aucun caractère non latin, je pense que cette erreur character WITH byte sequence 0xe2 0x80 0x9e... viendrait d'un message d'information qui va du serveur vers le client. Le message serait en UTF8 et contiendrait ce caractère de guillemet gauche "typographique" qui n'existe pas en LATIN9, et c'est l'impossibilité de convertir ce message qui provoquerait finalement à cette erreur.

Ce qui me fait dire ça c'est que les traductions en allemand des messages d'erreur utilisent ce type de guillemet , par exemple un message comme ça en anglais:
```
COPY format "%s" not recognized
```
est traduit par:
```
COPY-Format „%s“ nicht erkannt
```
Ce genre de guillemets pour faire joli est surtout une manière de se tirer dans le pied quand on est pas en full-UTF8...