Le codage est caractères est un sujet souvent prise de têtes pour les informaticiens hors hardware. A un certain moment, l'ordinateur parlait uniquement anglais et donc le codage ne maitrisait que les caractères de l'alphabet anglais plus d'autres trucs genre “{[;:%$¤”'#~\'. Le codage utilisé était alors montagnard: ASCII. Et puis un jour, d'autres gens ont fait leurs propres codages pour pouvoir lire/écrire dans leurs langues.

Puis, enfin, des gens se sont dit: “et si on faisait un système universel pour gérer ça?” C'est à ce moment qu'est né l'unicode.

Mais même avec l'unicode, il subsiste des différences. Comme par exemple le retour à la ligne dans les fichiers texte.

Sous:

• Unix: caractère LineFeed(LF), hex0A, \n
• Mac: caractère CarriageReturn(CR), hex0D, \r
• DOS / Windows: CR+LF, hex0D0A, \r\n

Ressources: HexDump OnLine, AsciiTable, Special chars in python

Astuces:

• La méthode open de python n'est pas sensible à la convention utilisée. Ses méthodes read fournissent insensiblement \n tandis que sa méthode write écrit avec la convention du système hôte (d'après ce que j'ai compris).
• Lors de certaines manips (genre une vue Django qui sert un fichier CSV, on ouvre le fichier cible avec open et on refile ce fichier dans une HttpResponse. Ce faisant, python envoie un fichier avec des \n seulement. Pour éviter ce problème: ouvrir le fichier en mode binaire ('rb') (l'ouvrir en mode texte, le modifier, le fermer et le rouvrir en mode binaire s'il le faut).