Ubuntu-fr

Yuki

fichiers unicode

Salut à tous !!!

A y est, ma boite est enfin passée sous Linux, et pas n'importe quelle distrib, vu que j'ai une jolie Breezy pour m'amuser et programmer...
Je me suis récemment lancée sur Python, histoire de faire simple et efficace, seulement voilà, j'ai déjà rencontré quelques difficultés.
Je dois manipuler des fichiers, contenant des caractères japonais. Le problème, c'est que je ne sais pas dans quel jeu de caractères ils sont encodés (la commande file me dit ISO-8859).

Sous emacs (probablement muni des extensions adéquates pour les langues asiatiques), tout s'affiche correctement, et je peux exporter mon fichier en UTF-8 sans aucun problème.
Sous Python, quand je lis depuis ce fichier et essaye de convertir les chaines en Unicode, lors d'une lecture du fichier de sortie que je génère, certains caractères disparaissent, d'autres sont remplacés par de gros carrés... Je soupconne Python de ne pas me fournir de l'UTF8 en f:Dait, vu que j'obtiens des résultats différents entre mon output emacs et mon output Python lors de l'affichage des chaines de caractère dans l'interpréteur...

Du coup, j'aimerais savoir s'il est possible de "scripter" en emacs pour convertir le jeu de caractères d'environ 10.000 fichiers en UTF8. J'ai essayé la commande iconv, mais faute de connaitre le jeu de caractère initial, j'ai une sortie du genre \303\210\302\254\302\270\303\215 au lieu de jolis kanji tout beaux...
Ou si quelqu'un a l'habitude de gérer de l'unicode sous python...

Merci d'avance en tout cas

aleph

Re : fichiers unicode

i) Python gère très bien l'unicode et ses différents encodages.
ii) Python possède un excellent fichier d'aide.
iii) Je ne comprends pas ton problème car tout est mélangé : interpréteur, fichiers, chaînes de caractères, encodage, affichage.
iv) Est-ce que tu pourrais au moins me dire si tes scripts Python contiennent des chaînes unicode ?
v) Je ne vois pas le lien entre Linux/Breezy et Python.

Bibi218

Re : fichiers unicode

Heu.... bon j'ai pas compris grand chose non plus a ton pb Yuki...
Par contre, pour avoir du me frotter a des caracteres exotiques sous Python, je profite pour parasiter un peu si vous permettez

Exemples a l'appui, ce sera plus parlant. J'ai un fichier disons log.txt encode dans un format que je ne connais pas, et la lecture d'une ligne sous Python me donne

chaine1='\xc8\xac\xb8\xcd+{\xa5\xcf\xa5\xc1\xa5\xce\xa5\xd8}\n'

Le meme fichier converti au prealable en UTF8 sous emacs me revoie, toujours sour Python

chaine2='\x1b$BH,8M\x1b(B+{\x1b$B%O%A%N%X\x1b(B}\n'

He ben croyez moi ou non, je vois pas du tout comment convertir la premiere chaine dans le meme format que la seconde (le but etant de verifier si elles representent les memes caracteres, genre chaine1==chaine2).

J'ai bien essaye de faire du

tmp=unicode(chaine1,"charset au choix")
chaine1=tmp.encode( "utf-8")

mais je pense que mon charset n'est pas supporte en standard dans python http://www.python.org/doc/2.3.5/lib/node130.html

En esperant ne pas trop faire de HS ^^; (ceci dit, ca parle de texte et d'unicode a l'origine)

PS : desole pour les accents, clavier americain...

aleph

Re : fichiers unicode

> Bibi218

Ce n'est pas hors sujet, tu as correctement mis le doigt sur le problème.

Cela dit,

- Python gère tous les codecs en standard sur toutes les platformes.
- Tes variables chaine1 et chaine2 ne sont pas des variables Python de type unicode.

Peut pas faire plus.

Compte supprimé

Re : fichiers unicode

