drole de caracteres ?

> oui

Ça tombe je voulais mieux comprendre les charsets.

Le page est en ISO-8859-1,

Comment je fais pour savoir que cette page est en ISO-8859-1?
Je regarde le code source et je trouve:
http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1"><title>

C'est marrant dans le code source aussi y a des caracteres anormaux.
Passons ça me fait mal à la tête.

mais le serveur renvoie un header "Content-Type:
text/html; charset=UTF-8".

1/Comment je fais pour savoir cela ?
2/Le serveur a un rôle là dedans comment? pourquoi?

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 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...)
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

Y a pas quelqu'un qui pourrait nous expliquer comment cela
peut s'articuler.

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.



--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 'H EAD
/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 v alidateur
> 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 l e 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

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 'H EAD
/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 v alidateur
> 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 l e 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

On Sun, Sep 25, 2005 at 09:57:06AM +0200, Sylvain Sauvage wrote :

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).

Pas dac'. Ce sont des formidables machines à éradiquer les langues non
accentuées, y compris celle que l'on emploie sur cette liste. Tout est
plus simple quand on parle anglais. Essaye d'envoyer un mail sur le
téléphone portable d'un japonais, chinois ou coréen. La réponse c'est
vite "merci, mais pas d'accents s'il te plait" :(

Du coup, c'est l'informatique qui introduit des barrières : l'anglais
est simple et le français compliqué, alors qu'il faudrait écrire
"favorisé" et "pénalisé".

C'est l'uniformisation informatique qui est sensée nous sauver de
l'uniformisation linguistique.

--
Charles


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Sep 25, 2005 at 09:57:06AM +0200, Sylvain Sauvage wrote :

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).

Pas dac'. Ce sont des formidables machines à éradiquer les langues non
accentuées, y compris celle que l'on emploie sur cette liste. Tout est
plus simple quand on parle anglais. Essaye d'envoyer un mail sur le
téléphone portable d'un japonais, chinois ou coréen. La réponse c'est
vite "merci, mais pas d'accents s'il te plait" :(

Du coup, c'est l'informatique qui introduit des barrières : l'anglais
est simple et le français compliqué, alors qu'il faudrait écrire
"favorisé" et "pénalisé".

C'est l'uniformisation informatique qui est sensée nous sauver de
l'uniformisation linguistique.

--
Charles


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[ Grr. Sylpheed vient de me perdre mon courriel. Je dois le recommencer.
Tant pis (mieux ?), il sera plus court. ]

Dimanche 25 septembre 2005, 17:39:23 CEST, Charles Plessy a écrit :

On Sun, Sep 25, 2005 at 09:57:06AM +0200, Sylvain Sauvage wrote :

> 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).

Pas dac'. Ce sont des formidables machines à éradiquer les langues non
accentuées, y compris celle que l'on emploie sur cette liste.

L'EUC-JP permet les caractères romains accentués. Évidemment, JIS et
Shift_JIS non, mais comme c'est EUC-JP le plus courant sur les unix ;oP

Tout est
plus simple quand on parle anglais. Essaye d'envoyer un mail sur le
téléphone portable d'un japonais, chinois ou coréen. La réponse c 'est
vite "merci, mais pas d'accents s'il te plait" :(

Du coup, c'est l'informatique qui introduit des barrières : l'anglais
est simple et le français compliqué, alors qu'il faudrait écrire
"favorisé" et "pénalisé".

C'est l'uniformisation informatique qui est sensée nous sauver de
l'uniformisation linguistique.

Si tu remplaces « uniformisation informatique » par « standard
international (et réfléchi) des formats de données », je signe ;o)

Les encodages asiatiques sont intéressants parce qu'ils ont de nombreux
utilisateurs potentiels, qu'ils sont déjà majoritairement utilisés et que
l'on ne peut pas réduire leurs glyphes à des « modification mineures des
caractères latins » (comme « on » pourrait être tenté de le fai re pour
nos accents). Ce sont des arguments pour éviter les âneries comme l'ASC II
et pour réfléchir un peu avant de décider pour tout le monde et pour
l'avenir.

Unicode a été réfléchi. Y compris avec des spécialistes asiatiq ues, ce
qui invaliderait certaines objections. Mais le « c'est dû à l'histoir e de
la construction d'unicode » pour expliquer que l'on conserve des erreurs
(comme l'ordre des caractères thaïs p.ex.), me semble suspect :
l'informatique est très conservatrice de solution temporaires patchées et
repatchées pour éviter d'avoir à repenser le problème (ou à refai re le
vieux truc qui fait conserver la vieille solution) alors que ce serait
plus facile.

Le problème, c'est qu'utf-8, ce n'est pas unicode. Utiliser utf-8 ne va
pas forcément permettre d'écrire de droite à gauche p.ex.

Autre problème, c'est qu'utf-8 n'est pas seul. Il y a utf-16, utf-32,
utf-7, utf-ebdcdic, gb18030... Sans compter les petit-boutistes et les
gros-boutistes.
À la place de « merci, pas d'accent » tu auras « du gb18030 stp », ce
qui ne sera pas très facile à envoyer depuis ton mobile en utf-8.

(Remarque que je suis quand même passé à l'utf-8 récemment. Pour tester
et parce qu'il n'y pas mieux pour l'instant sous Debian.)

--
Sylvain Sauvage

On Sun, Sep 25, 2005 at 03:44:54PM +0200, Sylvain Sauvage wrote :

Autre problème, c'est qu'utf-8 n'est pas seul. Il y a utf-16, utf-32,
utf-7, utf-ebdcdic, gb18030... Sans compter les petit-boutistes et les
gros-boutistes.

Ainsi que les normalisations de formes C et D :((

À la place de « merci, pas d'accent » tu auras « du gb18030 stp », ce
qui ne sera pas très facile à envoyer depuis ton mobile en utf-8.

Bah, de toutes façons, y'a pas d'accents sur mon mobile. Va falloir que
je voie comment forcer le EUC-machinchose avec mutt, des fois que les
téléphones l'acceptent (je ne sais pas quel encodage ils utilisent).

--
Charles


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Sep 25, 2005 at 03:44:54PM +0200, Sylvain Sauvage wrote :

Autre problème, c'est qu'utf-8 n'est pas seul. Il y a utf-16, utf-32,
utf-7, utf-ebdcdic, gb18030... Sans compter les petit-boutistes et les
gros-boutistes.

Ainsi que les normalisations de formes C et D :((

À la place de « merci, pas d'accent » tu auras « du gb18030 stp », ce
qui ne sera pas très facile à envoyer depuis ton mobile en utf-8.

Bah, de toutes façons, y'a pas d'accents sur mon mobile. Va falloir que
je voie comment forcer le EUC-machinchose avec mutt, des fois que les
téléphones l'acceptent (je ne sais pas quel encodage ils utilisent).

--
Charles


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 2005-09-24 16:39:58 +0200, Florent Bayle wrote:

Le page est en ISO-8859-1, mais le serveur renvoie un header "Content-Type:
text/html; charset=UTF-8". Il y a bien dans la page une balise "<meta
http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">", mais
elle semble ignorée par le navigateur.

Oui, ce sont les en-têtes HTTP qui ont la priorité (c'est dans les
spec).

--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org