'utf8' codec can't decode byte 0xe9 in position 539: invalid continuation byte

Salut tout le monde,

J'ouvre une page html vi le serveur applicatif de Django, et j'obtiens l'erreur suivante :
'utf8' codec can't decode byte 0xe9 in position 539: invalid continuation byte

Est-ce que quelqu'un aurait une idée? QUe faut-il faire?

Merci d'avance

Rajoute le

Code:

---

# -*- coding: utf-8 -*-

---

en début de fichier.

Edit: ou vérifier l'encodage des fichiers html.

Je l'ai mis au début de mon fichier views.py, et ça ne fonctionne pas non plus...
C'est au début de quel fichier?

Réponse

A vrai dire je fais juste une redirection vers une page HTML donc à priori je n'ai pas besoin d'encode quoi que ce soit :


=>url(r'^Mysite/signup/$', 'Mysite.MysiteTEST.views.signup_view')

Qui renvoie vers la vue suivante :
def signup_view(request):
return render_to_response("signup.html")

signup.html est une page HTML standard avec quelques CSS et un script JS...

D'autres idées?

Merci d'avance!

Salut,

Citation:

---

signup.html est une page HTML standard avec quelques CSS et un script JS...

---

Si la page HTML standard contient des caractères accentués, il faudra préciser comment ils sont encodés d'une façon ou d'une autre.
Dans votre cas, cela se passe comme si on lisait un caractère accentué "latin-1" avec un décodeur utf-8.

- W

il faut définir l'encodage au début du code source python.

Code:

---

# -*- coding: <encoding name> -*-

---

Salut,

Citation:

---

Envoyé par Golgotha

il faut définir l'encodage au début du code source python.

Code:

---

# -*- coding: <encoding name> -*-

---

---

Probablement... mais cela ne vaut que pour les fichiers "script" lus par l'interpréteur et non les fichiers "autres" lus par le programme interprété.
- W

Salut ,

j'ai eu ce genre d'erreur il y a peu.

Dans mon cas, je faisais une importation de données d'une vieille base aux encodages multiples vers une nouvelle base bien propre utilisée par mon appli Django.

pour ne pas interrompre l'importation, j'ai effectué un traitement mineur au champs causant ce problème :

Code:

---

1 2 3 4

... f[1].encode('unicode_escape'), ...

---

Le résultat obtenu, est une chaine d'octects donc les caractères spéciaux se retrouvent affichés d'une façon brute et non converti .

En espérant que cela va t'aider :)


Petites explications sur l'utilisation de encode() et 'unicode_escape'

Bonjour ici,

J'ai un soucis à peu près du même charactère (petit jeu de mot :mouarf:)

Donc j'ai un client java qui communique avec un serveur python.

Mon serveur est fait pour recevoir des JSON Strings, donc encodées en UTF-8.

Voilà comment mon client (java) envoie des données :

Code:

---

1 2 3

this.out.writeBytes(this.escapeContent(message)+"\n"); //la méthode escape content n'influe pas sur le probleme d'encodage (testé sans) this.out.flush();

---

Et voici comment mon serveur (python) les récupère :

Code:

---

1 2 3 4 5

data = self.socket.recv(1024) if not data: break dataList=data.decode('utf8').split("\n")

---

Tout fonctionne impeccablement jusqu'à ce qu'un character accentué (ou autre) pointe son nez et.... TADAM ! Exception !

Code:

---

1 2	UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 12: invalid continuation byte

---

Traiter l'exception n'est pas un probleme, le probleme est surtout de bien encoder les données envoyées (job de java) ou de bien les décoder (job de python). Donc j'ai essayé de remplacer le writeBytes par un writeUTF, mais quand python reçoit ma JSON String, il la considère comme non json (et donc exception de décodage json).

Donc est ce que le probleme doit être réglé dans java, quand j'encode mes datas (dans quel cas je pourrai aller faire un petit coucou au forum java :D), ou dans python quand je les décode ?

Merci pour votre attention :)

Salut,

Si vous preniez le temps de lire le post donné en référence dans celui de fred1599 vous suspecteriez plutôt Java d'expédier du "latin-1" et non de l'"utf-8".

Si vous allez dans le forum Java demandez aussi comment "tester" le code "Java" pour s'assurer qu'il expédie bien de "l'utf-8" avant que les applications "python" (ou autres) qui le récupèrent se prennent les pieds dans le tapis.

- W