codage des caractères Windows vs Linux

Antoun wrote in message <42d013f2$0$7835$626a14ce@news.free.fr>:

Quelqu'un peut-il m'expliquer cette galère ?

<URL: http://www.tuteurs.ens.fr/theorie/encodages.html >

Le plus fiable avec perl, à mon avis, dès qu'on manipule des chaênes avec
des accents, c'est d'en faire des chaînes Unicode. Ici, ça se fait ainsi :

use Encode;
$page_web = get ...;
$page_web = decode($encodage_page_web, $page_web);

$encodage_page_web se trouve soit en fixant une valeur une fois pour toutes
si c'est un site bien connu, soit en regardant dans les entêtes HTTP ou le
meta http-equiv, le champ Content-Type.

En sortie, on règle :

binmode FILEHANDLE, ":encoding($encodage_fichier)";
print FILEHANDLE $page_web;


Après, quant à savoir quels sont les encodages utilisés par les outils
windows, je n'en ai aucune idée.

Salut,

On Sat, 09 Jul 2005 20:14:05 +0200, Antoun <antoun@free.fr> wrote:

Je suis sous Windows XP avec ActivePerl et Open Perl IDE. Je récupère
avec LWP::Simple des pages HTML contenant des caractères accentués, qui
sont écrits tels quels et non codés en &eacute; comme il conviendrait.

C'est loin d'être obligatoire, à partir du moment où le charset est bien
défini (voir le header HTTP Content-Type, qui devrait être de la forme
text/html; charset=xxx), permettant de savoir à quoi correspondent
effectivement les octets rencontrés.

Je mets le contenu de chaque page dans une variable, que je print
ensuite à la fois dans l'écran de contrôle d'Open Perl IDE et dans un
fichier texte. Dans mon fichier texte ouvert avec Notepad, les accents
apparaissent correctement ; si j'ouvre le même fichier avec Note Tab
Light, les é (e accent aigu) apparaissent comme é (A majuscule tilde et
signe copyright) ; même chose dans l'écran de Perl IDE.

Ca c'est de l'encodage UTF-8 qui n'est pas interprété comme tel.

Jusque-là, je me dis "c'est pas grave, tant que c'est OK dans Notepad ça
va". Mais maintenant j'ai besoin d'ôter les tirets conditionnels
(caractère 173), je fais donc passer un s/xAD//g

Résultat, Notepad se comporte maintenant comme les autres, avec des é
partout...

Quelqu'un peut-il m'expliquer cette galère ?

Dès lors qu'on sort du pur US-ASCII (i.e. les caractères dont la
représentation est un octet <7), il y a toutes sortes de
représentations différentes (les encodages ou charsets), tout le monde
n'ayant pas décidé d'attribuer les mêmes caractères aux différents codes
(de 128 à 255 dans un jeu de caractères 8 bits), ne serait-ce que parce
qu'il y a plus de caractères à faire rentrer qu'il n'y a de places. On
trouve ainsi beaucoup de jeux de caractères sur 8 bits, le plus courant
étant ISO 8859-1 (aka ISO Latin 1), mais il y en a pas mal d'autres.

Comme tout ne rentrait pas, on a ensuite évolué vers un codage à 16 bits
(UCS-2) voire 32 bits (UCS-4). Mais ça pose toutes sortes de problèmes de
compatibilité, et la grande tendance de nos jours c'est UTF-8, qui encode
chaque caractère (ou plutôt son code à 32 bits) sur un nombre variable
d'octets, mais avec la garantie que tous les caractères <= 127 sont codés
tels quels et que le codage d'un caractère >8 ne comprend jamais
d'octet <7.

http://www.faqs.org/rfcs/rfc3629.html

Le problème, c'est maintenant que quand on manipule des caractères, il
faut savoir dans quel encodage ils sont et faire les conversions
appropriées si nécessaire. Le traitement de tout ça varie beaucoup d'une
version à l'autre de perl, perl avant la 5.6 ne manipulant que des octets,
perl 5.6 ayant un mélange bizarre d'UTF-8 et d'octets, et perl 5.8 étant
nettement mieux, mais pas au point de pouvoir deviner tout seul (ce n'est
presque jamais possible) l'encodage de ce qu'on lui donne en pâture. Il
faut donc l'aider un peu, et lire perldoc Encode, l'objectif étant au
final de traiter tout en interne comme de l'UTF-8, quite à convertir de
part et d'autre en fonction des besoins.

Jacques.

super, mes pages étaient en utf8 et je les recode en Latin-1, ça marche
parfaitement.

Merci beaucoup !

Antoun