Python ne voit pas le format Windows

Version imprimable

[Résolu]Python ne voit pas le format Windows[Résolu]

Bonjour

Je développe pour moi une application perso convertir des fichier .c format win en unix ( remplacement des '\r\n' par des '\n')

voici mon code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 import os Rep_courant = os.getcwd() print Rep_courant ls = os.listdir(Rep_courant) for i in ls: Fc = i.count('.c') if Fc == False: int = ls.index(i) del(ls[int]) ofi = open(ls[0],'r') print ls[0] Lecofi = ofi.read() res = Lecofi.count('\r\n') print res ofi.close()
res = -1 alors que mon fichier contient bien des '\r\n' vu avec notepad++ (CRLF)
pourqoui?

Merci de votre aide

16/03/2010, 18h03
tyrtamos

Bonjour,

Il est possible que Python prenne des initiatives pour "normaliser" son comportement entre les différentes plateformes, mais en fait tu n'as pas besoin d'aller plus loin dans cette direction: Lecofi = ofi.read().rstrip() retire la fin de ligne dans tous les cas. Tu pourras ajouter la fin de ligne linux après.

Sinon, ton code a des améliorations nécessaires:

- tester si le fichier est un fichier "xxxxx.c": os.path.splitext(nomdefichier)[-1] renvoie l'extension avec son point. Ton code actuel comptera "toto.cxxx.txt comme un fichier C.

- j'imagine qu'aucun sous-répertoire n'aura un nom qui se terminera par '.c' sinon, il y aura une erreur. On peut éliminer les sous-répertoires en testant avec os.path.isfile().

- ce n'est pas raisonnable de vouloir modifier la liste ls alors qu'elle est la base de la boucle for. Ou alors, on peut utiliser un while. Mais il vaut mieux créer une liste supplémentaire temporaire qui ne contient que les fichiers C détectés.

Tyrtamos
16/03/2010, 18h06
eyquem

Pour info:

http://www.python.org/dev/doc/maint2...new/node7.html

http://www.python.org/dev/peps/pep-0278/
16/03/2010, 18h48
eyquem
Code:

1 2 3 4 5 for i in ls: Fc = i.count('.c') if Fc == False: int = ls.index(i) del(ls[int])
Ouhlala, il y a danger,là....... Deux dangers.

L'un réel.

for i in ls: te fait parcourir la list ls de son début vers sa fin

Quand tu élimines un élément de la liste par del(ls[int]) , tous les éléments qui le suivaient se retrouvent avc des indices diminués de 1. Ce qui veut dire que quand l'itération poursuit son avancée, l'élément considéré au tour suivant n'est pas l'élément qui suivait celui qui a été délété mais le suivant de ce suivant !

Pour résoudre le problème, facile: on parcourt la liste dans l'autre sens:
for i in ls[::-1]

L'autre virtuel dans le cas qui t'occupe.

En éliminant un élément de la liste sur la base de son index recherché, tu t'expose à trouver un index plus petit que celui de l'élément que tu es en train d'examiner, s'il y en a deux exemplaires dans la liste. Et donc tu vas éliminer un élément plus en amont dans la liste que celui qui devrait l'être.

Dans ton cas, ça ne peut pas arriver parce que les noms des fichiers sont a priori tous différents.

Mais dans d'autres cas, on peut imaginer que la condition examinée soit telle qu'un 1er exemplaire ne soit pas éliminé quand le programme lui passe au dessus, et que la condition examinée soit vérifiée pour un 2ième exemplaire plus en aval du premier ce qui va déclencher l'élimination de l'élément trouvé sur la base de son indice, c'est à dire le premier, parce que les deux exemplaires sont identiques. Et ce n'est pas ce qu'on veut. :aie: Ouf.

Pour ne jamais être confronté à ce genre de problème il vaut mieux parcourir la liste en se fondant dès le départ sur un index incrémenté.

Ce qui au total donne:
Code:

1 2 3 4 for n in xrange(len(ls)-1,-1,-1): if ls[n].find('.c')!=-1: del(ls[n])
Tyrtamos, splitext() produit une paire, il suffit donc d'écrire os.path.splitext(nomdefichier)[1] et non pas -1
16/03/2010, 20h02
dividee

