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.

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)

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.

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

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)

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

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

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.