89 thoughts on “L’encoding en Python, une bonne fois pour toute”

• 

  roro 21/04/2013 at 08:31

  Merci, merci, merci, et…MERCI.
  Ta statue sera équestre. Pas moins.

• 

  Sam Post author 21/04/2013 at 09:16

  Fait gaffe aux nombres de pieds en l’air pour le cheval. J’ai pas envie qu’on me prenne pour un macabé.

  Pour la matière, le bronze est mon meilleur profile.

• 

  k3c 21/04/2013 at 13:02

  s/et le jour où ça se gatte/et le jour où ça se gâte
  s/à ou d’autres langage/à où d’autres langages
  s/Et certains on plusieurs noms/Et certains ont plusieurs noms
  s/c’est ce qu’on appelles les encodings/c’est ce qu’on appelle les encodings
  s/Certaines bibliothèque /Certaines bibliothèques

  Le sodomiseur de coléoptères :-)

  Merci pour l’article, je pensais pas trop mal connaître le sujet, mais visiblement non.

• 

  Sam Post author 21/04/2013 at 13:18

  Bah tu sais moi je me dis après chaque article que j’ai bien tout relu et qu’il reste pas de faute. Mais visiblement non.

• 

  fab 21/04/2013 at 17:50

  Franchement merci.
  Pour avoir lu plein de choses sur le sujet, mal compris, confondu le vocabulaire, oublié le lendemain, etc… c’est l’article qui explique le mieux et le plus concrètement l’encoding. C’est de la même veine que les articles sur la programmation orientée objet qui sont d’un niveau pédagogique inégalé parmis tout ce que j’ai pu lire. La théorie et les bases sont parfaitement expliquées avec toujours une application concrète. C’est limpide et efficace.
  Cela fait un petit moment que je suis régulièrement votre blog, c’est une petite pépite, donc bravo et surtout un grand merci pour le partage car mine du rien c’est du boulot.

• 

  Sam Post author 21/04/2013 at 18:07

  \ o /

• 

  Lyyn 21/04/2013 at 20:33

  Yeah, ça part dans mes favoris ! Merci pour l’article !

• 

  JeromeJ 21/04/2013 at 20:33

  Premier commentaire constructif de la journée :

  Vous avez déjà utilisé cette image d’entête d’article pour un autre article, c’est trop nul, vous perdez votre originalité.

  <3

• 

  Sam Post author 21/04/2013 at 20:39

  Meeeeeeeeeeeeerde, j’ai eu un doute en plus.

  EDIT: m’en fout, je l’ai changé.

• 

  JeromeJ 22/04/2013 at 00:58

  Sinon plus sérieusement … c’est un peu perturbant, vous parlez un peu des différences avec Python3 mais la majorité des exemples sont en Python2 et vu que les différences entre python2 et 3 (à ce niveau là en tout cas) sont super chiantes et prêtent à confusion, bah du coup c’est un peu plus dur de bien vous suivre partout (moi qui suis 100% Python3), dommage … Article bien complet sinon :) Merci.

  Ah et si l’un de vous à une solution simple pour faire en sorte que les encodings de stdout et stdin se mettent en UTF-8 par défaut, ça serait pas mal. (Surtout que ce sont des propriétés en read only donc, à part des méthodes bizarroïde au lancement de Python (en console), je ne sais même pas si y a moyen de les modifier en live).