Encore plus simple: autant éviter de modifier la liste et en construire une nouvelle:

Code:

ls = [e for e in ls if '.c' not in e]

Je préfère aussi l'utilise de in (ou not in) qui me parait plus claire (on n'a pas besoin de trouver la position de '.c', juste savoir s'il s'y trouve).
Mais ici, ce serait pas plutôt endswith qu'il faudrait utiliser ?

Code:

ls = [e for e in ls if not e.endswith('.c')]

Pour le problème des fins de lignes qui ne sont pas trouvées, il faudrait peut-être utiliser le mode d'ouverture "rb" plutôt que "r". Ouvrir le fichier en mode binaire empêche Python d'interpréter les fins de lignes en fonction de l'OS...
17/03/2010, 08h58
hdgetnet

Merci

pour vos conseils, je suis un pure développeur en C.
Je code en Python comme en C :aie: car je débute en python

Par contre vous ne répondez pas à ma question sur les fins de lignes

Bonjour,

Faisons un petit test:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 ############################## print "fin de ligne Windows" f = open("testFDL.txt", 'w') f.write("toto\r\n") f.close() f = open("testFDL.txt", 'r') ligne = f.readline() f.close() for c in ligne: print ord(c) print "comptage:", ligne.count('\r\n') ############################## print "fin de ligne Linux" f = open("testFDL.txt", 'w') f.write("toto\n") f.close() f = open("testFDL.txt", 'r') ligne = f.readline() f.close() for c in ligne: print ord(c) print "comptage:", ligne.count('\n') ############################## print "fin de ligne Mac" f = open("testFDL.txt", 'w') f.write("toto\r") f.close() f = open("testFDL.txt", 'r') ligne = f.readline() f.close() for c in ligne: print ord(c) print "comptage:", ligne.count('\r')
Ce qui affiche:

Citation:

fin de ligne Windows
116
111
116
111
13
10
comptage: 1

fin de ligne Linux
116
111
116
111
10
comptage: 1

fin de ligne Mac
116
111
116
111
13
comptage: 1

On voit que Python fait bien son boulot: les fins de ligne de chacun des systèmes d'exploitation sont correctement reconnus, y compris avec count. Si ça ne marche pas chez toi, tu devrais vérifier le fichier sur disque avec un éditeur hexa. Si c'est ok, regarde s'il n'y a pas un problème d'encodage (ex: si les sources C sont en unicode, il faut les lire en unicode).

Mais, je le répète, pour supprimer les fins de ligne, tu n'as pas besoin de ça dans ton problème: ligne.rstrip() retire la fin de ligne dans tous les cas, et tu peux ajouter la nouvelle fin de ligne que tu souhaites!

Pour compléter l'info: il existe une astuce qui consiste à ouvrir le fichier en lecture avec 'rU': dans ce cas, chaque ligne est renvoyée avec la fin de ligne '\n' pour tous les systèmes d'exploitation. Ceci pour favoriser les programmes multiplateformes.

Tyrtamos

Tyrtamos, pour mettre en évidence que « Python fait son boulot », c'est à dire que « les fins de ligne de chacun des systèmes d'exploitation sont correctement reconnus » dans une chaîne, il n'est pas nécessaire de passer par une écriture et une lecture dans un fichier. Le code suivant suffit:
Code:

1 2 3 4 5 for u in ("toto\r\ntoto\r\ntoto\r\n", "toto\ntoto\ntoto\n", "toto\rtoto\rtoto\r"): print '\n',repr(u),'\n',' '.join(str(ord(x)) for x in u if x not in 'to') print "count('\\r\\n') =",u.count('\r\n'),\ "\ncount('\\n') =",u.count('\n'),\ "\ncount('\\r') =",u.count('\r')
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 'toto\r\ntoto\r\ntoto\r\n' 13 10 13 10 13 10 count('\r\n') = 3 count('\n') = 3 count('\r') = 3 'toto\ntoto\ntoto\n' 10 10 10 count('\r\n') = 0 count('\n') = 3 count('\r') = 0 'toto\rtoto\rtoto\r' 13 13 13 count('\r\n') = 0 count('\n') = 0 count('\r') = 3
Il est même déconseillé de passer par une écriture et une lecture d'un fichier, parce que c'est offrir à des bizarreries dues aux écriture-lecture d'un fichier la possibilité de venir perturber la démonstration.

