Discussion :

[tyrtamos]

Bonjour,

import cStringIO : c'est du pur python2, d'ailleurs, savez-vous l'équivalent Python3 pour cette Lib ? "io" ?

Oui => io.StringIO

conclusion : décode ton fichier "iso8859" et travaille sur de l'unicode ça téviteras des galères. et biensur tu écris tout en "utf8"

Le principe qui diminue les problèmes d'encodage dans un programme Python 2 est:
- tout ce qui rentre est converti en unicode le plus tôt possible
- tout ce qui sort est converti à partir de l'unicode dans le bon encodage le plus tard possible
- entre les 2, on ne travaille qu'en unicode.

En faisant ça, on ne fait que se rapprocher du comportement de Python 3.

Il faut se méfier de l'utf-8 pour travailler à l'intérieur d'un programme, parce que le nombre d'octets dépend du caractère. Par exemple, le mot "tête" comporte 4 caractères mais 5 octets en utf-8. Cela provoque des anomalies dans le traitement des chaines. En contrepartie, l'utf-8 est très bon pour communiquer avec l'extérieur du programme, parce qu'il a des capacités excellentes de représenter des caractères dans des langues étrangères. Ce n'est pas par hasard si c'est l'encodage par défaut des linux récents.

[sweetasnz]

Ah erreur de ma part ; je viens de vérifier, je suis effectivement en Python2.
Mais il vaudrait peut-être mieux que je passe en Python3 !

ok pour reprendre les bouts de code qu'on t'a donné, cependant, il faut un minimum l'adapter à ta situation ET DONC à L'ENCODAGE DE TON FICHIER INITIAL.
là on ne peut pas franchement t'aider plus, donc :
Lis ton fichier avec le bon "encoding" (tyrtamos lis avec de l'utf8 alors que tu as dis que ton fichier était en iso8859, donc lis le avec iso8859)

code de tyrtamos :

Code :

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

1
2
3
4
5
def lirecsv(fichier, codisk):
    """lit le fichier CSV encodé codisk, et le retourne comme une 
       liste de listes unicode (tableau)
    """
    codcsv = "utf-8" # encodage supporté par le module csv

bref, tu as tous les éléments, refait un test en vérifiant la véracité de tes lignes de codes (les unes après les autres, pas à pas) par rapport avec ton fichier.
sinon renvoie le code que tu utilises car je ne voit pas pourquoi cela ne fonctionnerait pas chez toi, alors que chez nous (python26, 27) cela fonctionne bien.

allez courage, ça va forcemment passer un jour

[tyrtamos]

Lis ton fichier avec le bon "encoding" (tyrtamos lis avec de l'utf8 alors que tu as dis que ton fichier était en iso8859, donc lis le avec iso8859)

Ce n'est pas tout à fait ça: dans mon code, l'encodage du fichier csv est donné comme paramètre "codisk" pour que la lecture du fichier soit correcte. Mais à l'intérieur de la fonction de lecture, il faut une conversion en utf-8 parce que sous Python 2, le module csv n'accepte que de l'utf-8. Et le résultat est renvoyé à l'appelant en unicode.

1- Il faut donc qu'il adapte l'encodage du fichier csv, donc qu'il mette codisk="iso8859" là où j'ai mis codisk="cp1252"

2- et qu'il fasse attention au code d'affichage en fonction de l'encodage de sa console, car un mauvais encodage plante les programmes.

A part ça, je suis entièrement d'accord!

[sweetasnz]

Mais à l'intérieur de la fonction de lecture, il faut une conversion en utf-8 parce que sous Python 2, le module csv n'accepte que de l'utf-8. Et le résultat est renvoyé à l'appelant en unicode.

je crois qu'on a tout avec ça
a+ et bonne chance à enicnath

[wiztricks]

Salut,

Difficile de ne pas noter combien "mieux" devient ici ennemi de "bien".

Ça démarre avec un "print" foireux à cause de parenthèses qui affichent un tuple.
Cela corrigé, il n'y aurait plus eu de problèmes: "bien".
Et c'est une des toutes premières réponses.

Mais comme nous faisons le prosélytisme de "bonnes pratiques", difficile de ne pas apprendre à gérer l'encoding.

Comme le module CSV de Python2 ne sait pas travailler avec de Unicode, il faut lui passer des bytes comme l'"utf-8" mais "latin-1" suffirait aussi de ce côté-ci de l'Europe, non?
Il faut quand même se souvenir que nous avons vécu des dizaines d'années sans se prendre le chou à convertir les bytes en texte pour respecter l'encoding et que des strings de bytes restent tout a fait acceptables tant qu'on ne touche pas à utf-8 (où un byte n'équivaut plus toujours à un caractère).

Pourquoi se prendre le chou à vouloir faire "mieux" (surtout avec le module csv de Python2) alors que le soucis rencontré serait résolu si on se contentait de "bien"?
D'autant qu'on sait que ce "mieux" s'appelle Python3 et que le PO n'a pas (à priori) de soucis à l'utiliser.

- W
note: il existe aussi un module Python2 sur PyPi appelé unicodecsv prêt à l'emploi.

[sweetasnz]

résolu non ?
pensez à mettre à jour le statut de votre post