Accents dans le nom du fichier template

Salut à tous,

j'ai une erreur pas très courantes! Le nom de mes templates possèdent des accents et potentiellement des caractères spéciaux.
Alors oui, c'est pas propre :aie:, mais mes templates sont généré automatiquement par un autre programme. Je ne peut obliger le client à ne pas mettre d'accents dans sont programme, ainsi je me retrouve parfois avec des noms de templates avec accents. L'erreur généré est la suivante:

UnicodeEncodeError at /zim/Présentation.html
'ascii' codec can't encode character u'\xe9' in position 37: ordinal not in range(128)

L'erreur est déclenché par la vue:

Code:

---

1 2 3 4 5

#-*- coding: utf-8 -*- from django.shortcuts import render   def page(request, page): return render(request, u"%s.html" % page)

---

Ainsi quand un utilisateur essai d’accéder à la page "Présentation.html" l'erreur est déclenché. Je ne comprend vraiment pas comment résoudre ce problème.

Si quelqu'un a déjà eu le problème... help me please! :calim2:
Merci.

Slt
Tu vas devoir décoder ton entrée externe ( nom de fichier )

Article très clair sur ce sujet qui va certainement résoudre ton problème.

http://sametmax.com/lencoding-en-pyt...is-pour-toute/

Ch

Salut,

Merci pour l'aide. L'article est super et je vient de comprendre des trucs... mais apparemment c'est pas suffisant! :roll:
Suite à cette lecture voici se qui me semble le plus correcte.

Code:

---

1 2 3 4 5 6

#-*- coding: utf-8 -*- from django.shortcuts import render   def page(request, page): template = '%s.html' % page return render(request, template.encode('utf8'))

---

Mais j'ai toujours encore la même erreur.

Note intéressante: L'erreur ne se produit pas en local. Uniquement sur le serveur. Comme si sur le serveur l'encodage était différent.

salut,

Citation:

---

Envoyé par Snooky68

Note intéressante: L'erreur ne se produit pas en local. Uniquement sur le serveur. Comme si sur le serveur l'encodage était différent.

---

J'ai déjà eu un problème similaire en développant avec Eclipse/Pydev.

Python a un encodage par défaut (peut être différent en fonction du système, je sais pas) et dans certain cas il se sert de cet encodage par défaut pour effectuer des encodages/décodages implicites.
on peut retrouver cet encodage par défaut en exécutant un fichier contenant le code suivant:

Code:

---

1 2	import sys sys.getdefaultencoding()

---

Si ce simple code ne donne pas le même résultat depuis ton environnement de dev et ton environnement de prod, la suite peut t'interesser.

---

Mon problème venait du fait que Eclipse/Pydev modifiait cet encodage par défaut en fonction de la declaration d'encodage du fichier .py et que ça masquait des erreurs potentielles.

Un exemple étant plus parlant qu'une longue explication, considérons le code suivant:

Code:

---

1 2	# coding:utf-8 u"ûnë chàïne ùnîcödè".encode("utf-8").encode("utf-8")

---

Dans un environnement ou l'encodage par défaut de Python est "ascii", il provoque l'erreur suivante:

Citation:

---

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)

---

Il parait normal que ce code plante puisque qu'on cherche à encoder une chaine déjà encodée, ce qui est plus étonnant c'est que l'erreur parle d'une erreur de décodage alors que c'est un encodage qu'on cherche à faire.

Une petite explication pour bien comprendre:
- on a une chaine unicode avec plein de caractères spéciaux et d'accents
- on l'encode une première fois en utf-8 et on obtient donc suite d'octets en utf-8
- on l'encode une deuxième fois en utf-8 et c'est là qu'il y a problème:

- Python ne sait pas encoder une suite d'octets, il ne sait encoder que des objets de type str ou unicode
- Python décide donc de décoder cette suite d'octets pour obtenir ce qu'il veut et comme il ne sait pas quel encoding utiliser, il prend son encodage par défaut (pour rappel, "ascii" pour notre exemple. oui, le mal réside aussi dans les conversions implicites)
- Python tombe sur des octets avec une valeur supérieur à 127 (qui ne sont donc pas de l'ascii), qu'il ne peut donc pas décoder et lève donc une erreur

et là on comprend mieux pourquoi l'erreur parle de décodage alors qu'on cherche à encoder.

Tout ça parait donc très normal et on peut légitimement se demander pourquoi ça passe dans Eclipse/Pydev. La réponse c'est que Eclipse/Pydev se croyant malin, en voyant un "# coding:utf-8" au début du fichier, se dit que ça va sans doute nous arranger s'il passe l'encodage par défaut de Python à "utf-8" et en faisant ça, il masque l'erreur qui devrait se produire avec le code fourni plus tôt:
- la chaine unicode est encodé en utf-8
- on cherche à encoder en utf-8 la suite d'octets utf-8

- python fait alors son décodage implicite en utilisant l'encodage par défaut (soit utf-8) et tout se passe bien (c'est là qu'on aurait du avoir une erreur)
- il peut alors encoder tranquillement la chaine qu'il a décodé implicitement.

moralité: une erreur qui passe inaperçu en environnement de dev et qui va se faire un plaisir de péter dés qu'elle sera sortie d'Eclipse/Pydev.

---

Après tu n'utilises peut être pas Eclipse/Pydev et ton erreur ne vient peut être pas de là, mais vu les symptomes, je pense que ça vaut le coup de vérifier ;)
NB: il est quand même possible de forcer Eclipse/Pydev à utiliser un encodage particulier, et j'ose espérer que les autres IDE le permettent aussi.

Salut Tryph,

C'est super intéressant! J'ai testé et je suis bien en "ascii" sur le serveur comme le local. C'est donc pas le problème.

Cependant ton message ma donnée une idée. En local j'utilise le serveur de test de django "./manager.py runserver"
En production j'utilise nginx. J'ai donc démarrer le serveur de test django sur le serveur, et là surprise: sa marche.

J'en conclut que le problème ne vient non pas de django, mais de nginx!
Cela dit... je n'ai toujours pas de solution! :(

c'était bien tenté quand même ;)

sinon, tu peux peut être réussir à mieux cerner le problème en utilisant le 2e paramètre de la méthode "encode" et en lui assignant la valeur "replace". ça évitera de provoquer l'erreur tout en remplaceant les caractères problématiques par des "?"...

c'est pas une solution, mais ça peut aider à avancer...

EDIT: "backslashreplace" permet de remplacer les caractères problématiques par des séquences d'échappement, c'est peut être encore mieux.