Discussion :

[gratiert]

Bonjour,

Je rencontre un problème très simple mais je ne suis pas arrivé à le résoudre de manière simple.
Mon intention était d'enchainer des "rechercher-remplacer" sur un fichier mais je rencontre un problème avec les guillemets doubles.
Le "rechercher-remplacer" ne fait pas le travail comme je l'attendais : il ne remplace rien

Mon code fonctionne sous Linux

Code :

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

1
2
3
4
5
6
7
8
9
10
 
f = open("monfichier.sql")
o = open("output.sql","a")
while 1:
  line = f.readline()
  if not line: break
  line = line.replace("DateTime","date")
  line = line.replace("\"","")
  o.write(line + "\n")
o.close()

Je dois rester sous Windows car je ne peux pas changer de système d'exploitation : j'ai d'autres traitements spécifiques à Windows (plus précisément du Access)

Des solutions pour avoir un script "windows" compatible?

Merci de vos réponses et d'éviter de "troller" (je suis pro "nunux" mais je fais avec les infrastructures existantes...)

gratiert

[PauseKawa]

Bonjour gratiert,

Code :

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

1
2
3
4
5
6
7
8
9
f = open('monfichier.sql', 'r')
o = open('output.sql', 'w')
while 1:
  line = f.readline()
  if not line: break
  line = line.replace('DateTime', 'date')
  line = line.replace('\\', '')
  o.write(line)
o.close()

A noter que tu vas te retrouver dans le même cas avec les chemins Windows :
"C:\\\WINDOWS\\System"

@+

[gratiert]

Bonjour,

Merci de votre réponse PauseKawa. Malheureusement, votre proposition ne semble pas prendre en compte ma demande rechercher-remplacer de guillemets doubles.
Je pense après m'être relu ne pas avoir été assez clair

Mon fichier en entrée contient un truc du genre

Code :

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

rtetereretet "fvhhvghhvhgv" gdfhfdfhg "ghdsghdhgds" fdfdgdd "tyy"

La sortie souhaitée est

Code :

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

rtetereretet fvhhvghhvhgv gdfhfdfhg ghdsghdhgds fdfdgdd tyy

La ligne dans mon code qui ne fonctionne pas comme je l'attend est

Code :

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

line = line.replace("\"","")

Merci encore

gratiert

[rambc]

Bonjour.

Ne serait-ce pas plus simple de taper ce qui suit ?

Code :

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

line = line.replace('"','')

[gratiert]

Bonjour,

J'avais déjà testé, la syntaxe est plus simple mais le résultat du traitement est le même : rien n'a été remplacé dans mes guillemets.
Je deviens "fou" : je bloque dessus ce problème depuis hier sur ce qui est ou parait être un détail!!

Merci pour votre réponse

gratiert

PS : ma version de python est la 2.6.5

[eyquem]

Bonjour,


Hier soir, à l’œil , je n’ai rien vu qui puisse expliquer le comportement que tu décris. Pour moi, il n’y a rien d’incorrect dans ton code.

Ce matin je l’ai fait tourner, avec deux fichiers nommés exactement comme dans ton code, et j’ai bien obtenu le recopiage du premier à la fin du second sans les “

Écrire

Code :

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

 "\"" ou '"'

revient au même et il est cohérent d’apprendre que ça ne change rien.

Cohérent mais incompréhensible pour moi.





Le code que tu fais effectivement tourner est-il bien à celui que tu as posté ? Ou l’as tu réduit pour poster un code plus court ?

Quelle version de Python utilises tu ?

Comment utilises tu Python ? Avec IDLE? En fenêtre Shell Python ? En fenêtre MS-DOS ? En association avec d’autres langages ou logiciels ?

[tyrtamos]

Bonjour,

Je suis d'accord avec rambc, et chez moi, ça marche:

Code :

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

1
2
3
4
 
