Bonjour,
J’ai toujours déposé mes CSV encodés en UTF-8, et divers outils d’édition ou tableur le détecte automatiquement.
Pourtant après certaines mise-à-jour je constate que tabular-api.data.gouv.fr et explore.data.gouv.fr ont ré-encodé mes textes comme si ils n’étaient pas en UTF-8.
Ma mise à jour du 12 avril est totalement caviardée alors que les 2 précédentes étaient correctes :
Bonjour, nous avons bien une détection automatique de l’encodage des fichiers dans notre pipeline d’APIfication, mais le script semble perturbé par la présence des émojis dans votre fichier, ce qui l’amène à considérer que l’encodage est « ISO-8859-1 » (avec un taux de confiance faible, qui pourrait expliquer pourquoi il a pu détecter le bon encodage auparavant). Vous pouvez comparer le résultat avec un autre fichier avec des caractères accentués, pour lequel la détection se passe sans problème.
Bonjour,
un peu sceptique que les émojis soient la cause ; les précédentes versions (depuis le 30 mars inclus) avaient déjà des émojis…
Je viens de déposer un nouveau fichier ayant 33 nouvelles lignes ajoutées au début qui est bien géré en UTF-8 et les émojis s’affichent.
Aussi essayé le fichier sans les 33 lignes ajoutées qui passe aussi, tandis que celui 12 avril échoue à chaque fois.
Voulez-vous mes anciennes versions du fichier pour investiguer ?
Bonjour @Pierlou_Ramade ,
le pb de détection de l’encodage est revenu 
Hier, j’ai déposé une màj avec le même processus d’export que les précédents (en UTF8) et l’API tabulaire refait un ré-encodage commi si c’était du ISO-8859-1.
En checkant avec Notepad++ je vois pas quel caractère perturberait csv-detective.
J’ai voulu m’initier au Python (sous Windows) pour débugger ce problème, mais l’install crash pour le module faust-cchardet. Et sur votre github il y a vraisemblament un pb avec la release 0.10.3
J’ai essayé avec la release précédente, même problème pour install ce module.
L’encodage avec l’API est toujours cassé alors que CSV-detective évalue que c’est de l’UTF8 avec +90% de confidence en analysant toutes les lignes
Bonjour,
Nous rencontrons le même souci que oliezekat
Jeux de données concernées : Jeu de données - Annuaire Santé - Extractions des données en libre accès des professionnels intervenant dans le système de Santé (RPPS) | data.gouv.fr
Depuis quelques semaines, nous avons constaté que certains fichiers de nos extractions libre accès ont un mauvais encodage. au niveau des en-têtes de colonnes dans l’API Tabulaire et dans la fonction explore.data.gouv.fr
A noter que notre fichier est bien en encodage UTF-8.
Merci par avance pour votre aide.
Bien Cordialement,
jamais eu de reponse de @Pierlou_Ramade ni même à mes dm
le pb reste même si je remets un ancien fichier, j’ai aussi essayé en nettoyant tout ce qui pouvait être malinterprété comme par exemple les emojis (bien que conforme à l’utf8)
@williamazis par curiosité j’ai run csv-detective avec votre fichier ps-libreacces-dipl-autexerc.txt (qui apparait caviardé dans l’api tabulaire), pour lui c’est du UTF8 avec 99% de confidence, et de visu il me semble nickel.
Bonjour, mes excuses pour le délai de réponse, je découvre ces messages. Nous avons largement revu la détection de l’encodage récemment, je viens de regarder les ressources dont il est question et je ne retrouve plus de trace des problèmes mentionnés. Pouvez-vous me confirmer que tout est bien conforme à l’attendu ?
