Discussion :

[tyrtamos]

Bonjour,

Je fais une application qui, à un moment donné, sauvegarde des données "texte" sur disque. Et cette application doit être multi-plateforme (Windows, Linux et mac au moins).

J'utilise donc os.linesep comme séparateur de ligne. Voilà un petit exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
#!/usr/bin/python
# -*- coding: utf-8 -*-
 
import os
 
x=0.160861702033834
y=0.443963995843483
z=0.732024303279896
 
chemin=os.getcwd() + os.sep + "resultat.txt"
try:
    f=open(chemin,'w')
    try:
        f.write("%r" % x + os.linesep)
        f.write("%r" % y + os.linesep)
        f.write("%r" % z + os.linesep)
    except:
        print "Erreur", "impossible d'ecrire dans le fichier resultat.txt"
    f.close()
except:
    print "Erreur", "impossible d'ouvrir le fichier resultat.txt en ecriture"

J'examine ensuite le fichier ainsi écrit avec un éditeur hexadécimal.

Sous Linux, pas de problème, il y a bien "\n" d'ajouté en fin de ligne (0A en hexa)

Par contre, sous Windows, os.linesep contient bien "\r\n" comme il se doit, mais le ,"\n" se traduit à lui tout seul par "\r\n", ce qui fait que j'ai "\r\r\n" comme séparateur de ligne (0D 0D 0A en hexa).

D'ailleurs, si au lieu d'utiliser os.linesep j'utilise directement "\r\n", cela donne la même chose: "\n" se dédouble automatiquement en "\r\n". Ce n'est donc pas un problème spécifique à os.linesep.

Je pourrais donc utiliser seulement "\n" (qui me donne bien "\r\n" sous Windows et "\n" sous Linux), mais je tiens au caractère multiplateforme (ça doit aussi fonctionner sur mac).

Donc: comment puis-je empêcher que le Python sous Windows me transforme automatiquement "\n" en "\r\n" dans l'écriture de fichiers sur disque?

Merci d'avance!

Tyrtamos

[edit]: d'après ce que je lis ici: http://mail.python.org/pipermail/pyt...ay/038360.html, c'est un bug. Il suffit d'ouvrir en écriture binaire ("wb") pour que ça marche (j'ai vérifié, c'est ok). Par contre, je ne sais pas ce que ça donne avec les différents encodages. Si quelqu'un a de l'expérience sur le sujet?

[oiffrig]

A priori c'est écrit dans le fichier avec l'encodage de la chaîne. En tout cas chez moi (ubuntu hardy) si je lui demande de l'UTF-8 il écrit en UTF-8, iso-8859-15 est en iso-8859-15 donc il ne devrait pas y avoir de problème.

[tyrtamos]

Merci oiffrig,

Effectivement, que j'ouvre en "w" ou en "wb", c'est pareil:


- si je ne mets aucune demande de changement d'encodage, ce qui est enregistré correspond à l'encodage du code source.

---> source latin1 => enregistrement latin1 (exemple: "é" -> E9)

---> source utf-8 => enregistrement utf-8 (exemple: "é" -> C3 A9)


- si je change l'encodage volontairement, ce qui est enregistré correspond à ce que j'ai demandé.

---> source latin1 et "é".encode('utf-8') => enregistrement utf-8 (exemple: "é" -> C3 A9)

---> source utf-8 et "é".encode('latin1') => enregistrement latin1 (exemple: "é" -> E9)


Et si je veux que le fichier soit reconnu comme un fichier utf-8 par les éditeurs de texte, il faut que je commence par envoyer le "BOM" en début de fichier:

Code :

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

f.write("%c%c%c" % (0xEF,0xBB,0xBF))

Ouf... Ces pb d'encodage sont un vrai casse-tête

Problème résolu.

Merci!

Tyrtamos