line = 'rtetereretet "fvhhvghhvhgv" gdfhfdfhg "ghdsghdhgds" fdfdgdd "tyy"'
print line.replace('"','')
rtetereretet fvhhvghhvhgv gdfhfdfhg ghdsghdhgds fdfdgdd tyy

Il doit y avoir autre chose. Pb d'encodage?

Tyrtamos (python 2.6.4)

[gratiert]

Bonjour,

J'en perd mon latin. Cela fonctionne maintenant.
Je me suis contenté de mettre à jour ma version de python (2.6.4 à 2.6.5).
Je travaillais pour info avec un fichier test.py exécuté via python test.py
Le pire c'est pas que ça n'ai pas fonctionné à un moment mais que je doute encore de la provenance de l'erreur : je ne pense pas que ça vienne de "l'upgrade"

Merci encore, je marque comme résolu.

gratiert

[rambc]

Il doit y avoir autre chose. Pb d'encodage

C'est à peu près certain. Le fichier vient de Linux, et tu travailles sous Windows, et il y a fort à parier qu'il y a un souci d'encodage derrière.

Ton fichier peut-il se lire avec quelque chose comme NotePad++ afion de récupérer l'encodage du fichier ?

Comment ton fichier a-t-il été construit ? Sur quel OS ?

[eyquem]

Tant mieux. Et dommage qu’on n’ait pas réussi à trouver la cause du problème.

On peut penser que c’était un de ces bugs corrigés dans la version 2.6.5:

Python 2.6.5 release
Python 2.6.5 is a maintenance release for Python 2.6.4, fixing dozens of issues in the core, builtin modules, libraries, and documentation. Python 2.6.5 final was released on March 19, 2010.

http://www.python.org/download/releases/2.6.5/

Il faudrait se replacer sous Python 2.6.4 pour voir si le problème revient.

EDIT
Je m’étais trompé deux fois dans la fin de ce post. L’erreur la plus importante étant que Python 2.6.4 n’est plus du tout télécheargeable.
À moins que je ne sache pas regarder sur le site python.org.

[eyquem]

Pour analyser un peu le problème, il aurait été possible de voir ce que donne

Code :

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

1
2
3
4
5
6
def oq(x):
    return ch, map(ord,ch), ’\n’
 
print oq('A"B\C')
 
print oq("A\"B\C")

En 2.6.5, ça donne:

Code :

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

1
2
A"B\C [65, 34, 66, 92, 67] 
A"B\C [65, 34, 66, 92, 67]

“ a pour code ASCII 34
\ a pour code ASCII 92

Ces codes étant ceux de l’ASCII de base (codes de 0 à 127), je ne vois pas comment un problème d’encodage pourrait être mêlé à ce qui était observé, car toutes les tables de codages comportent les mêmes correspondances caractères-code pour les codes 0 à 127. Du moins étant donné ce que j’ai compris, pour lequel je ne mettrais pas ma main au feu.

Cependant, il est vrai qu’à part un problème d’encoding, je ne vois pas non plus ce qui pourrait être en cause. Je me dis alors qu'il doit bien exister des codages , créés avant Unicode, dans lesquels les nombres 0 à 127 ne se préoccupaient pas de caractères latins: un codage de langue asiatique , un hébreu non 8859-8 si ça existe.... je ne sais quoi exactement .....

Il faudrait savoir quel sorte de texte tu traites , gratiert.

Je n’aime pas les mystères qui persistent.

[tyrtamos]

Comme l'EBCDIC d'IBM par exemple.

http://shop.alterlinks.com/ascii-tab...-ebcdic-fr.php

Tyrtamos

[gratiert]

Bonsoir,

Pour info, je suis seulement sous Windows dans ce cas (mon test Linux était pour voir si c'était un problème d'OS)
Mon fichier d'entrée est un ANSI et celui de sortie est un UTF-8 (SANS BOM)
La langue utilisée au niveau du contenu n'est pas très "exotique" : français avec accents.
Les données que je récupère viennent de Access via ce snippet http://code.activestate.com/recipes/...jet-databases/ car j'ai besoin de faire du reverse engineering en gardant les relations, ce que permet Jet contrairement à ODBC.