• 

  JeromeJ 22/04/2013 at 01:11

  Au fait, je veux j’aurais bien voulu un tampon :( (tout ça pour ça bitch !)

• 

  Max 22/04/2013 at 07:26

  le tampon ça se mérite jeune homme ! N’est pas tamponné qui veut.

• 

  Sam Post author 22/04/2013 at 07:30

  @JeromeJ: pour Python3, c’est pareil, exactement le même article sauf que:

  – le type ‘unicode’ est appelé ‘str’ et est celui créé par défaut quand on fabrique une chaîne
  – le type décodé est appelé ‘byte’
  – pas besoin de déclarer “# -*- coding: utf-8 -*-” si ton fichier est en UTF8 car c’est maintenant la valeur par defaut

  C’est tout. Tout le reste est pareil.

  Quand à s’assurer que toute écriture sur sdtout est en UTF8, c’est sans doute possible en faisant un truc du genre :

  import sys from codecs import getwritter   sys.__stdout__ = getwriter('utf8')(sys.stdout.buffer)

  Mais je ne le recommanderais pas car :

  – ça remplace stout pour tout le code, y compris les libs tierces parties et qui sait ce que ça peut provoquer
  – ça rend le code importable (stdout n’est pas en utf8 sous windows, et ça printera un truc illisible)
  – ton script peut changer de context en cours d’éxécution, et sdtout ne sera alors plus le même, avec potentiellement un encoding différent

  D’une manière générale il vaut mieux spécifier l’encoding par défaut directement sur les fonctions qui font l’opération d’écriture. Par exemple:

  import sys from codecs import getwriter from functools import partial   p = partial(print, file=codecs.getwriter('utf8')(sys.stdout.buffer)) p('yéééééééé') # cette fonction print toujours sur stdout en UTF8

  Une alternative est de setter la bonne variable d’environnement pour que Python remplisse stdout avec l’encoding que l’on souhaite. Par exemple sous Ubuntu :

  http://drj11.wordpress.com/2007/05/14/python-how-is-sysstdoutencoding-chosen/

  (ou PYTHONIOENCODING=utf-8:surrogateescape python somescript.py selon les versions)

  Cela conditionne par ailleur le résultat de :

  >>> import locale >>> locale.getdefaultlocale()[1]

• 

  JeromeJ 22/04/2013 at 07:48

  @Max: J’aurais essayé !

  @Sam: Bien ce que je craignais … Pas mal l’idée de wrapper print avec functools.partial, j’aime !

  (C’est bien le prob c’est que je travaille à moitié sous Windows)

• 

  Sam Post author 22/04/2013 at 08:07

  Le terminal de windows n’est pas configuré pour afficher de l’UTF8, Python ne pourra rien y changer. Il faut soit y printer l’encoding qu’il utilise actuellement (et se limiter aux caractères qu’il accepte du coup). On peut le trouver en faisant (il me semble):

  >>> import locale >>> locale.getdefaultlocale() ('fr_FR', 'UTF-8')

  Mais print devrait se charger de le faire automatiquement en Python3 donc ça devrait pas poser de problème. Simplement tu oublis les caractères chinois.

  Soit setter l’encoding avant avec une commande :

  http://stackoverflow.com/questions/388490/unicode-characters-in-windows-command-line-how

  Ce n’est pas particulièrement lié à Python, c’est pareil dans tous les langages sous Windows car cet OS n’a pas adopté utf8 par default.

• 

  desfrenes 22/04/2013 at 08:42

  “Par défaut, Python plante sur les erreurs d’encoding là ou d’autres langage (comme le PHP) se débrouillent pour vous sortir un truc (qui ne veut rien dire, qui peut corrompre toute votre base de données, mais qui ne plante pas).”

  Ouais… bah vaut mieux que ça plante, au moins ça donne l’occasion de réparer proprement.

  Merci pour cet excellent résumé.

• 

  AxelF 22/04/2013 at 08:54

  Il y a encore des choses plus rigolotes à faire avec l’encoding. Par exemple ce fichier est tout à fait valide :

  # -*- coding: rot13 -*-
cevag h'Obawbhe fnz'

  j’avais découvert ça il y a quelques temps sur linuxfr, avec même en prime l’encodage en brainfuck, mais on peut également imaginer encoder son fichier en whitespace ou tout autre encodage hyper pratique …

• 

  Sam Post author 22/04/2013 at 09:09

  Tristement, ça ne marche plus avec Python 3. On pouvait aussi utiliser base64, zlib, etc.

• 

  kontre 22/04/2013 at 09:31

  Uhu : http://sebsauvage.net/links/?Q3zlyg
  Coïncidence ?

  C’est la première fois que j’ai l’espoir de comprendre et d’utiliser correctement les fichues chaînes de caractère en python. Chapeau les mecs ! Mais je flippe quand même de modifier mon code sur ce sujet, qui fonctionne actuellement à peu près.

  Par rapport à codec.open, il y a ça dans la doc :

  Note
  Files are always opened in binary mode, even if no binary mode was specified. This is done to avoid data loss due to encodings using 8-bit values. This means that no automatic conversion of ‘\n’ is done on reading and writing.

  Ça peut être emmerdant ça ? Il y a un moyen simple de faire la conversion à la main ?

• 

  Sam Post author 22/04/2013 at 11:44

  Je dirais qu’un bon strip() fera bien l’affaire :-)

• 

  kontre 22/04/2013 at 12:19

  En effet, ça marche bien à la lecture, mais du coup pas à l’écriture. Y’a plus qu’à utiliser la version standard sans oublier de convertir, j’ai l’impression.

• 

  kontre 22/04/2013 at 13:38

  Autre différence python2/3 : les exceptions. En python3 on peut leur passer un message en unicode, alors qu’en python2 il faut le .encode(“utf-8). Et ça chie avec les docstrings, après…

