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:
\n\r\r\nRessources: HexDump OnLine, AsciiTable, Special chars in python
Astuces:
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).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).L'encodage par défaut sous Windows en Europe occidentale depuis Windows 3.0 est windows-1252, compatible avec iso_8859-1 (latin-1).
C'est celui utilisé par cmd.exe.
Sous python, pour déclarer cet encodage (en emacs-style):
# -*- coding: windows-1252 -*-
L'encodage par défaut sur AIX 6.1.0.0 semble être utf-8.
Notepad++ possède un Menu > Edition > Paneau des caractères ASCII. Cela permet notamment d'insérer des caractères non imprimables (echap, CR, LF, etc) dans le document, puis de les copier-coller dans le programme de sn choix (au hasard : un émulateur de terminal ⇒ très pratique pour envoyer ^H à un programme genre telnet ^^)