Parmi ces bizarreries, j'en connais deux lorsqu'on est sous Windows:

1) Windows a une façon particulière d'écrire un fichier sur disque en mode 'w' : c'est un effronté qui n'en fait qu'à sa tête, il ajoute systématiquement un '\r' devant tout '\n' qu'il rencontre dans une chaîne dans une instruction write() en mode 'w': il fait de tous les caractères '\n' des fins de ligne Windows '\r\n', même quand ces '\n' sont placés devant des '\r'.

2) À la lecture, les '\r\n' sont transformés en '\n'.

J'ai cru un temps que c'était la fonctionnalité Universal Newline Support de Python qui était responsable de cette transformation, en étant active par défaut.
Mais j'avais tort, j'avais mal compris les docs, qui ne sont pas d'une grande clarté.

La fonctionnalité Universal Newline Support permet de faire transformer n'importe quel type de fin de ligne ('\n' ou '\r' ou '\r\n' ) rencontrée par Python lors la lecture d'un fichier, en '\n'.
Mais ceci n'a lieu que si on spécifie un mode 'rU' de lecture, cette fonctionnalité n'est active que si on place cette indication dans le code.

Cette fonctionnalité Universal Newline Support peut être débranché lors de la compilation d'un code Python:

Citation:

This feature can be disabled when compiling Python by specifying the --without-universal-newlines switch when running Python's configure script.

http://www.python.org/dev/doc/maint2...new/node7.html

Elle n'est alors plus disponible.

En absence de ce débranchement, elle est disponible, ce qui ne veut pas dire qu'elle est active et que toute lecture se fera en 'rU' par défaut.
Au contraire, il faudra bien spécifier une indication 'rU' comme mode de lecture lorsqu'on voudra activer cette fonctionnalité pour la lecture d'un fichier donné.
C'est ce que je n'avais pas compris mais que j'ai fini par éclaircir. Je pense donc maintenant que la transformation des '\r\n' en '\n' est le fait de Windows et non de Python.

La preuve en est que si l' Universal Newline Support était impliqué dans cette transformation, les fins de lignes '\r' seraient aussi transformées en '\n'. Or ce n'est pas le cas.

Ces deux bizarreries sont mises en évidence dans le code suivant
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 print repr("TOTO\r\n TUTU\n TITI\r"),', chaine écrite dans un fichier selon deux modes' print "\n1/ après écriture en mode'wb'" f = open("testW.txt", 'wb') f.write("TOTO\r\n TUTU\n TITI\r") f.close() f = open("testW.txt", 'rb') print repr(f.read()),"\t: sa lecture en mode 'rb'" f.close() f = open("testW.txt", 'r') print repr(f.read()),"\t: sa lecture en mode 'r'" f.close() f = open("testW.txt", 'rU') print repr(f.read()),"\t: sa lecture en mode 'rU'" f.close() #------------------------------------------------------------------ print print "2/ après écriture en mode'w'" f = open("testW.txt", 'w') f.write("TOTO\r\n TUTU\n TITI\r") f.close() f = open("testW.txt", 'rb') print repr(f.read()),"\t: sa lecture en mode 'rb'" f.close() f = open("testW.txt", 'r') print repr(f.read()),"\t: sa lecture en mode 'r'" f.close() f = open("testW.txt", 'rU') print repr(f.read()),"\t: sa lecture en mode 'rU'" f.close()
qui donne, sous Windows (mon cas):
Code:

1 2 3 4 5 6 7 8 9 10 11 'TOTO\r\n TUTU\n TITI\r' , chaine écrite dans un fichier selon deux modes 1/ après écriture en mode'wb' 'TOTO\r\n TUTU\n TITI\r' : sa lecture en mode 'rb' 'TOTO\n TUTU\n TITI\r' : sa lecture en mode 'r' 'TOTO\n TUTU\n TITI\n' : sa lecture en mode 'rU' 2/ après écriture en mode'w' 'TOTO\r\r\n TUTU\r\n TITI\r' : sa lecture en mode 'rb' 'TOTO\r\n TUTU\n TITI\r' : sa lecture en mode 'r' 'TOTO\n\n TUTU\n TITI\n' : sa lecture en mode 'rU'
Il en résulte que le code avancé par Tyrtamos donne les résultats attendus pour vérifier «que Python fait son boulot»,
mais si on est sous Windows, on ne s'aperçoit pas que Windows fait le sien en catimini, ce qui se passe dans un sens lors de l'écriture se défaisant à la lecture.