• 

  YvesD 22/04/2013 at 14:48

  Bel article, bravo, j’aime bien la structuration en entrée (eh eh les entrées, règle #4, plat (le traitement python), dessert (les sorties, règle #5).

  Cependant je vois souvent comme directivepython, les 2 écritures pour UTF8:

  # -*- coding: utf8 -*-
  ou
  # -*- coding: utf-8 -*-

  Est-ce la même chose ? Laquelle est à privilégiée ?

• 

  Sam Post author 22/04/2013 at 14:57

  C’est kif kif.

• 

  Orlanth 22/04/2013 at 15:14

  Copié collé direct dans mes notes, à côté de : http://sebsauvage.net/python/charsets_et_encoding.html

• 

  Gring 23/04/2013 at 09:49

  Merc＀ p〇ʋr cごt art%cle tr⁋s instrucⁱf !

• 

  mentat 23/04/2013 at 19:31

  stdin et pas stding dans :
  sys.(stding|stdout).encoding.

  A part çà, rien à redire, c’est nickel comme d’hab !

• 

  Sam Post author 23/04/2013 at 21:38

  C’est l’acceng, c’est pour ça.

• 

  Kyoku57 05/05/2013 at 10:42

  Alors là, très bon article !

  Quelque soit le langage, le problème le plus récurrent est toujours celui de la manipulation des différents types d’encoding.

  Je ne te parle pas de ceux qui développent sous Windows avec un CP-1252 par défaut dans tous les logiciels et qui même avec un réglage de l’IDE finit un jour où l’autre par te ressortir l’encoding par défaut genre .. à la réouverture.

  Bref, éternel problème que tu as très bien mis en évidence. Tout le problème est d’origine interface chaise-clavier. Il faut se sortir les doigts du boule pour faire du propre.

• 

  yuiio 05/08/2013 at 14:26

  Juste merci

• 

  A_Vgyle 27/09/2013 at 20:25

  Merci grandement!
  2 jours que je plante sur ces %?!/%££!! d’encoding, et en 15 minutes… Réglé
  Thanx
  Continue!!!

• 

  Max 01/10/2013 at 10:27

  C’est laborieux chez leaseweb :/
  Ensuite ça a été un probleme de varnish qui s’est bien lancé quand leaseweb a reboot les VPS mais qui pour une raison mystérieuse ne voulait rien savoir :/

• 

  Guts 16/10/2013 at 10:29

  Merci pour l’article qui m’a bien aidé sur certains points de blocage mais il y a toujours quelque chose que je ne parviens pas à résoudre : le parsing (avec os.walk) de fichiers qui contiennent des accents. Ce qui me déroute surtout c’est la différence entre Windows et Ubuntu.

  Dans mon programme j’ai une fonction (li_geofiles()) chargée de lister les fichiers compatibles (selon leur extension et l’existence de leurs dépendances) contenus dans une arborescence à partir d’un dossier indiqué par l’utilisateur (foldertarget retourné via tkMessageBox.askdirectory) et qui bloque sur les noms de fichiers qui contiennent un accent…mais seulement sur Ubuntu ! Ça fait 2 jours que je me flagelle là-dessus et j’ai essayé qqls solutions :
  – un try/except sur le nom de fichier et réencodage à la volée (solution choisie) mais qui a le (gros) défaut de ne pas lister les fichiers avec accents (os.path.isfile ne les reconnaît pas…)
  – passer foldertarget en unicode mais ça marche pô (idem avec path.normpath(foldertarget)

  Voici la fonction en question :

  for root, dirs, files in walk(foldertarget): self.num_folders = self.num_folders + len(dirs) for f in files: try: unicode(path.join(root, f)) full_path = path.join(root, f) except UnicodeDecodeError, e: full_path = path.join(root, f.decode('latin1').encode('utf8')) self.logger.error("%s:%s" % (e, f.decode('utf-8'))) # Looping on files contained if path.splitext(full_path.lower())[1] == '.shp' and \ path.isfile('%s.dbf'.lower() % full_path[:-4]) and \ path.isfile('%s.shx'.lower() % full_path[:-4]) and \ path.isfile('%s.prj'.lower() % full_path[:-4]): # add complete path of shapefile self.li_shp.append(full_path) elif path.splitext(full_path.lower())[1] == '.tab' and \ path.isfile(full_path[:-4]+ '.dat'.lower()) and \ path.isfile(full_path[:-4]+ '.map'.lower()) and \ path.isfile(full_path[:-4]+ '.id'.lower()): # add complete path of MapInfo file self.li_tab.append(full_path)

  Si quelqu’un voit le problème…et surtout la solution !

  PS : je suis géographe à la base donc pas vraiment un développeur… #indulgence

• 

  Adrien 04/11/2013 at 14:41

  Un grand merci, enfin un tuto qui va à l’essentiel. J’ai enfin compris comment ça fonctionne.

• 

  Bromway 26/12/2013 at 22:43

  Juste au Top!
  Un super cadeau de Noel qui vient de m’offrir une ou deux nuit planche de moins

• 

  Réchèr 20/01/2014 at 23:01

  Article auquel je me réfère régulièrement, car à chaque fois que je résout mes problèmes d’encodage, je ne me souviens plus comment je les ais résolus et je dois refaire le raisonnement dans mon cerveau.

  Juste pour info : y’a des fois, syt.stdout.encoding renvoie None.

  Je suis en python 2.7 sous Windows (oui, je sais), quand j’exécute mon script dans la console, j’ai “cp850″. Quand je l’exécute avec Ctrl-B dans Sublime Text, j’ai None.

  Du coup, je fais le bourrin comme ça pour écrire sur stdout :

  # récupération de l'encodage de la sortie standard. encoding_out = sys.stdout.encoding if encoding_out is None: encoding_out = "utf-8"   def pri(whatever): unicode_string = unicode(whatever) print unicode_string.encode(encoding_out, "replace")   pri("é mon cul cé du poulé.")

• 

  Réchèr 21/01/2014 at 08:47

  Cela va sans dire, mais je précise que dans mon code précédent, j’ai bien évidemment mis le “from __future__ import unicode_literals” au début de mes fichiers.

  Du coup la chaîne “é mon cul cé du poulé” est de l’unicode.

  Et ça marche, je vois mes accents, aussi bien dans la console DOS que dans la console Sublime Text.

• 

  Frederic 06/02/2014 at 21:55

  Article salvateur!
  Juste une question:
  os.mkdir(stringenutf8.encode(sys.getfilesystemencoding())) ne marche pas sur windows avec python 2.7
  Tu sais pourquoi?

• 

  Sam Post author 07/02/2014 at 08:55

  Parce qu’il y a plusieurs notions mélangées dans cette ligne.

  mkdir a besoin d’une chaîne encodée dans l’encoding du file system.

  stringenutf8 est visiblement déjà encodée. On ne peut pas appelée “encode()” dessus.

  Soit l’encoding du fs est utf8, auquel cas tu peux l’utiliser directement, soit il faut décoder la string vers unicode, et la réencoder vers l’encoding du fs.

• 

  benjamin 04/04/2014 at 08:22

  tu m’as sauvé la vie, 1 semaine à me battre sur un code car un pu### de “°” dans l’adresse !!
  bref, je te vénère. Merci pour cet excellent article en VF.
  ps : j’aime bien l’exemple str(“Détécé”) …

• 

  Goldy 17/04/2014 at 23:32

  Une petite chose qui me semble avoir été omise dans l’explication, c’est que utf-8 est compatible avec ascii.

  C’est à dire que les 128 premiers caractères de la table utf-8 correspondent à la table ascii (c’est d’ailleurs une des raisons pour laquelle utf-8 est utilisé aux détriments des autres unicodes qui sont utf-16 et utf-32).

• 

  fredtantini 18/04/2014 at 07:28

  Je retombe dessus ; toujours très bon, comme d’habitude.

  J’en profite pour corriger quelques typos :

  Le texte sera de type ‘str’, et decode() retourne (si vous lui fournissez le bon codec ;-)), une version ‘unicode’.
  -> soit virer la virgule, soit changer les parenthèses en virgules.

  un envoie dans une socket
  -> envoi

  A la sortie
  -> À

  Les outils de la dernières chance
  -> dernière

  cyrilique
  -> cyrillique

  Merci à vous et continuez en restant comme vous êtes.

• 

  e-jambon 20/04/2014 at 01:15

  Il eut été plaisant que je commençasse à lire ce blog il y a quelques mois, avant de décider d’apprendre ruby&rails.

  C’est fou ce que python ressemble à ruby, soit dit en passant.
  Peut être un chouilla moins élégant, mais moins tortueux à relire quand on connaît pas…la preuve j’arrive à comprendre presque tout sans faire trop d’efforts.
  Given I’am as bright as a dark night…excellents articles très bien rédigés. Un grand merci.

  @Goldy merci pour la précision, ça me chiffonnait justement.

• 

  Sam Post author 20/04/2014 at 12:11

  @Goldy: j’étais persuadé de l’avoir mis, je deviens gaga.

• 

  Jean-Marie Sézérat 02/05/2014 at 12:52

  Vrabo
  Disons tous en choeur : “àéèùçÀÉÈÙÇ” – non : en chœur, c’est quand même plus joli…

• 

  kontre 05/05/2014 at 08:10

  Dans python3, on peut passer un encoding à la fonction open(), le décodage se fera de manière transparente. Super pratique !
  C’est possible en python2 avec le module coding, mais celui-ci, ne gère pas les différentes fin de ligne, ce qui est bof pour un truc sensé être plus compatible.

• 

  vecenzomene 07/05/2014 at 14:37

  bonjour,
  si par exemple je telecharge la page de google qui est securisé et ya du sharabiaya dans le code source et qui est en binaire comment faire pour convertir en utf-8 sachant que j’ai une erreur de conversion quand j’essai et puis comment faire pour lire les vrai contenue par exemple les resulats des recherche avec les liens et non le charabiya de truc securisé

• 

  Sam Post author 09/05/2014 at 09:38

  Je ne connais aucune page de google sécursé avec un code source en binaire.

  Quand je vais sur google.com, je vois bien le code source :

  http://0bin.net/paste/9-wDHADDZvekQFyC#G1VToTRNQslSE7ZaWWYI1eAK5l8k1sEjNyaFWej+DfQ=

  C’est beaucoup de javascript compressé, mais c’est un code source en clair.

  Le charset n’est pas déclaré dans la page, mais par les headers :

  ⟩ wget --server-response --spider https://google.com Mode « spider » activé. Vérification de l'existence d'un fichier distant. --2014-05-09 16:06:05-- https://google.com/ Résolution de google.com (google.com)… 74.125.135.100, 74.125.135.113, 74.125.135.139, ... Connexion à google.com (google.com)|74.125.135.100|:443… connecté. requête HTTP transmise, en attente de la réponse… HTTP/1.1 302 Found Location: https://www.google.co.th/?gws_rd=cr&ei=f5psU5LRBIOyrgeS64HoBA Cache-Control: private Content-Type: text/html; charset=UTF-8

  Donc c’est bien de l’utf8.

  Obtenir les résultats de la recherche plutôt que le code n’a rien à voir avec cela. Ce n’est pas une question d’encoding, ni de binaire, c’est simplement le niveau de fonctionalité que google choisit d’utiliser en fonction du client. Si tu te fais passer pour lynx par exemple, google n’utilisera pas javascript et tu récupéreras du HTML pure, plus facile à parser. Par exemple, avec la lib requets :

  requests.get("https://google.com/search?q=sametmax", headers={"User-Agent": "Lynx/2.8.7rel.2 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/1.0.0a"}).content

  Et ça me file du HTML que je peux lire avec beautifulsoup.

• 

  thieery 20/05/2014 at 22:51

  Bonjour,
  je cherche à lire le fichier dump windows et rien à faire, avez-vous une idée merci

• 

  Sam Post author 21/05/2014 at 05:34

  Il faut manger des crêpes au chocolat. Tout va mieux avec des crêpes au chocolat.

• 

  Heavy27z 13/06/2014 at 09:14

  Parfait cet article pour se dépatouiller quand on y comprend queudal :).
  Merci pour ce gros travail. En 20 minutes de lecture, ce blog me fait gagner à chaque fois minimum 2h. Faudrait que j’vous verse une partie de mon salaire…

  Petit détail concernant l’article : Perso, j’ai du mal avec la notion d’encode et de decode (dans quel sens est-ce que ça marche), puisque finalement le texte de brute n’existe pas comme c’est dit, à quoi correspondent les données que l’on a de part et d’autre d’une chaine str ou byte (pas simple de se faire comprendre, bref).

  J’ai trouvé des éléments de réponses dans un article détaillé de la doc python : https://docs.python.org/3/howto/unicode.html (Existe aussi pour python 2)

