Forum Programmation.python UnicodeDecodeError sur un simple readlines (python3, crontab)

Posté par .
Tags : aucun
0
12
août
2010
Bonjour à tous,

petit problème aujourd'hui, j'ai écrit un petit script bash qui se contente de récupérer un fichier avec wget puis de le traiter avec python3.1. Jusqu'ici tout va bien et mon programme fonctionne comme je veux.

Cependant, dès que je mets ce script dans ma crontab, le script plante durant l'exécution du code python.

Voici l'erreur :
File "/home/baleyjul/projets/chinese_tools/stardictizer.py", line 9, in stardictizer
dictionary = f.readlines()
File "/usr/lib/python3.1/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 783: ordinal not in range(128)

Il plante sur le readlines! Le fichier en entrée est codé en UTF8 et contient des caractères de diverses langues (fichier dictionnaire chinois=>anglais, avec des mots en coréen, français, etc).

Quelqu'un saurait-il pour quelle raison python me parle d'ascii? Pourquoi le script fonctionne sans problème lorsque je l'exécute dans ma console, mais pas lancé en tâche cron?

Merci d'avance.
  • # environnement ?

    Posté par (page perso) . Évalué à 2.

    env renvoie la même chose en console et dans la crontab ?

    Système - Réseau - Sécurité Open Source

    • [^] # Re: environnement ?

      Posté par . Évalué à 1.

      Bon, c'était mon premier script.
      En effet, les deux environnements n'étaient pas identiques et avec un export de LANG (=zh_CN.UTF-8 dans mon cas) dans mon script, ça fonctionne à présent sans problème. Étrange tout de même qu'UTF-8 ne soit pas un "par défaut" dans ce genre de contextes...

      Merci beaucoup en tout cas.
      • [^] # Re: environnement ?

        Posté par (page perso) . Évalué à 3.

        Étrange tout de même qu'UTF-8 ne soit pas un "par défaut" dans ce genre de contexte
        Voir par exemple /etc/default/locale et /etc/environment
        • [^] # Re: environnement ?

          Posté par . Évalué à 1.

          Eh bien justement, /etc/default/locale contient fr_FR.UTF8, alors je ne sais pas... Je n'y connais vraiment rien, il faut que je me documente, c'est certain. Mais je croyais que tout était en UTF8 sous les distribs récentes.
          • [^] # Re: environnement ?

            Posté par . Évalué à 1.

            J'ai rencontré un problème similaire récemment, mais avec stdout. Dans le doute voici ce qui bloquait sous Python 2.x:

            #!/usr/bin/python
            # -*- coding: utf-8 -*-

            import sys
            import locale

            print "preferred encoding = {0}".format(locale.getpreferredencoding())
            print "but ..."
            print "sys.stdout.encoding = {0}".format(sys.stdout.encoding)
            print "sys.stdin.encoding = {0}".format(sys.stdin.encoding)
            print "therefore 'print u'unicode string' results in ..."
            print u" *** Python, çuckß *** "


            Maintenant, si tu fais tourner le script précédent avec :
            bash $ LANG="fr_FR.UTF-8" python script.py
            bash $ LANG="C" python script.py
            bash $ LANG="en_GB.UTF-8" python script.py | cat
            bash $ LANG="en_GB.UTF-8" echo "foobar" | python script.py
            bash $ LANG="en_GB.UTF-8" echo "foobar" | python script.py | cat

            … tu vas obtenir 5 résultats différents.

            Je suppose que ta crontab fait tourner ton script dans un environnement particulier (locales ou LANG différents) ou, pire encore, que tu utilises des pipes ! Essaie de faire tourner le script précédent en remplaçant stdout par stdin et de logger son résultat dans un fichier externe pour comprendre le schmilblick.

            Plus d'info: http://docs.python.org/howto/unicode.html#reading-and-writin(...) (page qui peut se résumer avec a) toujours utiliser string.decode(charset) sur les entrées b) toujours utiliser string.encode(charset) sur les sorties)

            … mais qui ose encore dire que python est simple ???
            • [^] # Re: environnement ?

              Posté par . Évalué à 1.

              Oh, désolé, je n'ai pas dû être clair dans ma première réponse au post de nono14, mais j'ai résolu le problème en indiquant clairement la LANG dans mon script.

              Par défaut, le "env" de cron est presque vide (et rien concernant locale ou langue) chez moi.
            • [^] # Re: environnement ?

              Posté par . Évalué à 2.

              J'oubliais... et python 3, c'est censé être tout en UTF8 par défaut, non? Je utilise cette version principalement pour son support d'unicode, afin d'éviter tout le bazar inhérant à la gestion de l'unicode dans les versions 2.x (jusqu'à 2.5 seulement? je n'ai pas suivi ça).
              • [^] # Re: environnement ?

                Posté par . Évalué à 2.

                Aucune idée. Mais de toutes façons, qui s'en soucie de python3k ? Personne !

                Même pas les développeurs python eux même, vu l'état du "Python 3K - Unicode HOWTO":

                This HOWTO discusses Python 2.x’s support for Unicode, and explains various problems that people commonly encounter when trying to work with Unicode. (This HOWTO has not yet been updated to cover the 3.x versions of Python.)

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

                // Mauvais humour mis à part:
                Oui le "bug" précédent est corrigé dans python3k et oui python3k traite tous les 'string' comme des objets Unicode. Reste plus qu'à éviter de confondre b"hello world" avec "hello world".
              • [^] # Re: environnement ?

                Posté par . Évalué à 1.

                Python 3 a une solution simple pour "éviter" les problèmes d'encodage : pour lui, par défaut, tout est en UTF-8. Donc dès que tu lui donnes quelque chose d'autre sans le préciser, il se plante. C'est tout.
                • [^] # Re: environnement ?

                  Posté par . Évalué à 2.

                  Mon fichier est justement en utf8, (comme indiqué dans le post initial) d'où mon étonnement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.