Je prends le cas du code concernant les newlines de Linux. Étant sous Windows:
f.write("toto\n") en mode 'w' écrit 'toto\r\n' sur le disque
la lecture en mode 'r' récupère 'toto\n' dans une chaîne
Si on décompte les '\n' , le compte est bon: 1. Mais on n'y a vu que du feu.

Ne sachant pas ce qui se passe en coulisse, on sera alors très perplexe si on a la lubie ou le besoin de vouloir utiliser les fonctions seek() et tell() pour se déplacer dans un fichier et y faire des modifications. Le nombre de caractères trouvés dans une chaîne lue ne corespondra pas au nombre de caractères dont on aura fait déplacer le pointeur de fichier avec seek() , si le déplacement est passé au dessus de fins de lignes.

La connaissance de ce micmac en coulisses permet par contre de te répondre, hdgetnet:

Citation:

res = -1 alors que mon fichier contient bien des '\r\n' vu avec notepad++ (CRLF)
pourqoui?

Parce que tu dois être sous Windows et que cet OS transforme toutes les fins de lignes '\r\n' en '\n' lors de la lecture en mode 'r'.

Fais ce qu'a indiqué dividee dans le message #5 et tu ne devrais alors plus observer le problème:

Citation:

Pour le problème des fins de lignes qui ne sont pas trouvées, il faudrait peut-être utiliser le mode d'ouverture "rb" plutôt que "r". Ouvrir le fichier en mode binaire empêche Python d'interpréter les fins de lignes en fonction de l'OS...

Par contre je ne suis pas d'accord avec sa dernière phrase: je ne crois pas que Python interprète les fins de ligne en fonction de l'OS quand le mode de lecture est 'r'. Cela semble faire référence au Universal Newline Support, mais comme on l'a vu celui-ci n'est actif que si on fait ce qu'il faut pour ( un mode 'rU').

Que signifie « en fonction de l'OS » d'ailleurs ? Est-ce ce qui explique que sous Windows, les '\r\n' lus sont transformés en '\n' et seulement ces fins de ligne '\r\n' puisque les '\r' ne sont pas touchées ? Est-ce à dire que Python doit à la fois détecter quelle est l'OS et en tenir compte pour changer certaines fins de lignes et pas d'autres ?.....
Je ne suis certain de rien mais je n'y crois pas.Je pense que c'est l'OS Windows qui fait ses petites nagouilles tout seul.

Je crois que Linux ne s'amuse pas à faire ces changements de fins de ligne: il lit et écrit les chaînes strictement comme elles sont. Je crois que c'est ce que j'ai lu je ne sais où.
Ce qui voudrait dire dans ce cas, que si Python n'interprète pas les fins de ligne, comme je le crois, quelqu'un qui sera sous Linux ne devrait pas obtenir le problème que tu observes avec ton code sur ta machine, hdgetnet.
Il serait intéressant d'avoir un retour sur ce point.
Et pour Mac aussi.

Bonjour,

Citation:

Envoyé par eyquem

Tyrtamos, pour mettre en évidence que « Python fait son boulot », c'est à dire que « les fins de ligne de chacun des systèmes d'exploitation sont correctement reconnus » dans une chaîne, il n'est pas nécessaire de passer par une écriture et une lecture dans un fichier....

Et si, justement, je voulais un test global incluant les lectures/écritures!

Citation:

Envoyé par eyquem

Windows a une façon particulière d'écrire un fichier sur disque en mode 'w' : c'est un effronté qui n'en fait qu'à sa tête, il ajoute systématiquement un '\r' devant tout '\n' qu'il rencontre dans une chaîne dans une instruction write() en mode 'w': il fait de tous les caractères '\n' des fins de ligne Windows '\r\n', même quand ces '\n' sont placés devant des '\r'.