Pourtant ici http://www.python.org/doc/2.3.5/lib/node130.html je n'ai vu aucune trace des systemes d'encodage utilises au Japon (SHIFT-JIS, EUC-JP, pour en citer des connus)
Ensuite, que chaine1 ne soit pas une chaine unicode, je veux bien, vu qu'elle vient d'un fichier qui n'est pas ecrit avec ce charset. Par contre, pour chaine2, j'ai deja beaucoup plus de mal a voir la marche a suivre
Mon fichier est code en UTF-8, alors betement, je vais juste un truc du genre

file="mon_fichier.txt"
f=open(file,'r')
line=f.readline()
unicode_line=unicode(line,"utf-8")   #je viens d'y penser a ca :lol:

Mais a l'affichage, peu de progres... juste un joli 'u' devant pour me dire que maintenant j'ai de l'unicode...

u'\x1b$BH,8M\x1b(B+{\x1b$B%O%A%N%X\x1b(B}\n'

Certainement qu'il y a un truc que je fais mal, loin de moi l'idee d'accuser Python Par contre, j'aimerais bien savoir quoi

aleph

Re : fichiers unicode

Une réponse rapide en quelques points, je suis à la bourre.

- Je ne sais pas si Python connaît tous les encodages existants. Ce que je veux dire est que tous les encodages que Python connait sont livrés en standard, sur ma platforme ils sont dans C:\Python24\Lib.

- Le fichier que tu lis, mon_fichier.txt, n'est pas lu en Unicode mais en bytes. Ta commande ne vas pas convertir les bytes que tu as lu, puis que ceux-ci ne représentent pas des caractères unicode.

- Pour lire un fichier unicode dont on connaît l'encodage, ici utf-8
import codecs
f = codecs.open("mon_fichier.txt", "r", "utf-8")
text = f.read()
f.close()
Tout le fichier est maintenant dans la variable text qui est du type unicode.

- u'\x1b$BH,8M\x1b(B+{\x1b$B%O%A%N%X\x1b(B}\n'. Oui, c'est bien un unicode dans le sens Python. Mais ce n'est pas un "string unicode", c'est une var unicode qui contient des bytes, ce que l'on appelle souvent un byte string.

- Pour corser le tout. Quand on veut afficher un correctement un unicode, il faut connaître l'encodage de l'outil de l'affichage. Celui-ci varie selon les platformes et les logiciels. Dans mon Python shell, psi, http://www.chez.com/spinecho/, il est possible de définir l'encodage de sortie, IDLE le permet aussi. emacs le permet probablement.

- Pas évident ? Oui.

Compte supprimé

Re : fichiers unicode