• 

  Sam Post author 13/06/2014 at 10:18

  Le texte est un flux de bits. Ce flux de bits est dans un encoding. Quand on décode, on récupère un objet python qui peut être traduit vers n’importe quel autre flux de bits. Ce qu’il y dans cet objet Python n’est pas important. Il faut imaginer qu’il est neutre. Decoder fait passer du flux de bits à cet objet Python, encoder fait passer de cet objet python aux flux de bits.

• 

  Heavy27z 13/06/2014 at 10:46

  Merci d’avoir pris le temps de répondre, la doc python m’avait fait comprendre quelque chose de ce genre, mais là c’est très clair :).

• 

  gmarceau 01/07/2014 at 20:43

  Merci pour cet article clair et utile.

• 

  Mars Prosac 19/07/2014 at 22:19

  Petit bémol à l’article : “En Python 2.7, l’encoding par défaut est ASCII, donc il faut presque toujours le déclarer”
  Oui, il faut le déclarer si on souhaite coder autrement qu’en ascii, et dans ce cas, ça revient à dire “si on souhaite coder des strings autre qu’en ascii”. Autre précision qu’il ne me semble pas avoir lu : UTF8 est compatible ASCII (pas le contraire évidemment). Donc, un code 2.7 codé/enregistré en ascii est compatible avec un interpréteur 3.x. Enfin, l’encoding sqlite3 par défaut est l’utf8 (pragma encoding), ce qui lui confère également une compatiblité totale avec du code 2.7 en ascii (et autre création de table ou injection de données interne au programme).
  Et pour terminer : “régler son éditeur sur le bon encoding” : oui et non : vim va régler l’encoding par défaut sur le “locale” en cours (:set encoding=…) ; mais, si on code en C ou en Python, un :w écrira bien le fichier en ascii à moins d’utiliser des caractères non ascii propre au “locale” en cours (éè …). Eclipse travaille de la même façon, je peux avoir un “locale” en latin-1 (iso8859-1), coder sous PyDev ou CDT, le résultat sera bien un fichier ascii. Mes 2 kopecs. Merci pour l’article. cdt,

• 

  Marco 02/08/2014 at 12:42

  J’essai un peu le langage python sur l’ide netbeans, franchement pas convaincu… la doc existe en français ? (mais c pas sûr d’y comprendre d’avantage).

  Kel bordel l’encoding, j’arrive jamais à savoir kel encode y faut utiliser mais dans netbeans, tou s’affiche bien (lequel utilise par défaut windows-1252). dans la console y’a pas un accent qui s’affiche correc. jamais vu un langage aussi ambigue et confus… chiotte !

• 

  Sam Post author 02/08/2014 at 16:25

  J’ai jamais vu de doc en fr.

  Pour ton encoding, il faut que tu relise l’article. Il te faut connaitre l’encoding de ta console, comme pour tous les langages du monde.

• 

  Marco 03/08/2014 at 11:04

  Bon, ok, j’ai fini par comprendre un peu mieux le sujet et comment Python s’est adapté à la norme Unicode. J’ai surtout compris qu’à force de fouiller un string on finit par découvrir qu’il est en fait constitué de Bytes lesquels on des possibilités de “petits” ou “gros bouts” selon les types utf-16 BE et LE ?

  Cela dit, le comportement du code n’a pas les mêmes répercussions depuis la console de Netbeans ou exécuté par le fichier sur le desktop. Dans l’interpréteur Python, j’ai bien les caractères accentués qd varText.decode(‘utf-8′). La même instruction dans la console de l’IDE léve une erreur:
  AttributeError: ‘str’ object has no attribute ‘decode’
  Sauf si VarText =’chaine’.encode(‘utf-8′) à été auparavant formulé. Donc, ça roule qd même pas mal mais faut bien comprendre quel type d’objet est restitué dans les manip.

• 

  Sam Post author 03/08/2014 at 12:57

  Il y a une différence fondamentale entre Python 2 et 3, et selon que tu manipule une chaîne ou des bytes. Et bien entendu, il y a une différence entre l’encoding de ton IDE, celui de la console de l’IDE, et celui de la console de l’OS.

  Encore une fois, relis l’article. Il te faut ces informations pour répondre à ta question.

  Ce n’est pas spécifique à Python, il faut connaitre l’encoding dans tous les langages du mondes.

• 

  Marco 04/08/2014 at 08:09

  Ok pour l’encoding, qu’en est-il de la charmap de Python ?

  print(‘\u0100′)
  UnicodeEncodeError: ‘charmap’ codec can’t encode character ‘\u0100′ in position 0: character maps to

  Pourquoi Python ne trouve pas un point de codage dans la table Utf-8 ?

• 

  Sam Post author 04/08/2014 at 12:49

  Ce n’est pas que Python ne trouve pas le point de codage dans la table UTF8, c’est que ce caractère n’existe pas dans l’encodage de sortie. Tu essayes de faire passer un cube dans un trou rond.

  Si tu affiche ce caractère dans une console supportant l’UTF8, ça marche parfaitement.

  Je me répète donc pour la 3eme fois, relis l’article car tu n’as récupéré aucune des informations que je souligne comme étant indispensables à avoir.

  Tu ne m’as jamais donné ton OS. Ni ta version de Python. Ni quelle était ta sortie et son encoding.

• 

  Marco 04/08/2014 at 23:08

  Effectivement ça manque d’infos, je suis sur W7-64 et j’utilise Python33.
  Apparemment le pluggin Python pour Netbeans développé par le support Oracle comporte un bug. J’ai contacté le support pour avoir des infos et comment résoudre ça, j’attend la réponse.

  Je crois devoir chercher un autre IDE pour le dév en Python.

