Enfin d’une façon générale on se base surtout sur la réponse serveur pas le méta html ….

dans le cas présent : Content-Type: text/html; charset=utf-8

Dans le cas présent l’utf-8 n’est pas un hazard et il est bien précisé par le serveur en réponse… D’ou d’ailleurs le fait que le navigateur sache l’afficher…

Apres que “requests” decode pas directement tout seul …. ça je conseillerais une pull request dessus :)

Encore une petite coquille :

les gens se sont dit qu’utiliser base64 était déjà trop fait par tout le monde est qu’on allait pas se priver de cette occasion

En fait, le serveur http a un encoding par défaut, par exemple pour apache 2.4 dans httpd.conf c’est la directive AddDefaultCharset utf-8

Il y a également l’encoding de l’application qui est fixé par

Par conséquent, si l’application ne fixe aucun encoding, c’est l’encoding du serveur http qui est utilisé, donc forcément, si les encodings diffèrent, on se retrouve avec des contradictions.

C’est pour cela que l’encoding par défaut du serveur http doit toujours être le même que celui de l’application.

Dans le cas particulier du site espagnol, l’administrateur système a bien fait son boulot en fixant le utf-8, en revanche, les dèvs ont fait un boulot de sagouin en travaillent avec du ISO-8859-1. D’ailleurs, les dèvs doivent avoir des problèmes avec mysql qui doit être également en utf-8.

Après, dans la réalité, c’est autre chose … Le problème peut concerner l’UTF-7 qui reste difficile à gérer mais le côté européen n’est pas en reste en considérant de facto que l’ISO-8859 est l’encodage par défaut alors que la spécification ne le dit pas – pas mal d’emails français font cette erreur (et des emails venant de grosses entreprises).

Heureusement, les mecs de la spécification ont décidé une bonne fois pour toute de considérer l’UTF-8 par défaut désormais avec la RFC 6532 (cette dernière ayant été en partie produite, bizarrement, par des chinois). Pour le coup, il est vrai que l’email est un véritable bordel où l’on peut facilement compter une dizaine de RFC à implémenter pour gérer le gros des emails (et on peut les blâmer de n’avoir jamais imposer une homogénéisation – mais intervient la notion de legacy que Python a d’ailleurs omis lors de son passage à sa version 3) mais le problème concerne surtout les générateurs des emails (automatique ou humain ou les deux – dans le sens d’une automatisation produite par un humain) et le gagnant dans l’histoire est bien entendu Outlook (Microsoft n’a pas qu’exceller dans le domaine des standards avec IE, hein …).

Bref, c’est un gros bordel et ça le restera un bon bout de temps malheureusement car les logiciels essayant de traiter les emails sont toujours face à l’email fatidique (issu d’un mélange de RFC et de règles tacites que les reptiliens-développeurs des MUAs s’échangent dans le plus grand des secrets) qui ne respecte pas les standars mais qu’il faut traiter – intervient alors le patch-monkey, le cas particulier, le if de trop …

Voilà un petit complément d’information pour vous convaincre de ne pas traiter des emails.

Par contre j’ai été désolé d’apprendre que la “solid dick” d’iron man est fausse en fait…

Pyhton n’est pas parfait pour autant. => Python