Sinon merci des compléments apportés pour mieux débugger

gratiert

[eyquem]

Bien vu tyrtamos.

En évoquant un codage n’ayant pas les mêmes correspondances que l’ASCII dans la plage de codes 0-127, je n’avais en fait aucun exemple en tête. Ta remarque en fournit un.
J’ai lu que c’est d'ailleurs le seul:
http://czyborra.com/charsets/iso646.html



De plus, ta remarque m'a conduit à la solution.





---------------------------------------



Ayant vu que map(ord,'A"B\C') vaut [65, 34, 66, 92, 67] et que le byte de codage de " est donc 34 dans mon code Python,
j’ai eu la curiosité de regarder dans la page web donnée par tyrtamos quel est le caractère que code 34 dans la table de codage EBCDIC



Les colonnes de codes y sont
col 1 = Décimal ASCII .......col 2 = Hexadécimal ASCII .......col 3 = Hexadécimal EBCDIC
On y trouve une ligne

Code :

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

"    34    22    7F

qui indique bien un code ASCII-décimal de 34 pour ".



Et ensuite, coup de bol: je me suis trompé !
J’ai pensé: « 34 en décimal c’est aussi 34 en hexadécimal » et j’ai cherché 34 dans la colonne EBCDIC donnée en hexadécimal.
En fait 34 Hexa vaut 52 en décimal et le signe que j’ai trouvé dans la colonne EBCDIC est donc codé par 34 Hexa = 52 décimal.

Coup de bol + coïncidence: ce signe codé par 34 Hexa en EBCDIC est aussi un guillemet ! :

Code :

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

”     148    94    34

... et j’ai failli en rester là en me disant « Tiens, ASCII et EBCDIC codent tous les deux " par le nombre 34 ».


Mais un soupçon m’a traversé la cervelle: pourquoi le même caractère a-t-il deux codes aussi bien en ASCII qu’en EBCDIC ?

En regardant de plus près, et il faut pour cela copier-coller et agrandir les caractères, on s’aperçoit de ceci

Code :

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

1
2
3
4
5
6
"      34    22    7F 
'      39    27    7D 
‘     145    91    31 
’     146    92    1A 
“     147    93    33 
”     148    94    34 