• 

  Marco 05/08/2014 at 06:42

  Re, j’insiste encore, quitte à devenir un peu lourd, j’ai beau relire l’article, je ne vois nulle part le principal intéressé…

  On est bien d’accord que l’encoding sert à transformer une grille de chose d’une matrice sur une autre, au final c’est ce que ça fait, découvrir où sont placés des éléments dans un tableau…

  Ici les éléments en question sont des signes typographiques, lesquels plus globalement sont des dessins appelés glyphes.

  Nulle part cet article n’explique comment ces glyphes peuvent s’afficher sur un écran … nulle part ni Unicode ni les grilles UTF-8 n’indique comment dessiner sur un écran ces glyphes.
  Je n’ai pas été assez précis sur la nature des erreurs rencontrés certes, mais bien souvent il n’y a simplement rien ou bien juste des carrés qui s’affichent pour remplacer les glyphes. Ça veut dire que l’encoding fonctionne mais l’affichage est incapable de produire le glyphes correspondant.
  En changeant la police d’Output par défaut de l’IDE (Arial MS Unicode), les caractères à présent s’affiche correctement.
  CQFD. Peut être sur d’autres terminaux cette substitution de caractères est automatique mais en l’occurrence Netbeans avec le pluggin Python ne la produit pas. Au moins ça aura servit à clarifier ce point non négligeable.

• 

  Sam Post author 05/08/2014 at 12:11

  Ah, mais ça n’a rien à voir avec Python ça, c’est juste que tu utilises des polices qui n’ont pas les glyphes en UTF8. Imagines si chaque articles doit répondre à toutes les config, on est pas rendu…

• 

  Marco 06/08/2014 at 11:18

  Oui, c’est vrai que c’est parallèle au sujet…

  Autre question: j’essaie de changer l’encoding de sortie qui semble boulonné à l’objet STDOUT.
  En parcourant Stackoverflow il y a une flopée de post sur ce sujet mais pas de réponse ouvrant sur une modif de la config.

  Toujours en Python 3.x sous W7 64, voilà les données:
  print(sys.getdefaultencoding()) →UTF-8
  print(locale.getpreferredencoding()) →cp1252

  Je comprend pourquoi alors que tout est UTF-8, je n’arrive pas à mettre le STDOUT de même. Une solution à été formulé, elle fonctionne et c’est la plus courte observé:
  utf8stdout = open(1, 'w', encoding='utf-8', closefd=False)
# fd 1 is stdout
print(everyfile, file=utf8stdout)
  Avec ça effectivement il n’y a plus d’erreur de charmap mais bon c’est juste un hack, y’a pas une soluce plus propre ?

• 

  Sam Post author 07/08/2014 at 14:40

  Mettre le sdtout en en UTF8 ne veut rien dire. Sdtout est juste un objet qui représente la sortie standard.

  Python n’a aucun contrôle sur le périphérique de sortie. Si le périphérique ne supporte pas l’encoding donné, on ne peut pas l’utiliser. C’est aussi simple que ça. On ne peut pas afficher des caractères UTF8 sur une console qui ne supporte pas l’UTF8. Avec aucun langage du monde. Ce n’est pas particulièrement lié à Python.

  Vu que je ne sais toujours pas ce que vous voulez faire car vous ne l’avez toujours pas écris, je n’ai aucun moyen de vous aider. De surcroit, les commentaires de blog sont très mal adaptés à l’aide des gens en ligne.

  Mon conseil :

  – relisez l’article (bis, ter, etc). Vous avez visiblement raté des choses importantes.
  – suivez les conseils des choses à lister pour s’en sortir avec l’encoding. Après autant de message et autant d’appel de ma part à relire l’article, vous n’avez TOUJOURS PAS listé l’encoding de votre sortie ni précisé si votre texte était uniquement issu de strings du code où d’une autre source.
  – rédigez votre message de demande d’aide en suivant ce template : http://sametmax.com/template-de-demande-daide-en-informatique/. Vraiment, jouer au chat et à la souris pour récupérer des bouts d’indices pour aider quelqu’un qui programme à rédiger une demande d’aide décente, c’est fatiguant.
  – postez le dit message sur un forum.

  Je pense comprendre votre problème, mais vous ne me facilitez pas la tâche pour le résoudre. Je m’arrête donc là.

• 

  WhatTheHell 12/08/2014 at 11:27

  Merci…
  au delà du fait de la qualité de l’article.
  Il exprime mon état de nerf face à ce p***** de problème d’encoding entre 2 PC avec 2 versions de windows et 2 versions de python qui essaient de communiquer ensemble. (oui, j’aime me faire du mal…”foooouettez-moi bien fort, maîtresse!!”

• 

  Thomas 12/09/2014 at 09:12

  Superbe article.
  Il m’a beaucoup éclairé sur le sujet.

• 

  hengys 27/09/2014 at 12:06

  Vraiment merci pour le tuto. Cela fait plus de 3 semaines que je galère avec cette histoire d’ encodage. Probleme enfin resolu. Merci vraiment.

• 

  Yax 15/10/2014 at 06:57

  Une explication complète de A à Z pour éviter la migraine :-)

  Merci beaucoup

• 

  Yves Masur 15/11/2014 at 16:46

  Excellent! Merci pour cette synthèse appréciée, je partage.

• 

  Biganon 02/12/2014 at 22:06

  Pourquoi avoir préfixé d’un “u” la chaîne dans msg = u"Page '{}' sauvée\n".format(nom) alors que tu importé unicode_literals ?

• 

  Sam Post author 04/12/2014 at 14:55

  La force de l’habitude. Ca n’a aucune impact.

• 

  Pwalkour 28/12/2014 at 23:44

  Bonsoir, python, c’est tout nouveau pour moi désolé si je dis des bêtises …

  j’vu dans les commentaire qu’une autre personne a rencontré le même que moi, à savoir le problème dees noms de fichiers avec des accents lorsque que l’on utilise walk pour parcourir une arboresence. Je ne pense pas avoir vu de solution où de suggestion …

  l’un de vouspurrait-il m’aider ?

  Avant d’oublier, merci pour cette synthèse très pratique.

  A bientôt et bonnes fêtes de fin d’année à tout le monde.

  Pwalkour

