Re: drole de caracteres ?
Samedi 24 septembre 2005, 23:26:48 CEST, Debian User a écrit :
>[...]
> C'est marrant dans le code source aussi y a des caracteres anormaux.
Normal, le décodage par défaut du code source pour son affichage en tant
que code source dépend aussi du navigateur : il ne prend pas forcément en
compte le charset passé dans le Content-Type donné par le serveur
(peut-être parce qu'il peut s'agir d'un fichier local ?). Celui du meta
n'est pas parsé non plus (il pourrait...).
> > mais le serveur renvoie un header "Content-Type:
> > text/html; charset=UTF-8".
>
> 1/Comment je fais pour savoir cela ?
Il faut vérifier les en-têtes envoyés par le serveur.
Une des façons que je préfère : 'telnet www.trucmuche.net 80' puis 'HEAD
/machin/toto/bidule.html HTTP/1.0' (et deux retours chariot).
Tu peux aussi avoir des infos par le navigateur (p.ex. clic-droit
« Informations sur la page » dans Firefox).
> 2/Le serveur a un rôle là dedans comment? pourquoi?
Le serveur envoie un fichier. Un fichier est juste une suite d'octets.
Il faut que le client sache comment interpréter ces octets (image,
texte, archive... ?).
Pour cela, le fichier est associé à un type mime (p.ex. text/html).
Les types mime text/* ne sont pas forcément suffisants pour savoir avec
quels charset et encodage interpréter le fichier.
Donc, certains text/*, comme le text/html, prévoient de définir le
charset dans leur corps (balise meta).
Le serveur ne peut pas vérifier que les informations sont dans le corps,
alors il donne un charset par défaut (« parfois » parce que ce n'est pas
obligatoire).
> > Il y a bien dans la page une balise "<meta
> > http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">",
>
> Je l'ai trouvé (affichage --> code source)
> > mais
> > elle semble ignorée par le navigateur.
> Oui c'est pour cela que l'on des caracteres bizarres
> > Pour savoir si le navigateur a raison ou pas, j'ai passé la page au validateur
> > W3C (http://validator.w3.org/), qui lui aussi détecte de l'UTF8.
> ?
Le validateur voit la balise meta et s'arrête là.
L'affichage dans le navigateur dépend aussi de sa configuration et de
son environnement (on peut très bien le forcer à afficher en utf-8 un
texte en EUC-JIS (japonais) et on y voit plus rien).
> > Le problème
> > semble donc venir du site/de la page.
> Bon.
>
> > Avec firefox tu peux forcer le charset à utiliser pour une page par le menu
> > Affichage > Encodage des caractères > Occidental (ISO-8859-1).
>
> Oui ça règle le probleme. Effectivement
>
> Mais j'avoue que ça ne m'aide pas à comprendre.
>
> Les élements qui entre en compte sont si j'ai bien compris:
>
> 1/ l'éditeur de la page web (emacs, screem, bluefish; ayama...)
Pas vraiment : l'éditeur fait ce que tu lui dis. Si ton environnement
est en utf-8, Emacs (p.ex.) enregistrera en utf-8 par défaut, mais tu
peux le forcer à enregistrer en latin-15 (C-x-Ret-f).
> 2/ le code de la page web (p.e. http-equiv="Content-Type"
> content="text/html; charset=ISO-8859-1">)
> 3/ le serveur de la page web (ça je savais pas)
> 4/ le navigateur qui va lire la page web
>
> C'est ça
Oui.
> Y a pas quelqu'un qui pourrait nous expliquer comment cela
> peut s'articuler.
Comme tu as vu, c'est un beau merdier ;o)
> J'ai lu :
> http://openweb.eu.org/articles/jeux_caracteres/
>
> Mais ça juste à savoir ce que sont ces jeux de caractères mais pas
> comment ils sont définis et interprétés.
Définition : par celui qui veut bien les définir, sinon par une norme
(voir ISO, ECMA, ANSI, AFNOR, DIN, JAS...)
Interprétation : un code (des bits) correspond à un ou plusieurs
glyphes (dessins). La correspondance est dans la déf.
Certains pensent que ce bazar est en train de s'arranger avec
l'unicode (on pourrait tout encoder en unicode : plus de 4 milliards
de caractères). Mais ce n'est pas si simple : il y a l'utf-8 (le plus
courant, minimum d'un octet par caractère), l'utf-16 (minimum deux
octets), l'utf-32 (tout sur quatre octets).
Le choix actuel s'est porté sur l'utf-8 pour deux raisons :
- les premières valeurs sont celles de l'ascii (dont rien à changer pour
tous les textes n'utilisant que l'ascii) ;
- l'octet 0 n'entre pas dans le codage, ou disons que c'est le caractère
NUL, le caractère « pas un caractère », il peut encore servir pour
marquer la fin des chaînes de caractères.
(Le conservatisme est très fort en informatique...)
Au contraire, l'utf-16 est incompatible avec les « legacy
applications » (traduction : vieux trucs qui empêchent le progrès) :
- incompatible avec l'ascii : il y a toujours un octet 0 devant ;
- l'octet 0 ne peut plus servir de fin de chaîne.
Personnellement, je pense qu'on est pas sorti de l'auberge :
- l'utf-8 partout, ça vient mais c'est pas encore là (transition
difficile) ;
- l'ascii était sur 7 bits parce que les normateurs avaient l'esprit
étroit :
<<
This coded character set is to facilitate the general interchange of
information among information processing systems, communication systems,
and associated equipment. ... An 8-bit set was considered but the need
for more than 128 codes in general applications was not yet evident.
ASA subcommittee X3.2, American Standard Code for Information
Interchange (ASCII) -- Communications of the ACM
>>
- l'ascii étendu s'est limité au 8 bits (l'élargissement de la vision
des normateurs était limité) ;
- l'utf-8 est extrêmement ennuyeux pour ceux qui ont déjà, et depuis
longtemps, un encodage sur 16 bits (chinois, japonais, etc.) : en plus
de l'incompatibilité, un texte en 8 bits peut être plus long qu'en
16 bits (c'est le cas pour le japonais : l'utf-8 est plus long que
l'EUC d'environ 5 % à 10 % ; le français prend 2-3 % en passant du
latin-15 à l'utf-8).
Bon, l'utf-8 va surtout permettre aux occidentaux de partager les mêmes
charset/encodage sans trop bousculer ce qu'il y avait avant. Cela leur
permet aussi de faire du multilinguisme (plusieurs langues dans le même
document). Mais je pense que EUC, Big5, KOI8-R ou autres ont encore de
beaux jours devant eux (et tant mieux : l'_uni_formité, c'est triste).
--
Sylvain Sauvage
Reply to: