Lorsque je mets des accents dans mes chaines de caractères, j'ai un warning généré par python. Normal.
J'aimerais supprimer ce warning mais je n'y arrive pas.
Je suis sous windows. J'utilise Eclipse 3.1 avec le plug-in PyDev.
Je mets le commentaire qui va bien au début de mon fichier pour dire que j'ai des caractères de type UTF-8. J'enregistre mon fichier au format UTF-8 (ou du moins je pense que c'est le cas). J'ai bien mes caractères accentués dans le fichier source mais à l'exécution j'ai 2 caractères bizarres à chaque lettre accentuée. Je suppose que ces deux caractères correspondent au code UTF-8 non "décodé". Ce qui est étrange c'est que dès que je mets le commentaire de type d'encodage au début du fichier, Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage. Comme si Eclipse connaissait cette "instruction". Peut-être que c'est PyDev qui fait ça ?
Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une solution ?
dès que je mets le commentaire de type d'encodage au début du fichier, Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage. Comme si Eclipse connaissait cette "instruction". Peut-être que c'est PyDev qui fait ça ?
Le format dans lequel est écrit le codage de caractères est une convention aussi connue de vim et emacs.
Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une solution ?
Il y a longtemps, à l'école, quand j'écrivais des programmes C qui imprimait des accents dans un terminal "DOS" sous Windows. :-)
Je ne me souviens pas pour un script Python exécuté dans la même console de m***e mais il est possible que ce vieil âne têtu n'en fasse qu'à sa tête et refuse de prendre autre chose en compte que son codage de caractères propriétaire, dont le nom pour Python doit être windows-1252 ou cp-1252. Problème de portabilité en vue si tu l'utilises...
-- Hervé Cauwelier http://www.oursours.net/
dès que je mets le commentaire de type d'encodage au début du fichier,
Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage.
Comme si Eclipse connaissait cette "instruction". Peut-être que c'est
PyDev qui fait ça ?
Le format dans lequel est écrit le codage de caractères est une
convention aussi connue de vim et emacs.
Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une
solution ?
Il y a longtemps, à l'école, quand j'écrivais des programmes C qui
imprimait des accents dans un terminal "DOS" sous Windows. :-)
Je ne me souviens pas pour un script Python exécuté dans la même console
de m***e mais il est possible que ce vieil âne têtu n'en fasse qu'à sa
tête et refuse de prendre autre chose en compte que son codage de
caractères propriétaire, dont le nom pour Python doit être windows-1252
ou cp-1252. Problème de portabilité en vue si tu l'utilises...
dès que je mets le commentaire de type d'encodage au début du fichier, Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage. Comme si Eclipse connaissait cette "instruction". Peut-être que c'est PyDev qui fait ça ?
Le format dans lequel est écrit le codage de caractères est une convention aussi connue de vim et emacs.
Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une solution ?
Il y a longtemps, à l'école, quand j'écrivais des programmes C qui imprimait des accents dans un terminal "DOS" sous Windows. :-)
Je ne me souviens pas pour un script Python exécuté dans la même console de m***e mais il est possible que ce vieil âne têtu n'en fasse qu'à sa tête et refuse de prendre autre chose en compte que son codage de caractères propriétaire, dont le nom pour Python doit être windows-1252 ou cp-1252. Problème de portabilité en vue si tu l'utilises...
-- Hervé Cauwelier http://www.oursours.net/
nico
dès que je mets le commentaire de type d'encodage au début du fichier, Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage. Comme si Eclipse connaissait cette "instruction". Peut-être que c'est PyDev qui fait ça ?
Le format dans lequel est écrit le codage de caractères est une convention aussi connue de vim et emacs.
Après un peu de recherches, c'est PyDev (version récente) qui fait le changement automatique d'encodage.
Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une solution ?
Il y a longtemps, à l'école, quand j'écrivais des programmes C qui imprimait des accents dans un terminal "DOS" sous Windows. :-)
Je ne me souviens pas pour un script Python exécuté dans la même console de m***e mais il est possible que ce vieil âne têtu n'en fasse qu'à sa tête et refuse de prendre autre chose en compte que son codage de caractères propriétaire, dont le nom pour Python doit être windows-1252 ou cp-1252. Problème de portabilité en vue si tu l'utilises...
Oui mais je suis sous Windows et ça je n'y peut rien. Donc je cherche une solution.
dès que je mets le commentaire de type d'encodage au début du fichier,
Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage.
Comme si Eclipse connaissait cette "instruction". Peut-être que c'est
PyDev qui fait ça ?
Le format dans lequel est écrit le codage de caractères est une
convention aussi connue de vim et emacs.
Après un peu de recherches, c'est PyDev (version récente) qui fait le changement automatique d'encodage.
Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une
solution ?
Il y a longtemps, à l'école, quand j'écrivais des programmes C qui
imprimait des accents dans un terminal "DOS" sous Windows. :-)
Je ne me souviens pas pour un script Python exécuté dans la même console
de m***e mais il est possible que ce vieil âne têtu n'en fasse qu'à sa
tête et refuse de prendre autre chose en compte que son codage de
caractères propriétaire, dont le nom pour Python doit être windows-1252
ou cp-1252. Problème de portabilité en vue si tu l'utilises...
Oui mais je suis sous Windows et ça je n'y peut rien. Donc je cherche une solution.
dès que je mets le commentaire de type d'encodage au début du fichier, Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage. Comme si Eclipse connaissait cette "instruction". Peut-être que c'est PyDev qui fait ça ?
Le format dans lequel est écrit le codage de caractères est une convention aussi connue de vim et emacs.
Après un peu de recherches, c'est PyDev (version récente) qui fait le changement automatique d'encodage.
Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une solution ?
Il y a longtemps, à l'école, quand j'écrivais des programmes C qui imprimait des accents dans un terminal "DOS" sous Windows. :-)
Je ne me souviens pas pour un script Python exécuté dans la même console de m***e mais il est possible que ce vieil âne têtu n'en fasse qu'à sa tête et refuse de prendre autre chose en compte que son codage de caractères propriétaire, dont le nom pour Python doit être windows-1252 ou cp-1252. Problème de portabilité en vue si tu l'utilises...
Oui mais je suis sous Windows et ça je n'y peut rien. Donc je cherche une solution.
noone
Bonjour,
Lorsque je mets des accents dans mes chaines de caractères, j'ai un warning généré par python. Normal. J'aimerais supprimer ce warning mais je n'y arrive pas. Je suis sous windows. J'utilise Eclipse 3.1 avec le plug-in PyDev. Je mets le commentaire qui va bien au début de mon fichier pour dire que j'ai des caractères de type UTF-8. J'enregistre mon fichier au format UTF-8 (ou du moins je pense que c'est le cas). J'ai bien mes caractères accentués dans le fichier source mais à l'exécution j'ai 2 caractères bizarres à chaque lettre accentuée. Je suppose que ces deux caractères correspondent au code UTF-8 non "décodé". Ce qui est étrange c'est que dès que je mets le commentaire de type d'encodage au début du fichier, Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage. Comme si Eclipse connaissait cette "instruction". Peut-être que c'est PyDev qui fait ça ? Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une solution ?
Nicolas
tu as bien mis ça au début de ton code source
# -*- coding: iso-8859-1 -*-
(tu peux remplacer iso-8859-1 par l'encodage qui tu utilises (utf-8, windows-1252, cp-1252)
Je te conseille d'installer Cygwin sur ton PC et de regarder l'encodage avec la fonction "file"... le modifier avec "iconv" ou "recode"
Bonjour,
Lorsque je mets des accents dans mes chaines de caractères, j'ai un
warning généré par python. Normal.
J'aimerais supprimer ce warning mais je n'y arrive pas.
Je suis sous windows. J'utilise Eclipse 3.1 avec le plug-in PyDev.
Je mets le commentaire qui va bien au début de mon fichier pour dire que
j'ai des caractères de type UTF-8. J'enregistre mon fichier au format
UTF-8 (ou du moins je pense que c'est le cas). J'ai bien mes caractères
accentués dans le fichier source mais à l'exécution j'ai 2 caractères
bizarres à chaque lettre accentuée. Je suppose que ces deux caractères
correspondent au code UTF-8 non "décodé". Ce qui est étrange c'est que
dès que je mets le commentaire de type d'encodage au début du fichier,
Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage.
Comme si Eclipse connaissait cette "instruction". Peut-être que c'est
PyDev qui fait ça ?
Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une
solution ?
Nicolas
tu as bien mis ça au début de ton code source
# -*- coding: iso-8859-1 -*-
(tu peux remplacer iso-8859-1 par l'encodage qui tu utilises (utf-8,
windows-1252, cp-1252)
Je te conseille d'installer Cygwin sur ton PC et de regarder l'encodage
avec la fonction "file"... le modifier avec "iconv" ou "recode"
Lorsque je mets des accents dans mes chaines de caractères, j'ai un warning généré par python. Normal. J'aimerais supprimer ce warning mais je n'y arrive pas. Je suis sous windows. J'utilise Eclipse 3.1 avec le plug-in PyDev. Je mets le commentaire qui va bien au début de mon fichier pour dire que j'ai des caractères de type UTF-8. J'enregistre mon fichier au format UTF-8 (ou du moins je pense que c'est le cas). J'ai bien mes caractères accentués dans le fichier source mais à l'exécution j'ai 2 caractères bizarres à chaque lettre accentuée. Je suppose que ces deux caractères correspondent au code UTF-8 non "décodé". Ce qui est étrange c'est que dès que je mets le commentaire de type d'encodage au début du fichier, Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage. Comme si Eclipse connaissait cette "instruction". Peut-être que c'est PyDev qui fait ça ? Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une solution ?
Nicolas
tu as bien mis ça au début de ton code source
# -*- coding: iso-8859-1 -*-
(tu peux remplacer iso-8859-1 par l'encodage qui tu utilises (utf-8, windows-1252, cp-1252)
Je te conseille d'installer Cygwin sur ton PC et de regarder l'encodage avec la fonction "file"... le modifier avec "iconv" ou "recode"
Laurent Pointal
nico wrote:
Bonjour,
Lorsque je mets des accents dans mes chaines de caractères, j'ai un warning généré par python. Normal. J'aimerais supprimer ce warning mais je n'y arrive pas.
:-) collision de sujet entre python-fr et fclp :-)
pythonfr: http://www.aful.org/wws/info/python
Je me cite: ---------------------------------------------------------------------
Mais c'est quoi la "chaîne python classique" ?
C'est la chaine de type str, qui utilise l'encodage par défaut (sys.getdefaultencoding). Donc généralement l'ASCII..
sys.getdefaultencoding() 'ascii'
(sauf erreur il est fortement conseillé de laisser l'encodage en ASCII car c'est global, et certains modules peuvent ne pas apprécier si l'on change).
Personnellement je fais souvent l'erreur suivante
- je déclare un # -*- coding: latin1 -*- au début de mon module. - l'encode effectivement mon source en latin1 - je déclare des chaînes standard str (via "blabla"), qui contiennent effectivement des caractères encodés en latin1.
Mais... pour Python, comme les chaînes ne sont pas déclarées unicode (via u"blabla"), elles sont donc des chaînes dans l'encodage par défaut... donc l'ascii. Et lorsque je veux afficher des caractères, je me retrouve avec des caractères de l'espace latin1 (>127) dans des chaînes censées être de l'ASCII donc Python me lève de jolies exceptions.
Solution (pour les encodages de chaînes dans les sources): - je déclare un # -*- coding: latin1 -*- au début de mon module. - l'encode effectivement mon source en latin1 - je déclare des chaînes unicode, que Python crée automatiquement à partir du source qu'il sait être encodé en latin1.
Et lorsque je veux ressortir ces chaînes, je fais du s.encode(l'encodagequejeveux).
Et donc, solution lorsque je lis ou écrit du texte: savoir dans quel encodage il est, et travailler de façon interne avec de l'unicode.
Lorsque je mets des accents dans mes chaines de caractères, j'ai un
warning généré par python. Normal.
J'aimerais supprimer ce warning mais je n'y arrive pas.
:-) collision de sujet entre python-fr et fclp :-)
pythonfr: http://www.aful.org/wws/info/python
Je me cite:
---------------------------------------------------------------------
Mais c'est quoi la "chaîne python classique" ?
C'est la chaine de type str, qui utilise l'encodage par défaut
(sys.getdefaultencoding). Donc généralement l'ASCII..
sys.getdefaultencoding()
'ascii'
(sauf erreur il est fortement conseillé de laisser l'encodage en ASCII
car c'est global, et certains modules peuvent ne pas apprécier si l'on
change).
Personnellement je fais souvent l'erreur suivante
- je déclare un # -*- coding: latin1 -*- au début de mon module.
- l'encode effectivement mon source en latin1
- je déclare des chaînes standard str (via "blabla"), qui contiennent
effectivement des caractères encodés en latin1.
Mais... pour Python, comme les chaînes ne sont pas déclarées unicode
(via u"blabla"), elles sont donc des chaînes dans l'encodage par
défaut... donc l'ascii. Et lorsque je veux afficher des caractères, je
me retrouve avec des caractères de l'espace latin1 (>127) dans des
chaînes censées être de l'ASCII donc Python me lève de jolies exceptions.
Solution (pour les encodages de chaînes dans les sources):
- je déclare un # -*- coding: latin1 -*- au début de mon module.
- l'encode effectivement mon source en latin1
- je déclare des chaînes unicode, que Python crée automatiquement à
partir du source qu'il sait être encodé en latin1.
Et lorsque je veux ressortir ces chaînes, je fais du
s.encode(l'encodagequejeveux).
Et donc, solution lorsque je lis ou écrit du texte: savoir dans quel
encodage il est, et travailler de façon interne avec de l'unicode.
Lorsque je mets des accents dans mes chaines de caractères, j'ai un warning généré par python. Normal. J'aimerais supprimer ce warning mais je n'y arrive pas.
:-) collision de sujet entre python-fr et fclp :-)
pythonfr: http://www.aful.org/wws/info/python
Je me cite: ---------------------------------------------------------------------
Mais c'est quoi la "chaîne python classique" ?
C'est la chaine de type str, qui utilise l'encodage par défaut (sys.getdefaultencoding). Donc généralement l'ASCII..
sys.getdefaultencoding() 'ascii'
(sauf erreur il est fortement conseillé de laisser l'encodage en ASCII car c'est global, et certains modules peuvent ne pas apprécier si l'on change).
Personnellement je fais souvent l'erreur suivante
- je déclare un # -*- coding: latin1 -*- au début de mon module. - l'encode effectivement mon source en latin1 - je déclare des chaînes standard str (via "blabla"), qui contiennent effectivement des caractères encodés en latin1.
Mais... pour Python, comme les chaînes ne sont pas déclarées unicode (via u"blabla"), elles sont donc des chaînes dans l'encodage par défaut... donc l'ascii. Et lorsque je veux afficher des caractères, je me retrouve avec des caractères de l'espace latin1 (>127) dans des chaînes censées être de l'ASCII donc Python me lève de jolies exceptions.
Solution (pour les encodages de chaînes dans les sources): - je déclare un # -*- coding: latin1 -*- au début de mon module. - l'encode effectivement mon source en latin1 - je déclare des chaînes unicode, que Python crée automatiquement à partir du source qu'il sait être encodé en latin1.
Et lorsque je veux ressortir ces chaînes, je fais du s.encode(l'encodagequejeveux).
Et donc, solution lorsque je lis ou écrit du texte: savoir dans quel encodage il est, et travailler de façon interne avec de l'unicode.
- je déclare des chaînes unicode, que Python crée automatiquement à partir du source qu'il sait être encodé en latin1.
Et lorsque je veux ressortir ces chaînes, je fais du s.encode(l'encodagequejeveux).
Je pense que c'est le comportement le plus sain et le plus pérenne. Il me semble même avoir lu que c'était une piste pour l'évolution de Python : distinguer les chaînes « flux d'octets » pour les sources de données et les constantes littérales du code, et les chaînes de caractères texte à destination des humains.
Un outil que j'utilise fait cette distinction pour savoir quelles chaînes sont à extraire dans un fichier PO pour traduction et lesquelles sont à usage interne.
Et donc, solution lorsque je lis ou écrit du texte: savoir dans quel encodage il est, et travailler de façon interne avec de l'unicode.
C'est de toute façon indispensable. Comment peut-on programmer sans savoir dans quel codage on lit et écrit, on stocke ses données, et on lit les données des autres ? Une référence en français sur le sujet : http://french.joelonsoftware.com/Articles/Unicode.html
-- Hervé Cauwelier http://www.oursours.net/
- je déclare des chaînes unicode, que Python crée automatiquement à
partir du source qu'il sait être encodé en latin1.
Et lorsque je veux ressortir ces chaînes, je fais du
s.encode(l'encodagequejeveux).
Je pense que c'est le comportement le plus sain et le plus pérenne. Il
me semble même avoir lu que c'était une piste pour l'évolution de Python
: distinguer les chaînes « flux d'octets » pour les sources de données
et les constantes littérales du code, et les chaînes de caractères texte
à destination des humains.
Un outil que j'utilise fait cette distinction pour savoir quelles
chaînes sont à extraire dans un fichier PO pour traduction et lesquelles
sont à usage interne.
Et donc, solution lorsque je lis ou écrit du texte: savoir dans quel
encodage il est, et travailler de façon interne avec de l'unicode.
C'est de toute façon indispensable. Comment peut-on programmer sans
savoir dans quel codage on lit et écrit, on stocke ses données, et on
lit les données des autres ? Une référence en français sur le sujet :
http://french.joelonsoftware.com/Articles/Unicode.html
- je déclare des chaînes unicode, que Python crée automatiquement à partir du source qu'il sait être encodé en latin1.
Et lorsque je veux ressortir ces chaînes, je fais du s.encode(l'encodagequejeveux).
Je pense que c'est le comportement le plus sain et le plus pérenne. Il me semble même avoir lu que c'était une piste pour l'évolution de Python : distinguer les chaînes « flux d'octets » pour les sources de données et les constantes littérales du code, et les chaînes de caractères texte à destination des humains.
Un outil que j'utilise fait cette distinction pour savoir quelles chaînes sont à extraire dans un fichier PO pour traduction et lesquelles sont à usage interne.
Et donc, solution lorsque je lis ou écrit du texte: savoir dans quel encodage il est, et travailler de façon interne avec de l'unicode.
C'est de toute façon indispensable. Comment peut-on programmer sans savoir dans quel codage on lit et écrit, on stocke ses données, et on lit les données des autres ? Une référence en français sur le sujet : http://french.joelonsoftware.com/Articles/Unicode.html
-- Hervé Cauwelier http://www.oursours.net/
nico
tu as bien mis ça au début de ton code source
# -*- coding: iso-8859-1 -*-
J'ai essayé avec UTF-8 et Cp-1252 sans succès.
(tu peux remplacer iso-8859-1 par l'encodage qui tu utilises (utf-8, windows-1252, cp-1252)
Je te conseille d'installer Cygwin sur ton PC et de regarder l'encodage avec la fonction "file"... le modifier avec "iconv" ou "recode"
tu as bien mis ça au début de ton code source
# -*- coding: iso-8859-1 -*-
J'ai essayé avec UTF-8 et Cp-1252 sans succès.
(tu peux remplacer iso-8859-1 par l'encodage qui tu utilises (utf-8,
windows-1252, cp-1252)
Je te conseille d'installer Cygwin sur ton PC et de regarder l'encodage
avec la fonction "file"... le modifier avec "iconv" ou "recode"
(tu peux remplacer iso-8859-1 par l'encodage qui tu utilises (utf-8, windows-1252, cp-1252)
Je te conseille d'installer Cygwin sur ton PC et de regarder l'encodage avec la fonction "file"... le modifier avec "iconv" ou "recode"
nico
C'est la chaine de type str, qui utilise l'encodage par défaut (sys.getdefaultencoding). Donc généralement l'ASCII..
sys.getdefaultencoding()
'ascii'
(sauf erreur il est fortement conseillé de laisser l'encodage en ASCII car c'est global, et certains modules peuvent ne pas apprécier si l'on change).
Personnellement je fais souvent l'erreur suivante
- je déclare un # -*- coding: latin1 -*- au début de mon module. - l'encode effectivement mon source en latin1 - je déclare des chaînes standard str (via "blabla"), qui contiennent effectivement des caractères encodés en latin1.
Mais... pour Python, comme les chaînes ne sont pas déclarées unicode (via u"blabla"), elles sont donc des chaînes dans l'encodage par défaut... donc l'ascii. Et lorsque je veux afficher des caractères, je me retrouve avec des caractères de l'espace latin1 (>127) dans des chaînes censées être de l'ASCII donc Python me lève de jolies exceptions.
Solution (pour les encodages de chaînes dans les sources): - je déclare un # -*- coding: latin1 -*- au début de mon module. - l'encode effectivement mon source en latin1 - je déclare des chaînes unicode, que Python crée automatiquement à partir du source qu'il sait être encodé en latin1.
Et lorsque je veux ressortir ces chaînes, je fais du s.encode(l'encodagequejeveux).
Et donc, solution lorsque je lis ou écrit du texte: savoir dans quel encodage il est, et travailler de façon interne avec de l'unicode.
Tiens, ça me fais penser que le problème est peut-être ailleurs. J'utilise wxPython comme interface graphique pour mon programme. Et c'est dans les affichages de mon programme que ça va pas. Et je me rapelle avoir installé la version non unicode de wxPython (en me demandant à quoi pouvait bien servir une version unicode).
Et si j'installais une version unicode de wxPython...
Merci pour la solution complète. Je ne pensais pas que ça serait si compliqué de mettre des accents dans un programme ;)
C'est la chaine de type str, qui utilise l'encodage par défaut
(sys.getdefaultencoding). Donc généralement l'ASCII..
sys.getdefaultencoding()
'ascii'
(sauf erreur il est fortement conseillé de laisser l'encodage en ASCII
car c'est global, et certains modules peuvent ne pas apprécier si l'on
change).
Personnellement je fais souvent l'erreur suivante
- je déclare un # -*- coding: latin1 -*- au début de mon module.
- l'encode effectivement mon source en latin1
- je déclare des chaînes standard str (via "blabla"), qui contiennent
effectivement des caractères encodés en latin1.
Mais... pour Python, comme les chaînes ne sont pas déclarées unicode
(via u"blabla"), elles sont donc des chaînes dans l'encodage par
défaut... donc l'ascii. Et lorsque je veux afficher des caractères, je
me retrouve avec des caractères de l'espace latin1 (>127) dans des
chaînes censées être de l'ASCII donc Python me lève de jolies exceptions.
Solution (pour les encodages de chaînes dans les sources):
- je déclare un # -*- coding: latin1 -*- au début de mon module.
- l'encode effectivement mon source en latin1
- je déclare des chaînes unicode, que Python crée automatiquement à
partir du source qu'il sait être encodé en latin1.
Et lorsque je veux ressortir ces chaînes, je fais du
s.encode(l'encodagequejeveux).
Et donc, solution lorsque je lis ou écrit du texte: savoir dans quel
encodage il est, et travailler de façon interne avec de l'unicode.
Tiens, ça me fais penser que le problème est peut-être ailleurs. J'utilise wxPython comme interface graphique pour mon programme. Et c'est dans les affichages de mon programme que ça va pas. Et je me rapelle avoir installé la version non unicode de wxPython (en me demandant à quoi pouvait bien servir une version unicode).
Et si j'installais une version unicode de wxPython...
Merci pour la solution complète. Je ne pensais pas que ça serait si compliqué de mettre des accents dans un programme ;)
C'est la chaine de type str, qui utilise l'encodage par défaut (sys.getdefaultencoding). Donc généralement l'ASCII..
sys.getdefaultencoding()
'ascii'
(sauf erreur il est fortement conseillé de laisser l'encodage en ASCII car c'est global, et certains modules peuvent ne pas apprécier si l'on change).
Personnellement je fais souvent l'erreur suivante
- je déclare un # -*- coding: latin1 -*- au début de mon module. - l'encode effectivement mon source en latin1 - je déclare des chaînes standard str (via "blabla"), qui contiennent effectivement des caractères encodés en latin1.
Mais... pour Python, comme les chaînes ne sont pas déclarées unicode (via u"blabla"), elles sont donc des chaînes dans l'encodage par défaut... donc l'ascii. Et lorsque je veux afficher des caractères, je me retrouve avec des caractères de l'espace latin1 (>127) dans des chaînes censées être de l'ASCII donc Python me lève de jolies exceptions.
Solution (pour les encodages de chaînes dans les sources): - je déclare un # -*- coding: latin1 -*- au début de mon module. - l'encode effectivement mon source en latin1 - je déclare des chaînes unicode, que Python crée automatiquement à partir du source qu'il sait être encodé en latin1.
Et lorsque je veux ressortir ces chaînes, je fais du s.encode(l'encodagequejeveux).
Et donc, solution lorsque je lis ou écrit du texte: savoir dans quel encodage il est, et travailler de façon interne avec de l'unicode.
Tiens, ça me fais penser que le problème est peut-être ailleurs. J'utilise wxPython comme interface graphique pour mon programme. Et c'est dans les affichages de mon programme que ça va pas. Et je me rapelle avoir installé la version non unicode de wxPython (en me demandant à quoi pouvait bien servir une version unicode).
Et si j'installais une version unicode de wxPython...
Merci pour la solution complète. Je ne pensais pas que ça serait si compliqué de mettre des accents dans un programme ;)
Je suis d'accord : les deux caractères correspondent bien à de l'UTF-8 "non-décodés" ; disons traités comme de l'ANSI ou de l'ASCII brut.
Ce qu'il faut, c'est que ta sortie traite l'UTF-8. Alors, question : comment visualises-tu le résultat de tes scripts ?
Si c'est la console, problème, elle ne gère pas l'UTF-8 ; il faut alors revenir au cp1252, utiliser la commande "CHCP 1252" pour dire à la console de se mettre en cp1252, et, éventuellement, changer la police, dans les propriétés de la console.
Si tu utilises une console virtuelle (par exemple avec SCite), il faut vérifier ses paramètres, et la police de caractères utilisée. Je conseille Arial Unicode, qui peut représenter plus de 56 000 caractères unicode.
Si tu utilises un GUI (wx, tk, etc.), il faut vérifier que tu utilises bien une version unicode.
Si tu utilises les API de windows, (avec ctypes ou pywin32), il suffit de choisir les version unicode, et il ne devrait pas y avoir de problème.
Perso, je travaille en cp1252 pour tout ce qui console, et en UTF-8 pour les gros script, à cause d'un bug de Python 2.4 et 2.4.1 (sur les grandes lignes en cp1252). Alors, dans le cas de l'UTF-8 en console, je convertis la sortie en cp1252 (1).
J'espère que ces indications aideront...
@-salutations
Michel Claveau
(1) en fait, je n'utilise pas que cp1252, mais aussi cp1251 (Russie), cp1250 (Europe centrale), et cp1253 (Grèce), selon les besoins. Tous fonctionnent bien sous windows.
Bonjour !
Je suis d'accord : les deux caractères correspondent bien à de l'UTF-8
"non-décodés" ; disons traités comme de l'ANSI ou de l'ASCII brut.
Ce qu'il faut, c'est que ta sortie traite l'UTF-8. Alors, question : comment
visualises-tu le résultat de tes scripts ?
Si c'est la console, problème, elle ne gère pas l'UTF-8 ; il faut alors
revenir au cp1252, utiliser la commande "CHCP 1252" pour dire à la console
de se mettre en cp1252, et, éventuellement, changer la police, dans les
propriétés de la console.
Si tu utilises une console virtuelle (par exemple avec SCite), il faut
vérifier ses paramètres, et la police de caractères utilisée. Je conseille
Arial Unicode, qui peut représenter plus de 56 000 caractères unicode.
Si tu utilises un GUI (wx, tk, etc.), il faut vérifier que tu utilises bien
une version unicode.
Si tu utilises les API de windows, (avec ctypes ou pywin32), il suffit de
choisir les version unicode, et il ne devrait pas y avoir de problème.
Perso, je travaille en cp1252 pour tout ce qui console, et en UTF-8 pour les
gros script, à cause d'un bug de Python 2.4 et 2.4.1 (sur les grandes lignes
en cp1252). Alors, dans le cas de l'UTF-8 en console, je convertis la sortie
en cp1252 (1).
J'espère que ces indications aideront...
@-salutations
Michel Claveau
(1) en fait, je n'utilise pas que cp1252, mais aussi cp1251 (Russie), cp1250
(Europe centrale), et cp1253 (Grèce), selon les besoins. Tous fonctionnent
bien sous windows.
Je suis d'accord : les deux caractères correspondent bien à de l'UTF-8 "non-décodés" ; disons traités comme de l'ANSI ou de l'ASCII brut.
Ce qu'il faut, c'est que ta sortie traite l'UTF-8. Alors, question : comment visualises-tu le résultat de tes scripts ?
Si c'est la console, problème, elle ne gère pas l'UTF-8 ; il faut alors revenir au cp1252, utiliser la commande "CHCP 1252" pour dire à la console de se mettre en cp1252, et, éventuellement, changer la police, dans les propriétés de la console.
Si tu utilises une console virtuelle (par exemple avec SCite), il faut vérifier ses paramètres, et la police de caractères utilisée. Je conseille Arial Unicode, qui peut représenter plus de 56 000 caractères unicode.
Si tu utilises un GUI (wx, tk, etc.), il faut vérifier que tu utilises bien une version unicode.
Si tu utilises les API de windows, (avec ctypes ou pywin32), il suffit de choisir les version unicode, et il ne devrait pas y avoir de problème.
Perso, je travaille en cp1252 pour tout ce qui console, et en UTF-8 pour les gros script, à cause d'un bug de Python 2.4 et 2.4.1 (sur les grandes lignes en cp1252). Alors, dans le cas de l'UTF-8 en console, je convertis la sortie en cp1252 (1).
J'espère que ces indications aideront...
@-salutations
Michel Claveau
(1) en fait, je n'utilise pas que cp1252, mais aussi cp1251 (Russie), cp1250 (Europe centrale), et cp1253 (Grèce), selon les besoins. Tous fonctionnent bien sous windows.
noone
Je te conseille d'installer Cygwin sur ton PC et de regarder l'encodage avec la fonction "file"... le modifier avec "iconv" ou "recode"
et vous savez quel est l'encodage du fichier que vous utiliser (en testant avec file)
Je pense que je mieux est d'utiliser un éditeur de texte digne de ce nom (Emacs par exemple tourne bien sous Windows)
Je te conseille d'installer Cygwin sur ton PC et de regarder l'encodage
avec la fonction "file"... le modifier avec "iconv" ou "recode"
et vous savez quel est l'encodage du fichier que vous utiliser
(en testant avec file)
Je pense que je mieux est d'utiliser un éditeur de texte digne de ce nom
(Emacs par exemple tourne bien sous Windows)
Je te conseille d'installer Cygwin sur ton PC et de regarder l'encodage avec la fonction "file"... le modifier avec "iconv" ou "recode"
et vous savez quel est l'encodage du fichier que vous utiliser (en testant avec file)
Je pense que je mieux est d'utiliser un éditeur de texte digne de ce nom (Emacs par exemple tourne bien sous Windows)
Do Re Mi chel La Si Do
Bonjour !
J'ai des doutes sur l'information renvoyée. Comment cet utilitaire distinguera-t'il un fichier en cp1252, d'un fichier en cp1251, ou d'un fichier unicode, si l'identifiant manque ? D'après Unicode, en l'absence d'en-tête, ce devrait être de l'UTF-8 ; cela n'est pas toujours vrai...
@-salutations
Michel Claveau
Bonjour !
J'ai des doutes sur l'information renvoyée. Comment cet utilitaire
distinguera-t'il un fichier en cp1252, d'un fichier en cp1251, ou d'un
fichier unicode, si l'identifiant manque ? D'après Unicode, en l'absence
d'en-tête, ce devrait être de l'UTF-8 ; cela n'est pas toujours vrai...
J'ai des doutes sur l'information renvoyée. Comment cet utilitaire distinguera-t'il un fichier en cp1252, d'un fichier en cp1251, ou d'un fichier unicode, si l'identifiant manque ? D'après Unicode, en l'absence d'en-tête, ce devrait être de l'UTF-8 ; cela n'est pas toujours vrai...