• 

  Sam Post author 29/12/2014 at 08:36

  En pyhton 2.7 :

  >>> from __future__ import print_function >>> import os >>> os.path.walk('/tmp', lambda args, root, files: print(type(root)), ()) <type 'str'> <type 'str'> <type 'str'> <type 'str'> <type 'str'> <type 'str'> <type 'str'> <type 'str'>

  Donc les chemins sont de types bytes, et il faut décoder, comme indiquer dans l’article.

  >>> import os >>> for root, dirs, files in os.walk('/tmp'): print(type(root)) ... <class 'str'> <class 'str'> <class 'str'> <class 'str'> <class 'str'> <class 'str'> <class 'str'> <class 'str'>

  Donc les chemins sont de types unicode, et il n’y a rien à faire.

  Si tu lis l’article, tu sauras exactement quoi faire avec ces informations, il n’y a rien de magique.

• 

  enebre 10/01/2015 at 00:20

  Bonjour à tous,

  les recherches pour un soucis avec python m’ont amené ici, alors je me disais que peut être trouverais-je la solution au problème.

  J’utilise depuis quelques temps mps-youtube, petit outils fort sympathique je dois dire.

  Mais depuis une mise à niveau rien ne va plus, il me sort une erreur tel que celle exposée ici…

  donc j’installe:

  sudo pip install mps-youtube

  puis je lance le soft :

  mpsyt

  j’envoie une recherche,

  .pantera

  je lui demande les infos d’une vidéo

  d2

  ensuite je demande le téléchargement, c’est là que l’erreur se présente :

  10

  mps-youtube a écrit :

  Problem playing last item: 'ascii' codec can't decode byte 0xc3 in position 13: ordinal not in range(128)

  Que puis-je faire ?

• 

  Sam Post author 10/01/2015 at 08:07

  Ta question n’est pas vraiment lié à l’article car tu ne programmes pas, mais utilise le logiciel, donc le mieux c’est que tu la pose ici : indexerror.net.

• 

  Dominique 27/01/2015 at 12:30

  Bonjour, j’essaye d’envoyer des séquences d’échappement à une imprimante HP en réseau (python 2.7 sous Windows, ‘cp850′ pour stdout et ‘mbcs’ pour le système de fichier ).

  J’ai essayé de fixer mes problème d’encoding en lisant l’article et fait des gros gros gros efforts (voir code ci-dessous) pour bosser en unicode!

  Si je tape le tout en python interactif, cela marche a moitier (mais séquences d’échappement sont ignorées… tout ce qui est événtuellement lisible est imprimer… comme @PJL JOB NAME =)

  Le plus étrange, si j’exécute script avec python script.py j’ai l’erreur d’encodage suivante (le script est pourtant sauvé en utf8 par l’éditeur PSPAD).

  Traceback (most recent call last):

  File “hp-minimal-job.py”, line 55, in

  do_simple_pcl_print_job()

  File “hp-minimal-job.py”, line 45, in do_simple_pcl_print_job

  print (u”.join( l )) #.encode( sys.stdout.encoding )

  File “C:\Python27\lib\encodings\cp850.py”, line 12, in encode

  return codecs.charmap_encode(input,errors,encoding_map)

  UnicodeEncodeError: ‘charmap’ codec can’t encode character u’\u2013′ in position

  2: character maps to

  Qu’est ce que j’ai bien pu raté?

  ——————- LE SCRIPT ——————————————–

  !/usr/bin/env python

  -- coding: utf8 --

  import socket

  import sys

  HP Network Printer Connexion Point

  PRINTER_IP = ‘192.168.1.206’

  PRINTER_PORT = 9100

  PJL is used to manage the job and encapsulate a PCL page

  PCL is the content to be printer.

  #

  def pjl_escape( cmd ):

  “”” Prepare an escaped command string with cmd as command content “””

  return u”+chr(27)+cmd

  def pjl_eol():

  “”” return the pjl Enf-of-Line composed of space+cr+lf “””

  return u’ ‘+chr(13)+chr(10)

  def prepare_pjl_job( jobname ):

  “”” initiable a PJL job + switch to PCL language “””

  l = [] # prepare list of string

  l.append( pjl_escape(u’%–12345x’)+str(u’@PJL JOB NAME = “‘)+jobname+str(u'”‘)+pjl_eol() )

  l.append( u’@PJL ENTER LANGUAGE = PCL’+pjl_eol() )

  return u”.join(l)

  def close_pjl_job():

  return pjl_escape(u’%–12345x’)+str(u’ @PJL EOF’)+pjl_eol()+pjl_escape(u’%–12345x’)

  def do_simple_pcl_print_job():

  s = socket.socket( socket.AF_INET, socket.SOCK_STREAM )

  s.connect( (PRINTER_IP, PRINTER_PORT) )

  l = []

  l.append( prepare_pjl_job(u”invoice x customer y”) )

  l.append( u’Essai d impression é@ testing’ ) # PCL command here

  l.append( close_pjl_job() )

  A imprimer

  print (u”.join( l )) #.encode( sys.stdout.encoding )

  for c in (u”.join( l ))[0:-1]:

  print( (‘%03i ‘ % ord(c)).encode( sys.stdout.encoding) )

  Envoyer à l’imprimante

  s.sendall( (u”.join(l)).encode( ‘cp850′ ) ) # Ne pas envoyer le dernier caractère qui est un NULL

  s.close()

  if name == ‘main‘:

  do_simple_pcl_print_job()

• 

  Sam Post author 27/01/2015 at 13:53

  Bonjour dominique,

  Pose ta question ici : indexerror.net

• 

  dacrovinunghi 14/02/2015 at 21:24

  putain merci !

• 

  TurtleCrazy 06/03/2015 at 14:27

  Il faudrait toutefois clarifier ce que demande python3, parce que dire que c’est de l’ Unicode par défaut n’est pas suffisant.

  Unicode est un standard et une norme. C’est tout.

  UTF décrit une “transformation” qui répond au standard Unicode et UTF-8 en est le pendant codé sur 8bits.

  Par contre, préfixer les chaines avec un “u” correspond en général à déclarer une chaine de caractères codée en UTF-8.

  Donc quel est l’encodage par défaut d’un compilateur python3 ? Sachant que dans le monde Windows, le terme ‘Unicode’ est mal employé pour désigner de l’UTF-16(*) alors que dans le monde Unix, il est tout aussi mal employé pour désigner de l’ UTF-8 …

  D’autant que le compilateur ou l’interpréteur peut lire un fichier dans un encodage et en utiliser un autre en interne (un pratique courante est de lire de l’utf-8 ou du latin-1 par défaut – voire exclusivement- et de stocker les chaines en UTF-16 )

  Ce qui d’ailleurs enfonce le clou pour affirmer que l’encodage doit être précisé et ne doit jamais être “supposé” par défaut…

  (*): pire encore, il y a deux UTF-16 (selon l’ endianess) et je ne sais pas lequel est utilisé en interne sous Windows.

• 

  Julian 13/03/2015 at 23:44

  Salut et merci pour l’article!

  J’ai relevé une mini erreur pour la déclaration d’encoding du fichier : # -- coding: utf8 --

  Après essai python2.7 retourne une erreur car c’est : # -- coding: utf-8 --

  C’est tout, simple correction de mini coquille :)

  Good night

• 

  Sam Post author 14/03/2015 at 08:57

  Hum, normalement ce sont des alias, et les deux marchent sur ma machine. Une spécificité windows ? A creuser.

• 

  Fred 08/05/2015 at 08:54

  Oh *;:@\#% de *;:@\#% ! L’article que je cherchais depuis 2~3 ans !

  Une nouvelle ère s’ouvre pour moi désormais.

  Merci

  “Je sais une chose : c’est que j’étais aveugle, maintenant je vois” Jean IX.25

• 

  Drico 22/06/2015 at 19:32

  J’adore le thon employé sur ce site (c’est pas une faute au niveau cul ;-)))

  Dans le genre branlette, je suis tombé sur (je parle d’accent en l’occurrence)

  sur la différence entre les accents composés et les accents décomposés (même moi je n’y ai pas cru)

  Genre un ë et un ë voire un è et un è, ça saute pas à l’œil mais il y’a plusieurs manières de le faire, vu le niveau

  des agitateurs je me dis, et vu l’article que je viens de lire (c’est bon les gars, respect :-))

  Si ça continue je file élever des chèvres dans le Larzac ;-)

  (et comme disais @Coluche il n’y a pas de meeeeehhhhh)