Et oui, tu as raison. Je m'en étais aperçu un jour que je récupérais un texte qui avait de ce fait un saut de ligne de trop dans un éditeur de texte.

Avec mon test ci-dessus, on le voit quand on examine le fichier écrit avec un éditeur hexa (comme EditHexa sous Windows): à chaque '\n' envoyé, un '\r' est envoyé avant. Ce qui fait que la fin de ligne envoyée par write '\r\n' devient sur le disque '\r\r\n'. Et le '\r' surabondant est retiré à la lecture par readline.

Si au lieu d'écrire en mode 'w' on écrit en mode binaire 'wb', la fin de ligne sur disque est bien ce qu'on a envoyé ('\r\n'), mais, bien sûr, en lecture, on perd le '\r' et on n'a plus que la fin de ligne '\n'.

Ce n'est pas un comportement très logique, et je ne sais pas si c'est Python ou Windows qui fait ça. D'ailleurs, si je crée un nouveau texte avec un éditeur comme notepad++, il me met les fins de ligne demandées sans discuter, et je peux le vérifier sur disque.

Cela peut d'ailleurs expliquer pourquoi hdgetnet ne trouve pas le '\r\n' avec count: si l'éditeur qui a crée le code C a mis le bon '\r\n', Python a supprimé le '\r' en lecture et n'a laissé passer que le '\n'.

Donc, pour répondre au problème posé (changement des fins de ligne de Windows à Linux), la méthode est:

1- lecture en mode texte, et suppression de la fin de ligne avec rstrip()

2- écriture de chaque ligne en mode binaire 'wb' avec la fin de ligne '\n'.

Ce qui donnerait comme code quelque chose comme ça:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 print "conversion des fins de ligne Windows => Unix" L = [] f = open("testFDL_W.c", 'r') for ligne in f: L.append(ligne.rstrip()) f.close() f = open("testFDL_U.c", 'wb') for ligne in L: f.write(ligne + '\n') f.close()
Le fichier testFDL_W.c comportant des fins de ligne Windows (ou n'importe quoi d'autre d'ailleurs) donne un fichier testFDL_W.c ne comportant que des fins de ligne Unix.

Tyrtamos

Bonjour à tous
Merci de votre participation qui a permit de résoudre mon pb

voici le bout de code

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import os
 
Rep_courant = os.getcwd()
print Rep_courant
ls = os.listdir(Rep_courant)                        # Liste tous les fichiers du rep courant
LsFichierC = [e for e in ls if e.endswith('.c')]    # on cherche dans le dossier tous les fichier c
for ChaqueFichier in LsFichierC:
    print ChaqueFichier
    FichierCourant = open(ChaqueFichier,'rb')
    LitContenu = FichierCourant.read()
    LitContenu = LitContenu.replace('\r\n','\n')    # On remplace '\r\n' par '\n'
    FichierCourant.close()
##  Sauvegarde des modifications
    FichierCourant = open(ChaqueFichier,'wb')
    FichierCourant.write(LitContenu)
    FichierCourant.close()

18/03/2010, 21h33
dividee

La comportement de open en Python dépend sans doute de celui de fopen de la bibliothèque C utilisée pour compiler CPython:

Sur MSDN, on trouve ceci pour la fonction fopen (http://msdn.microsoft.com/en-us/libr...cb(VS.71).aspx):

Citation:

Also, in text mode, carriage return–linefeed combinations are translated into single linefeeds on input, and linefeed characters are translated to carriage return–linefeed combinations on output.

Ainsi que

Citation:

b Open in binary (untranslated) mode; translations involving carriage-return and linefeed characters are suppressed.

Sur la page de manuel de la fonction de fopen (en Linux donc), il est dit que le mode "b" est ignoré (http://www.linux-kheops.com/doc/man/...3/fopen.3.html).

J'ai déjà eu un problème lié à cela en Python. Un code, normalement portable, mais écrit en Linux ne prenait pas la peine d'ouvrir des fichiers binaires (des images) en précisant le "b", car il n'a pas d'effet en Linux. Sous Windows, cela donnait une image corrompue...