C’est à dire que
le caractère codé par 34 en ASCII est un double quote = guillemet droit ,
mais
il existe en outre des guillemets courbes , dits ’anglais’ ou ’directional double quotation marks’ ( http://en.wikipedia.org/wiki/ISO/IEC_8859 ) , qui ont pour codes 147 et 148 dans la colonne ASCII de la page web donnant ce transcodage avec EBCDIC.

Idem pour les apostrophes.

En fait selon la police de caractères, les glyphes de ces guillemets et apostrophes apparaissent courbes (en Times New Roman par exemple) ou bien rectilignes-inclinés (comme dans les posts).



Résumé de ce que j’ai collecté comme appellations pour les guillemets et les apostrophes:

" guillemet droit = double quote = petit guillemet = guillemet dactylographique
' apostrophe droite = simple quote = guillemet droit simple = apostrophe dactylographique

‘ apostrophe typographique culbutée = guillemet anglais simple ouvrant
’ apostrophe typographique = guillemet anglais simple fermant
“ guillemet anglais double ouvrant
” guillemet anglais double fermant

Nota Bene:

L’appellation ASCII pour les codes 128 à 255
tel qu'il se trouve dans la page
http://shop.alterlinks.com/ascii-tab...-ebcdic-fr.php
en question, qui donne le transcodage entre un prétendu ASCII et EBCDIC,
est erronée et fautive.
Il s’agit en fait d’ASCII étendu, terme fourre-tout qui désigne de façon imprécise tout système de codage de caractères basé, pour les codes 0 à 127, sur l’ASCII stricto sensu (dit aussi US-ASCII) auquel ont été ajoutés des correspondances pour les codes 128 à 255 variables selon le système concerné.
Cette page manque totalement de rigueur en se contentant de nommer ASCII ce qui doit être justement de l’ANSI parce qu’il y a ces guillemets et apostrophes courbes (cf plus loin).



---------------------------------




Comme tu dis que le texte en entrée est en ANSI, j’ai examiné le charset ANSI.

ANSI est une extension d'ISO-8859-1, qui rajoute un certain nombre de caractères: «e dans l'o», symbole de l'Euro, mais aussi guillemets anglais, points de suspension, signe «pour mille», tirets cadratin et demi-cadratin, etc. En tout, cela représente 218 caractères imprimables. Dans les années 90, Microsoft adopte ANSI pour son système d'exploitation Windows. Aujourd'hui, quand on parle d'ANSI, on parle en fait

En CP-1252 = ANSI, les guillemets sont codés ainsi:
" 22 Hexa ( = 34 décimal)
“ 93 Hexa ( = 147 décimal)
” 94 Hexa ( = 148 décimal)
http://fr.wikipedia.org/wiki/Windows-1252

Au départ de la construction de la série des encodages ISO 8859 qui étendent l’ASCII 7 bits aux différentes langues européennes (et même au Thai), les guillemets courbes anglais n’ont pas été inclus:

As a rule of thumb, if a character or symbol was not already part of a widely used data-processing character set and was also not usually provided on typewriter keyboards for a national language, it didn't get in. Hence the directional double quotation marks « and » used for some European languages were included, but not the directional double quotation marks “ and ” used for English and some other languages.

http://en.wikipedia.org/wiki/ISO/IEC_8859

C’est sans doute pour combler des manques de ce genre quei Microsoft a sorti son encodage CP-1252, qui me semble être l’un des seuls à coder les guillemets et apostrophes courbes.








Or à partir de Python 2.3 et jusqu’à Python 3, l’encodage par défaut de Python était l’ASCII:

PEP: 0263
Title: Defining Python Source Code Encodings
Author: mal@lemburg.com (Marc-André Lemburg),
martin@v.loewis.de (Martin von Lœwis)

Created: 06-Jun-2001
Python-Version: 2.3


Defining the Encoding

Python will default to ASCII as standard encoding if no other
encoding hints are given.

To define a source code encoding, a magic comment must
be placed into the source files either as first or second
line in the file

http://www.python.org/dev/peps/pep-0263/

PEP: 3120
Title: Using UTF-8 as the default source encoding
Author: Martin von Lœwis <martin@v.loewis.de>
Created: 15-Apr-2007
Python-Version: 3.0


This PEP proposes to change the default source encoding from ASCII to UTF-8.
(...)
In Python 1, the source encoding was unspecified, except that the source encoding had to be a superset of the system's basic execution character set (i.e. an ASCII superset, on most systems).
(...)
In Python 2.0, the source encoding changed to Latin-1 as a side effect of introducing Unicode.
(...)
PEP 263 identified the problem that you can use only those Unicode characters in a Unicode literal which are also in Latin-1,
and introduced a syntax for declaring the source encoding. If no source encoding was given, the default should be ASCII.
For compatibility with Python 2.0 and 2.1, files were interpreted as Latin-1 for a transitional period. This transition ended with Python 2.5, which gives an error if non-ASCII characters are encountered and no source encoding is declared.
(...)
With PEP 263, using arbitrary non-ASCII characters in a Python file is possible, but tedious. One has to explicitly add an encoding declaration.
(...)
For Python 2, an important reason for using non-UTF-8 encodings was that byte string literals would be in the source encoding at run-time, allowing then to output them to a file or render them to the user as-is.
With Python 3, all strings will be Unicode strings, so the
original encoding of the source will have no impact at run-time.

The parser needs to be changed to accept bytes > 127 if no source encoding is specified; instead of giving an error, it needs to check that the bytes are well-formed UTF-8 (...)
IDLE needs to be changed to use UTF-8 as the default encoding.

http://www.python.org/dev/peps/pep-3120/

Ces deux PEP ont été acceptées et implémentées (status = Final):
http://www.python.org/dev/peps/pep-0000/









Par ailleurs, dans les docs officielles de Python, le terme ASCII est employé dans son sens rigoureux de système originel de codage sur 7 bits = limité aux codes 0-127:

In 1968, the American Standard Code for Information Interchange, better known by its acronym ASCII, was standardized. ASCII defined numeric codes for various characters, with the numeric values running from 0 to 127.
(...)
In the 1980s, almost all personal computers were 8-bit, meaning that bytes could hold values ranging from 0 to 255. ASCII codes only went up to 127, so some machines assigned values between 128 and 255 to accented characters. Different machines had different codes, however, which led to problems exchanging files. Eventually various commonly used sets of values for the 128-255 range emerged. Some were true standards, defined by the International Standards Organization, and some were de facto conventions that were invented by one company or another and managed to catch on.

http://docs.python.org/howto/unicode.html

Aussi est-il probable, du fait que le texte en entrée est en ANSI = CP-1252 et que Python déclencherait une erreur si son encodage était celui par défaut (ASCII 7 bits), que CP-1252 est l’encodage spécifié pour ton code Python.

• Donc d’un coté il doit y avoir des guillemets courbes qui arrivent en entrée dans ton texte ANSI et qui sont pris correctement en charge par ton code avec l’encodage ANSI.
  
  
• Par contre, d’un autre coté, le guillemet indiqué dans ton code Python dans replace("\"","") est certainement un quote double droit, parce que ton clavier envoie sans doute un byte 34 quand on appuie sur la touche "

Par conséquent, quand le programme exécute l’instruction line = line.replace("\"","") , il cherche des bytes 34 et ne réagit aucunement sur les bytes 147 et 148 qui se trouvent dans le texte traité.

J'en perd mon latin. Cela fonctionne maintenant.

À mon avis , ce nouveau mystère n’est pas dû à l’upgrade de 2.6.4 à 2.6.5
Tu as sans doute copié un guillemet courbe dans replace("\"","") sans t’en rendre compte, ou tu as transporté le fichier d'entrée dans une texte où il a perdu ses guillemets courbes.






En somme le problème que tu as rencontré est dû à la difficulté de différencier des glyphes visuellement proches de caractères différents, comme dans cet exemple:

The symbol for ohms (Ω) is usually drawn much like the capital letter omega (Ω) in the Greek alphabet (they may even be the same in some fonts), but these are two different characters that have different meanings.

http://docs.python.org/howto/unicode.html

[nadily]

[



pour les doubles guillemets tu fais alt 174 et pour fermer alt 175 voila
tu dois laisser le doigt appuyé sur alt !!et taper les chiffres en même temps donc tape alt 174 pour ouvrir et alt 175 pour fermer ...


B][/B]

Bonjour,

Je rencontre un problème très simple mais je ne suis pas arrivé à le résoudre de manière simple.
Mon intention était d'enchainer des "rechercher-remplacer" sur un fichier mais je rencontre un problème avec les guillemets doubles.
Le "rechercher-remplacer" ne fait pas le travail comme je l'attendais : il ne remplace rien

Mon code fonctionne sous Linux

Code :

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

1
2
3
4
5
6
7
8
9
10
 
f = open("monfichier.sql")
o = open("output.sql","a")
while 1:
  line = f.readline()
  if not line: break
  line = line.replace("DateTime","date")
  line = line.replace("\"","")
  o.write(line + "\n")
o.close()

Je dois rester sous Windows car je ne peux pas changer de système d'exploitation : j'ai d'autres traitements spécifiques à Windows (plus précisément du Access)

Des solutions pour avoir un script "windows" compatible?

Merci de vos réponses et d'éviter de "troller" (je suis pro "nunux" mais je fais avec les infrastructures existantes...)

gratiert