L'erreur bête et très frustrante du jour vient d'un petit formulaire qui permet de téléverser un fichier quelconque sur le serveur. Vous me direz, c'est la base du formulaire web avec des fichiers, et il ne devrait pas y avoir de soucis particuliers... sauf lorsque lesdits fichiers ont des accents dans le nom de fichier, et qu'une erreur aussi frustrante que difficile à analyser débarque avec ses gros sabots.

Alors, premier réflexe : chercher sur le net, entre Stack Overflow et le tracker de bug de django. Vous pourrez tomber sur ce genre de discussions : UnicodeEncodeError: 'ascii' codec can't encode character.

Cela donne déjà un premier aperçu d'où vient le problème, à savoir, une configuration de locale sur l'environnement serveur. Pour vous en dire plus, voici les symptômes auxquels j'ai été moi-même confrontés :

• le formulaire fonctionne avec le serveur de dev de django
• il ne fonctionne plus derrière apache/nginx/votre serveur web favori
• vous utilisez un serveur wsgi (du genre gunicorn) ou bien le mod_wsgi d'apache
• seul les fichiers avec des caractères accentués (ou "spéciaux") font lever l'exception

La première "solution" qui est proposée, c'est que l'environnement serveur soit correctement configuré, avec, entre autre, une modification du fichier /etc/apache2/envvars. Personnellement, j'ai essayé, mais cela ne fonctionne pas.

Bref, que faire dans ces cas là ?

Comprendre et analyser le problème

Je ne suis pas un expert, mais voici ma démarche pour comprendre puis résoudre ce problème.

Tout d'abords, j'ai regardé la locale de la machine à l'aide de la commande locale, et j'ai obtenu ceci :

LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

Ensuite, j'ai lancé l'interpréteur python, pour en savoir plus :

>>> import locale
>>> locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
('fr_FR', 'UTF-8')

Bon, je remercie ici mYk et linova sur IRC de m'avoir fait chercher dans ces directions, et de m'avoir proposé ensuite de vérifier la valeur de ces informations là dans le contexte de mon application django. J'ai donc affiché ces valeurs dans un template et voici les valeurs que j'ai obtenues avec le serveur de dev de django :

loc: (None, None)
loc_def: ('fr_FR', 'UTF-8')

Puis la même chose, mais avec gunicorn :

loc: (None, None)
loc_def: (None, None)

À partir de là, j'ai pu enfin comprendre le problème, et comment le résoudre. Merci à linova pour l'idée sur IRC.

Merci encore une fois au chan #djangocong sur freenode !

Résoudre le problème

J'utilise runnit pour gérer mes différentes applications servies par gunicorn, et j'ai donc des petits scripts (comme pour init.d), dans lesquels j'ai ajouté ceci :

export LC_ALL=fr_FR.UTF8

Et c'est tout. Oui, tout à fait, c'était juste ça : la locale n'était pas définie dans ce contexte très particulier, et pas dans un autre, ce qui explique tout mon problème avec ces foutus fichiers. J'ai redémarré les différentes applications, et je n'ai plus constaté de problèmes.

Alors, si vous aussi vous avez ce problème, je vous conseille de suivre la même démarche que moi : vérifiez vos locales, vérifiez vos locales via l'interpréteur python d'une part, puis dans le contexte de votre application plus spécifiquement.

Enfin, allez voir du côté du script de votre serveur, et voyez s'il n'y a pas quelque chose à faire avec.

Il est parfois difficile de dire d'un code qu'il est bon ou mauvais, qu'il est moche ou élégant. Parfois, les deux se confondent dans un doute profond sur la nature d'une idée, et sur son implémentation.

Beautiful is better than ugly.

Heureusement, parfois, il y a du code php/java/python/javascript/ruby/perl/autre bien sale et c'est très facile à repérer.

Notez l'effort pour ne pas troller toujours sur le même langage.

Ayant acquis récemment une nouvelle carte graphique ATI HD 6850 chez LDLC, je me suis empressé de la mettre dans ma belle unité centrale (dont il faudra sans doute que je vous parle ici un jour, dans un long article vous expliquant pourquoi c'est la plus belle #vantardise). J'ai, bien entendu, désinstallé les drivers sur Windows, et comme j'avais déjà une ATI, je n'ai rien eu à faire pour mon Ubuntu (j'ai vérifié, et il n'y a aucune contre-indication - j'ai peut-être raté un truc, si oui, dites le moi dans les commentaires !).

J'installe la bête, et je redémarre. Rien à dire sur Windows : ça marche tout de suite, j'installe le driver, et à moi les jeux avec des graphismes de folie. Super, j'ai pas le temps là. Passons à Ubuntu : je redémarre (vive les dual-boot), je passe l'écran du Grub, et... pouf, plus rien, l'écran noir !

N'ayant pas la patience de vérifier si, au bout de 5min, la machine fonctionne quand même, j'éteins, je remets l'ancienne carte, et heureusement ça fonctionne toujours. Je vérifie ensuite en utilisant un Live-CD : j'ai la même chose, c'est à dire l'écran noir à l'écran de chargement. Il semble bien qu'il y ait un problème entre le moment du boot et le moment où le bureau s'affiche (à ce moment là, je ne sais pas encore que le bureau est censé s'afficher quand même après un certain temps).

Je cherche sur le net, sans trouver grand chose. Et puis je me rappelle d'un truc, et je trouve ceci : ATI et usplash ; ainsi que ceci : Problèmes Usplash.

Ces deux articles présentent des problèmes qui correspondent bien à mes problèmes, et je décide, plutôt que de tenter d'installer / désinstaller des trucs, de simplement suivre la méthode évoquée dans le second article, à savoir, créer et écrire ceci dans le fichier /etc/usplash.conf :

xres=1280
yres=1024

Puis de lancer la commande suivante :

sudo update-initramfs -u

Et bien vous savez quoi ? Ça a marché ! Mon écran de démarrage est ré-apparu, Ubuntu se lance désormais comme il faut.

Donc, si cela vous arrive, ne paniquez pas : il y a probablement une solution, et le problème peut être quelque chose de particulièrement... inattendu ! J'ai pensé à regardé du côté de usplash car j'avais déjà entendu parlé de problèmes à peu près similaire au démarrage, mais c'était il y a quelques années maintenant...

... Comme quoi, les cartes ATI, c'est pas encore trop ça avec Ubuntu. Mais bon, là, ça marche bien, et je n'ai pas à me plaindre !

Enfin, si : j'ai pas assez de temps pour jouer et continuer tous ces petits projets que j'ai lancé à droite et à gauche. Mais ça, c'est un tout autre problème !