On Thu, Dec 16, 2004 at 04:24:32PM +0100, Cyril Banderier wrote:
ok, c'est indeed Fayçal qui a initialement lancé un mail en UTF-8 = unicode et sujeeevan a repiqué son codage avec son reply. Je recois nickel les Content-Type: text/plain; charset=ISO-8859-1; format=flowed mais pas l'unicode.
Je vais réexpliquer: ton mailer (Mail) n'a pas l'air de connaître quoi que ce soit au codage de caractère. Rien, nada. Il affiche des octets, et si tu as de la chance, tu es dans le même codage qu'à l'autre bout. Sinon, tu es dans la merde. Tu dois mal recevoir les accents envoyés depuis un macintosh aussi. D'ailleurs, ton mailer ne précise rien, ce qui va dans mon sens.
Font iech à avoir fait de l'ASCII 128 anglophone, ces pignoufs d'ancetres !
Ça ne change pas grand chose, le 128/256/65536: ce sont des codages différents. La plupart des codages font en sorte qu'un flot ASCII (octets uniquement entre 32 et 127) s'affichent comme le flot ASCII correspondant. Ce n'est pas vrai du codage UCS-2 ou UCS-4, par exemple. Tout système moderne et bien pensé sait quels sont les caractères qu'il a le droit d'afficher (souvent appelée locale, plus précisément la partie LC_CTYPE de la locale) et le codage à utiliser pour les afficher. Lorsqu'il tombe sur un codage qu'il connaît, il fait du transcodage autant que faire se peut, remplaçant les caractères inaffichables par des ?. Il n'y a pas de caractères inconnus. Ainsi, mutt m'affiche un unique ? par lettre russe ou idéogramme japonais qu'on lui demande d'afficher dans mes terminaux non-UTF8. Parfois, au lieu d'un ?, la séquence d'octets correspondante est affiché. C'est mal. Et c'est ce dont tu as souffert. L'Unicode est un de ces codages, qui a la propriété de (à peu près) posséder des injections de tous les codages dans lui-même. Ainsi, utiliser un terminal iso-8859-15 pour lire du texte iso-8859-1 n'est pas trop problématique. Seuls les œ posent problème (ainsi qu'une poignée d'autres, comme le Ÿ). Utiliser un terminal utf-8 avec un programme bien fait de pose jamais de problèmes. Avec un programme mal fait, le terminal recevra des séquences incorrectes (toutes les chaînes ne sont pas codantes en UTF-8). Regarder de l'UTF-8 avec un terminal iso-8859-1 donne les résultats que l'on sait (é et autres). Avec des programmes bien faits, surgissent parfois des problèmes. Par exemple, des courriers envoyé en iso-latin-1 mais non marqués comme tels sont considérés comme étant en US-ASCII, et les séquences non codantes (par exemple les caractères accentués) sont envoyés sur ?. Ceci dit, c'est un problème humain plus qu'autre chose. Tout logiciel qui n'a pas un bon comportement de substitution devrait être effacé de la mémoire collective. Les autres ont tout à fait leur place, même s'ils ne connaissent qu'un seul code (dommage, quand on sait que la libc fournit énormément d'outils déjà prêts).