• 

  Gwenmael 13/08/2015 at 10:15

  Bonjour,

  Pouvez vous m’expliquer pourquoi j’obteint systèmatiquement une erreur ? faut-il que j’importe une bibliotèque particulière ?

  IDLE 2.6.5 ==== No Subprocess ====

  coding: utf8

  une_chaine = ‘Chaîne’

  type(une_chaine)

  une_chaine = une_chaine.decode(‘utf8′)

  Traceback (most recent call last):

  File “<pyshell#4>”, line 1, in

  une_chaine = une_chaine.decode(‘utf8′)

  File “C:\ESRI\Python26\ArcGIS10.0\lib\encodings\utf_8.py”, line 16, in decode

  return codecs.utf_8_decode(input, errors, True)

  UnicodeDecodeError: ‘utf8′ codec can’t decode bytes in position 3-5: invalid data

• 

  Max 13/08/2015 at 18:11

  Salut,

  Tu devrais poser ta question sur http://indexerror.net, tu auras plus de chance d’avoir une réponse et ça pourra servir à d’autres.

• 

  Eildosa 15/09/2015 at 11:34

  Bon je croyais avoir tous compris mais je tombe sur cet article.

  Pourquoi ASCII est dans la liste des encodage alors que c’est suposé etre un jeux de caractère? (qui pourrais etre encodé en utf-8 par exemple)

• 

  Sam Post author 16/09/2015 at 06:19

  ASCII et UTF8 sont tous les deux des jeux de caractères (caracter sets). L’encodage (encoding) est le processus qui transforme un jeu de caractères en un autre. Ppour cette raison, on fait , comme dans cet article, souvent l’abus de langage en parlant d'”encoding ASCII” ou “encoding UTF8″ alors qu’on devrait dire “charset ASCII” et “charset UTF8″.

  Comme les jeux de caractères ne sont pas équivalent, l’encoding en Python se fait par une forme intermédiaire, vers laquelle on decode() et depuis laquelle on encode(), ce qui permet de facilement identifier quand le processus échoue : au niveau du charset de départ ou de celui d’arrivée. Cela permet aussi d’isoler le texte comme un type à part en Python 3 : str est considéré comme du texte pur, tandis que tout texte encodé est sous forme de bytes.

  En vérité, str est implémenté en utilisant utf8. Mais on a pas besoin de le savoir, et cela peut changer. C’est juste une API pour donner :

  • une abstraction du texte. Le jour où le texte évolue, on garde la même API et on peut changer l’implémentation.
  • de bonnes habitudes sur le mécanisme d’encodage/décodage.
  • un débuggage plus facile avec des erreurs très précises et des choix explicites sur leurs traitements.