Discussion :

[aurelie.guegan.15]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[funtim78]

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

[aurelie.guegan.15]

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

[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 +

[aurelie.guegan.15]

Bonjour SQLpro,

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

[SQLpro]

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 +