Annonce
L'appel à participation est ouvert jusqu'au 19 janvier 2025!
Pages: 1
- Sujet précédent - caractère 0xe28099 du codage UTF8 n'a pas d'équivalent dans LATIN1 - Sujet suivant
#1 Tue 20 August 2013 11:13
- pasca2011
- Juste Inscrit !
- Date d'inscription: 11 Jun 2013
- Messages: 7
caractère 0xe28099 du codage UTF8 n'a pas d'équivalent dans LATIN1
Bonjour
Je transfère du shapefile vers une base POSTGIS et j'ai l'erreur suivante dans FME
Creating table 'sig.espaces_verts'...
Emptying factory pipeline
Unexpected Input Remover(TestFactory): Tested 134 input feature(s) -- 134 feature(s) passed and 0 feature(s) failed
Unexpected Input Remover Nuker(TeeFactory): Cloned 0 input feature(s) into 0 output feature(s)
Source -> Generic(TeeFactory): Cloned 134 input feature(s) into 134 output feature(s)
Espaces verts Feature Counter -1 3(TeeFactory): Cloned 134 input feature(s) into 134 output feature(s)
Espaces verts -> sig.espaces_verts Correlator(TeeFactory): Cloned 134 input feature(s) into 134 output feature(s)
Final Output Feature Type Router(TestFactory): Tested 134 input feature(s) -- 134 feature(s) passed and 0 feature(s) failed
Final Output Nuker(TeeFactory): Cloned 0 input feature(s) into 0 output feature(s)
Bulk copy failed on table 'sig.espaces_verts' using delimiter ':'. Error was 'ERREUR: le caractère 0xe28099 du codage « UTF8 » n'a pas d'équivalent dans « LATIN1 »
CONTEXT: COPY espaces_verts, ligne 59
'
D'habitude j'ai ce genre de problème avec des accents. Mais je ne trouve rien.
Que puis je faire ?
Est-ce que le problème est à la ligne 59 du document initial ?
Merci de votre aide,
Cordialement,
Hors ligne
#2 Tue 20 August 2013 14:50
Re: caractère 0xe28099 du codage UTF8 n'a pas d'équivalent dans LATIN1
Quelle version de FME utilisez-vous ?
Il y a eu des problèmes d'encodage avec postgresql/postgis résolus avec FME 2013.
Sinon et si votre base est bien en Latin 1 il doit effectivement y avoir un caractère non compatible dans votre jeu de données source.
Dans ce cas là, la seule solution est de faire le chargement par petits bouts pour identifier le caractère qui pose problème.
Hors ligne
#3 Tue 20 August 2013 17:13
- xav
- Participant assidu
- Date d'inscription: 27 Oct 2005
- Messages: 280
Re: caractère 0xe28099 du codage UTF8 n'a pas d'équivalent dans LATIN1
Bonjour,
j'ai eu pas mal de problème de ce genre avec les apostrophes, principalement avec des données qui provenaient d'un copier/coller depuis word/excel/outlook/...
Dans ces logiciels, l'apostrophe n'est pas la même (caractère légèrement courbé) mais à l’œil, la différence est très dur à voir.
J'ai également eu un cas ou ... (3 points) étaient considérés comme un caractère unique (et non 3 caractères) et la c'était vraiment compliqué à voir.
Mais comme le dit Olivier dans ce genre de cas, il faut charger les données par petits bout pour trouver le (ou les) caractère(s) posant problème.
Bon courage
Xavier Lang
Information géographique et observatoire - DSI Communautaire
Cap Atlantique
Hors ligne
#4 Thu 22 August 2013 12:28
- pasca2011
- Juste Inscrit !
- Date d'inscription: 11 Jun 2013
- Messages: 7
Re: caractère 0xe28099 du codage UTF8 n'a pas d'équivalent dans LATIN1
j'utilise FME 2013 (que j'ai mis à jour juste avant de tenter ce transfert...)
J'avais déjà supprimé les apostrophes, les accents, les :, les ...
en y allant pas à pas je crois que j'ai trouvé la ligne problematique, j'ai retapé le texte , mais je ne vois pas ce qui n'allais pas...
Merci.
Hors ligne
#5 Thu 22 August 2013 16:17
Re: caractère 0xe28099 du codage UTF8 n'a pas d'équivalent dans LATIN1
Sûrement une histoire de simple quote ?
Freelance traitements ETL FME certifié: www.sitdi-france.fr Twitter : @sitdifrance
Site perso ~ www.partir-en-vtt.com
Hors ligne
#6 Thu 22 August 2013 20:55
- pasca2011
- Juste Inscrit !
- Date d'inscription: 11 Jun 2013
- Messages: 7
Re: caractère 0xe28099 du codage UTF8 n'a pas d'équivalent dans LATIN1
non, il n' y en avait pas. Pas compris ce qui posait probleme.
Même probleme aujourd'hui en voulant déposer un lot de données. C'est vraiment peu pratique quand on a 2000 lignes à mettre dans la base d'avoir tant d'erreurs pour des histoires de caractères accentués, de tirets, d'apostrophes ou d'espaces...
Dernière modification par pasca2011 (Mon 26 August 2013 21:39)
Hors ligne
Pages: 1
- Sujet précédent - caractère 0xe28099 du codage UTF8 n'a pas d'équivalent dans LATIN1 - Sujet suivant