Ahhhh, ca commence a s'eclaircir... je ferai un petit essai sur ce module "codecs" demain matin
Apres, en ce qui concerne l'affichage, je m'en fiche un peu, tant que ca apparait comme il faut dans mon fichier txt.
D'apres ce que je vois, chaine1 de mon exemple est codee en hexa, mais je suppose que c'est impossible de pouvoir determiner le charset utilise si on l'ignore, n'est-ce pas ??? (c'est trop inzuste... ) Je me demande comment fait emacs pour faire mouche a presque tous les coups
En tout cas, merci beaucoup de ton aide !!! Meme si je n'arrive pas a avancer plus demain, j'aurai au moins appris des trucs

aleph

Re : fichiers unicode

> Bibi218
> Apres, en ce qui concerne l'affichage, je m'en fiche un peu, tant que ca apparait comme
> il faut dans mon fichier txt.

Surtout pas, c'est le piège à éviter. Il est très important de connaître l'encodage utilisé de ton dispositif d'affichage. Un affichage correct peut faire croire que ton fichier ou string unicode est correct alors qu'il ne l'est pas !

Le cas typique vient des USA. Beaucoup d'utisateurs ne se rendent même pas compte dans quel encodage ils travaillent. ascii ou utf-8, car les "code points" sont représentés par un byte dans le deux cas. Autrement dit, l'affichage paraît correct dans les deux cas. Un vrai cauchemar.

Compte supprimé

Re : fichiers unicode

Aaahhh, ils pourraient pas faire un truc du genre "sauver par défaut en UTF8" par exemple dans les editeurs de texte, histoire que tout le monde sache sur quel pied danser ??? Apres tout, la mode est a l'interoperabilite non ???
Bon apres pour les developpeurs, je sais pas si ca serait vraiment un cadeau
Allez, je teste ce fameux module "codecs", et je reviens...

aleph

Re : fichiers unicode

>Bibi218
Il me semble que tu commences à mélanger les pinceaux, unicode, affichage, sauvegarde, édition...

Pout débuter, un excellent article court et synthétique.

"The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About
Unicode and Character Sets (No Excuses!)"
http://www.joelonsoftware.com/articles/Unicode.html

Compte supprimé

Re : fichiers unicode

Bon, j'avance lentement mais surement, faut pas croire... J'ai enfin reussi a identifier le codage d'entree de mon log, le EUC-JP, gere par Python en plus (ouf ). J'ai egalement employe la solution bourrine en restant en EUC-JP tout le temps (maintenant que j'ai le format...), seulement sur le plan de l'orgueil c'est pas vraiment tres satisfaisant...

>>> import codecs
>>> f=codecs.open("log.tmp",'r',"euc-jp")
>>> line1=f.readline()
>>> f.close()
>>> line1
u'\u672d\u5e4c+\u30b5\u30c3\u30dd\u30ed\n'
>>> f=codecs.open("logutf8.tmp,'r',"utf-8")
>>> line2=f.readline()
>>> f.close()
>>> lines2
u'\x1b$BH,8M\x1b(B+\x1b$B%O%A%N%X\x1b(B\n'

Le probleme maintenant, c'est de reussir a comparer la premiere chaine et la seconde. Le hic, c'est que si j'ai bien compris ce que tu m'as dit, la premiere est une unicode string, tandis que la seconde est une byte string (j'ai bon ???). Du coup, sur quelle base partir ? Je ne tire rien de la seconde chaine, a part la convertir en hexa, ce qui ne m'avance pas a grand chose. N'y aurait-il pas moyen de "l'evaluer" afin de la transformer en unicode string tout simple ???

Compte supprimé

Re : fichiers unicode

Desole, je crois que je commence a tout embrouiller aussi...
J'avais pas vu le lien, je m'en vais lire ca sur le champ

aleph

Re : fichiers unicode

Bien joué. Essayons maintenant de disséquer tes propos.

> J'ai enfin reussi a identifier le codage d'entree de mon log, le EUC-JP, gere par Python en plus (ouf big_smile).
J'ai toujours dit que Python était génial.

> Le probleme maintenant, c'est de reussir a comparer la premiere chaine et la seconde.
Nous avons donc 2 variables Python de type unicode, nous pouvons donc les comparer

>>> line1 == line2
False

> Le hic, c'est que si j'ai bien compris ce que tu m'as dit, la premiere est une unicode string, tandis que la seconde est une byte string (j'ai bon ???).

Exactement. Toi, y en a tout bon.

> Du coup, sur quelle base partir ?
Nous allons faire quelques tests.

> Je ne tire rien de la seconde chaine, a part la convertir en hexa, ce qui ne m'avance pas a grand chose.
Ces propos n'ont aucun sens. Concertir un unicode en hexa ne veut rien dire.

> N'y aurait-il pas moyen de "l'evaluer" afin de la transformer en unicode string tout simple ???
C'est déjà un unicode, on ne peut pas la transformer. C'est quoi un unicode tout simple ? Un unicode est un unicode, point.
Nous savons que line1 != line2. Quelques tests supplémentaires.

>>> len(line1)
8
Line 1 contient "8 code points"

>>> len(line2)
26
Line 1 contient 26  quoi ?

>>> len(line1.encode('utf-8'))
20
20 bytes pour composer l'unicode line1

>>> len(line2.encode('utf-8'))
26
26 bytes, en supposant que line2 sont un unicode "valide".

Ceci nous conforte dans l'idée que line1 != line2

Pour aller plus loin, tu peux jouer avec des
for char in ... :

Bon. Maintenant, essayons de visualiser le contenu de line1 et line2. C'est ici qu'intervient
toute l'importance de l'encodage du dispositif d'affichage. Nous allons encoder les unicodes line1 et line2 de façon identique pour essyer de voir leurs contenus à l'écran.
Pour mes essais, j'utilise IDLE sur windows 2000. Je *sais* que pour afficher correctement, il faut que j'utilise l'encodage cp1252 ou plutôt je *sais* que l'encodage cp1252 sur windows 2000 en utilisant IDLE qui est basé sur le toolkit Tcl/Tk fonctionne très bien.

Ici intervient un petit problème annexe. line1 contient des "code points" japonais. Je vais avoir des problèmes pour les visualiser. Qu'ä cela ne tienne, Python a tout prévu !
La fonction d'encode Python contient un paramètre permettant de gérer les problèmes d'encodage; pour faire court, c'est strict, ignore ou replace. L'option replace mettra un ? où il y a problème. Je te laisse voir la doc.
Appliquons, toujours dans IDLE

>>> print line1.encode('cp1252', 'replace')
??+????
Sept "chars" ou glyphes, 6 en je ne sais pas quoi et un plus.
Question: 7 chars ?, j'ai dit plus haut huit ! Réponse: le dernier char est un \n. Vicieux non ?

>>> print line2.encode('cp1252', 'replace')
$BH,8M(B+$B%O%A%N%X(B

Plutôt différent, non.

Voilà pour une première approche. Un oeil exercé aurait pu voir que le premier char de line2 correspond à ESC, \x1b

Ne te fais pas de souci pour ton orgueil. Cela me fait plaisir de m'entretenir avec quelqu'un qui veut comprendre. J'apprécierais bien une réponse.

Compte supprimé

Re : fichiers unicode

Tout d'abord, merci beaucoup pour ta patience... j'apprecie enormement.
J'ai bien lu le petit lien que tu m'avais envoye, pas sur que ca ait tout eclairci, mais au moins deux ou trois choses sont rentrees

Bon, je reprends un peu du debut...
J'ai un fichier log, que je sais maintenant code en EUC-JP (mon dieu que j'en ai bave pour le trouver cet encodage...). Grace a emacs, j'ai pu le convertir au format UTF8 (en faisant 'set-charset' ou quelque chose dans le genre). A l'ecran, le resultat est le meme. Potentiellement piegeux a ce que tu dis, mais je ne sais pas comment determiner le charset d'affichage... je croyais naivement que c'etait celui dans lequel est encode le fichier ???
C'est precisement ca qui me frustre, c'est que je sais (ou crois savoir) que les infos contenues sont les memes, mais juste codees differemment...

Dans ma folie destructrice, j'ai continue a faire des tests dans l'apres-midi, sans faire rentrer de japonais. Je me suis dit que des lettres accentuees, ca me permettrait de mieux voir le probleme.

Soit la chaine str="àéèù"
2 choix on va dire, soit je considere que c'est une chaine iso-8859-1

>>> str="àéèù"
>>> str
'\xe0\xe9\xe8\xf9'
# on convertit en string Unicode, jusque la, c'est bon
>>> ustr=str.decode("iso-8859-1")
# ici je commence a avoir un doute metaphysique... ca voudrait dire que ces caracteres ont la meme valeur
# dans les 2 systemes de codage ??? bon oki, pourquoi pas....
>>> ustr
u'\xe0\xe9\xe8\xf9'
# a partir du string unicode, on peut encoder dans un nouveau format, a savoir utf8
>>> ustr.encode("utf-8")
'\xc3\xa0\xc3\xa9\xc3\xa8\xc3\xb9'
>>> print ustr.encode("utf-8")
à éèà¹

Deja la, ca me fait bizarre. Ensuite dans l'autre sens

>>> str.decode("utf-8")

Traceback (most recent call last):
  File "<pyshell#13>", line 1, in -toplevel-
    str.decode("utf-8")
  File "xxxxxx/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 0-2: invalid data

encore plus bizarre. Les accents ne seraient pas reconnus ??? Pas possible

Je commence a douter de mes facultes avec un clavier la

PS : je savais pour les \n, c'est moi qui les ai mis

Compte supprimé

Re : fichiers unicode

Je viens de me rendre compte que je procedais a un detournement de post savament organise Desole Yuki...

aleph

Re : fichiers unicode

> Tout d'abord, merci beaucoup pour ta patience... j'apprecie
enormement. J'ai bien lu le petit lien que tu m'avais envoye,
pas sur que ca ait tout eclairci, mais au moins deux ou trois
choses sont rentrees

Relis le...

> Bon, je reprends un peu du debut...
J'ai un fichier log, que je sais maintenant code en EUC-JP (mon
dieu que j'en ai bave pour le trouver cet encodage...).

Eh oui, une source quelconque, e-mail, string, ou fichier texte
sans information sur l'encodage n'a aucun sens. Comme cela est
très bien expliqué dans l'article du lien que je t'ai donné.

>Grace a emacs, j'ai pu le convertir au format UTF8
(en faisant 'set-charset' ou quelque chose dans le genre).

Là, je ne peux t'aider. C'est à toi de découvrir l'encodage
du fichier que tu as. Si on ne connait pas l'encodage, cela
semble du moins à de l'unicode:
line1 = u'\u672d\u5e4c+\u30b5\u30c3\u30dd\u30ed\n'
Sous Linux, ça m'étonnerait fort qu'il n'y ait pas
un tool que fasse le job en une seule commande.

> A l'ecran, le resultat est le meme. Potentiellement piegeux
a ce que tu dis, mais je ne sais pas comment determiner le
charset d'affichage... je croyais naivement que c'etait
celui dans lequel est encode le fichier ??? neutral
C'est precisement ca qui me frustre, c'est que je sais
(ou crois savoir) que les infos contenues sont les memes,
mais juste codees differemment... roll

Tu le dis justement, les infos sont là mais on ne connaît
pas l'encodage. L'encodage du fichier est une chose,
l'encodage d'affichage d'emacs en est une autre. En tout cas,
il n'y a aucun lien entre les deux. Il se peut que par pur
coïncidence, ce soit les mêmes.

> Dans ma folie destructrice, j'ai continue a faire des tests
dans l'apres-midi, sans faire rentrer de japonais. Je me suis
dit que des lettres accentuees, ca me permettrait de mieux voir
le probleme.

C'est rigolo, non ? Le fait que le code points soient du japonais
n'a pas beaucoup d'importance. Ce ne sont que des code points.
L'inconvénient est seulement que l'affichage pose problème si
les polices ne sont pas disponibles. Il n'y a pas beaucoup
de fontes disponibles sur le "marché", la meilleure - à mes
yeux - pour le moment est MS Arial Unicode, c'est du moins
la plus complète.
Pour jouer et t'exercer, tu peux prendre le caractère euro dont
le code point est U+20AC, c'est à dire au delà de "256 premiers
caractères usuels".

>Soit la chaine str="àéèù"
2 choix on va dire, soit je considere que c'est une chaine iso-8859-1

L'encodage est défini pas ton dispositif d'entrée, donc connu.

-------

>>> str="àéèù"
>>> str
'\xe0\xe9\xe8\xf9'

Soit, str est un type string en Python encodé en ISO-8859-1.
Note: évite str comme variable, str est aussi une fct.

# on convertit en string Unicode, jusque la, c'est bon
>>> ustr=str.decode("iso-8859-1")

Oui, plus élégant : ustr = unicode(str, 'ISO-8859-1')

# ici je commence a avoir un doute metaphysique... ca voudrait
dire que ces caracteres ont la meme valeur
# dans les 2 systemes de codage ??? bon oki, pourquoi pas....
>>> ustr
u'\xe0\xe9\xe8\xf9'

Disons qu'ils contiennent la même information.

# a partir du string unicode, on peut encoder dans un nouveau format,
a savoir utf8
>>> ustr.encode("utf-8")
'\xc3\xa0\xc3\xa9\xc3\xa8\xc3\xb9'

Oui.

>>> print ustr.encode("utf-8")
à éèà¹

Résultat correct ! Où est l'erreur ?
L'erreur vient que ton affichage n'est pas géré en UTF-8, mais
probalement en IS0-8859-1. Ce qui explique les huit caractères
affichés, chaque code point à,é,è,ù (pas très correct, mais comment
les représenter ?) est représenté par deux bytes dans un encodage
UTF-8. Voir l'acticle proposé.
Un print ustr te donnera probablement àéèù

La même expérience sous Windows 2000, IDLE, encodage d'entrée cp1252,
encodage de sortie (affichage), cp1252.

>>> s = "àéèù"
>>> u = unicode(s, 'cp1252')
>>> u
u'\xe0\xe9\xe8\xf9'
>>> print u.encode('utf-8')
à éèà¹
>>> print u.encode('cp1252')
àéèù
>>> print u
àéèù

Tu noteras que print u.encode('cp1252') est identique à print u.
Pourquoi ? Simplement parce que cp1252 est le codage de sortie par
défault ! La preuve:

>>> sys.stdout.encoding
'cp1252'
>>>

--------

> Deja la, ca me fait bizarre. Ensuite dans l'autre sens
Non

------

>>> str.decode("utf-8")

Traceback (most recent call last):
  File "<pyshell#13>", line 1, in -toplevel-
    str.decode("utf-8")
  File "xxxxxx/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 0-2: invalid data

> encore plus bizarre. Les accents ne seraient pas reconnus ???
Pas possible hmm

C'est tout a fait correct et logique. La variable str étant encodée
en ISO-8859-1, il est donc impossible de la décoder avec un
"algorithme utf-8", Python se plaint de ne pouvoir faire ce travail
et nous en informe. Tu noteras que le message d'erreur parle de bytes
et non de caractères.
Un grand, très grand, coup de chapeau aux dévelopeurs Python.
A propos, as-tu pris conscience que nous avons fait tout ça, sans
jamais compiler un ligne de code ?

Le string line1 semble bien contenir des caractère CJK (Chinese-Japanese
-Korean). La valeur des codes points semble bien être dans cette plage.
A vérifier par le web.
>>> for c in line1:
        print c, ord(c)
? 26413
? 24140
+ 43
? 12469
? 12483
? 12509
? 12525
>>>

Voilà, je crois que nous avons fait un peu le tour du problème.
Maintenant que tu lises un fichier japonais, français ou russe,
la technique reste la même.
Je pense que cela t'aidera aussi à comprendre comment les navigateurs
web fonctionnent et pourquoi on peut choisir un encodage pour l'affichage.
Peut-être n'avais-tu pas fait le lien ?

En tout cas, rappelle-toi d'une chose:
*** Un string sans information sur son encodage n'a aucune valeur. ***
En espérant avoir un peu éclairé ta lanterne, comme l'on dit.
Désolé de ne pas être "sous Linux". Mais ça c'est une autre histoire.

Un peu de pub pour mon site, orienté Python
http://www.chez.spinecho.com.

aleph, Jean-Michel Fauth.

Compte supprimé

Re : fichiers unicode

Nouveaux tests ce matin... j'arrive enfin a faire du "bijectif", c'est a dire passer d'un encodage a l'autre sans perte d'info Ohh joie !!!

Bizarrement, les terminaux dans lesquels je travaillais etaient en UTF-8 pour la saisie, mais pas l'affichage manifestement. J'ai du passer par un uxterm pour avoir les deux.

La ou je ne comprends plus rien, c'est que ma conversion EUC-JP >> UTF-8 sous emacs semble ne pas avoir marche. Je trouve cette chaine

u'\x1b$BH,8M\x1b(B+\x1b$B%O%A%N%X\x1b(B\n'

est particulierement "horrible" en comparaison avec le "joli" unicode version Python, et si en plus tu me dis que le premier caractere semble etre ESC (allez savoir ce qu'il fait la...).

De meme, quand je lis mon fichier converti via python (qui est "juste", je l'ai verifie), emacs me fait un display vraiment etrange du genre de ceux qu'obtenait Yuki :

\350\225\250+{\343\203\257\343\203\251\343\203\223}

Moralite, maintenant c'est plus un probleme d'emacs que de Python

Dernière modification par Bibi218 (Le 26/05/2006, à 03:50)

aleph

Re : fichiers unicode

> Bibi218

> Moralite, maintenant c'est plus un probleme d'emacs que de Python

Bonne conclusion, maintenant que tu sais ce qu'est un encodage.
\x1b == esc (27 en decimal).

Compte supprimé

Re : fichiers unicode

Au passage, merci encore pour ton aide
Entre parentheses, je remercie les gars de chez Python pour le support des charsets et je plains ceux qui doivent gerer tout ca a la mano... enfin chacun ses problemes hein