Noyeux Joël à tous ...

Antoine Leca

26/12/2005 à 11:50

In news:20051225115934$, Vincent Lefevre va escriure:

Dans l'article <43ae6bd3$0$11351$,
Richard Delorme écrit:

D'après cet extrait, on peut mettre les caractères que l'on veut dans
les commentaires.

À condition qu'ils fassent partie du jeu de caractères

Oui.

ou qu'ils soient traduits sans erreur.

?

Soit ce sont des caractères, et ils font donc partie d'un jeu, et
l'implémentation est forcée de savoir les traduire (quitte à les refuser
ensuite, mais s'ils sont dans un commentaire on ne voit pas comment les
refuser, les commentaires disparaissant en phase 3, bien avant que les
règles d'analyse rentrent en ligne de compte).

Soit ce n'en est pas (cf. supra), et je ne vois pas comment ils peuvent
entrer.

La seule chose qui peut poser problème (dans un commentaire), c'est si
certains caractères (étendus au sens C99) changent l'état de décodage (un
peu comme les séquences =?...?Q du sujet des messages de ce fil).
Ce n'est pas une erreur de traduction d'un caractère en soi (ÀMHA), mais le
compilateur ne va pas trouver la fin du commentaire, donc il sera impossible
pour le compilateur de traduire quoi que ce soit.

Évidemment, il n'y a aucune différence ici du fait de la présence de
caractères accentués : la seule contrainte, c'est de représenter les
caractères '*' puis '/' qui terminent le commentaire avec les caractères du
jeu de base, donc dans l'état d'encodage « initial », _pas_ avec des
caractères équivalents dans un état d'encodage différent (pour en revenir à
mon analogie avec QP, le ?= qui termine la séquence doit se trouver au plus
tard avant le */). On est au niveau de la manière d'encoder le source, qui
est évidemment fonction des caractéristiques de l'implémentation (phase 1,
correspondance entre les caractères physiques et les caractères du jeu de
caractères source).

Et on a toujours la possibilité de ré-écrire le source de Pierre

* Adresse des voeux de No??/00ebl ??/00e0 la cit??/00e9 d'??/00C9vry

(ou mieux
* Adresse des v??/0153ux de No??/00ebl ??/00e0 la cit??/00e9 d'??/00C9vry
)

pour s'adapter aux contraintes les plus fortes sur cette 1re phase.

Antoine

In news:20051225115934$27db@ay.vinc17.org, Vincent Lefevre va escriure:

Dans l'article <43ae6bd3$0$11351$7a628cd7@news.club-internet.fr>,
Richard Delorme <abulmo@nospam.fr> écrit:

D'après cet extrait, on peut mettre les caractères que l'on veut dans
les commentaires.

À condition qu'ils fassent partie du jeu de caractères

Oui.

ou qu'ils soient traduits sans erreur.

?

Soit ce sont des caractères, et ils font donc partie d'un jeu, et
l'implémentation est forcée de savoir les traduire (quitte à les refuser
ensuite, mais s'ils sont dans un commentaire on ne voit pas comment les
refuser, les commentaires disparaissant en phase 3, bien avant que les
règles d'analyse rentrent en ligne de compte).

Soit ce n'en est pas (cf. supra), et je ne vois pas comment ils peuvent
entrer.

La seule chose qui peut poser problème (dans un commentaire), c'est si
certains caractères (étendus au sens C99) changent l'état de décodage (un
peu comme les séquences =?...?Q du sujet des messages de ce fil).
Ce n'est pas une erreur de traduction d'un caractère en soi (ÀMHA), mais le
compilateur ne va pas trouver la fin du commentaire, donc il sera impossible
pour le compilateur de traduire quoi que ce soit.

Évidemment, il n'y a aucune différence ici du fait de la présence de
caractères accentués : la seule contrainte, c'est de représenter les
caractères '*' puis '/' qui terminent le commentaire avec les caractères du
jeu de base, donc dans l'état d'encodage « initial », _pas_ avec des
caractères équivalents dans un état d'encodage différent (pour en revenir à
mon analogie avec QP, le ?= qui termine la séquence doit se trouver au plus
tard avant le */). On est au niveau de la manière d'encoder le source, qui
est évidemment fonction des caractéristiques de l'implémentation (phase 1,
correspondance entre les caractères physiques et les caractères du jeu de
caractères source).

Et on a toujours la possibilité de ré-écrire le source de Pierre

* Adresse des voeux de No??/00ebl ??/00e0 la cit??/00e9 d'??/00C9vry

(ou mieux
* Adresse des v??/0153ux de No??/00ebl ??/00e0 la cit??/00e9 d'??/00C9vry
)

pour s'adapter aux contraintes les plus fortes sur cette 1re phase.

Antoine

Vous avez filtré cet utilisateur ! Consultez son message

In news:20051225115934$, Vincent Lefevre va escriure:

Dans l'article <43ae6bd3$0$11351$,
Richard Delorme écrit:

D'après cet extrait, on peut mettre les caractères que l'on veut dans
les commentaires.

À condition qu'ils fassent partie du jeu de caractères

Oui.

ou qu'ils soient traduits sans erreur.

?

Soit ce sont des caractères, et ils font donc partie d'un jeu, et
l'implémentation est forcée de savoir les traduire (quitte à les refuser
ensuite, mais s'ils sont dans un commentaire on ne voit pas comment les
refuser, les commentaires disparaissant en phase 3, bien avant que les
règles d'analyse rentrent en ligne de compte).

Soit ce n'en est pas (cf. supra), et je ne vois pas comment ils peuvent
entrer.

La seule chose qui peut poser problème (dans un commentaire), c'est si
certains caractères (étendus au sens C99) changent l'état de décodage (un
peu comme les séquences =?...?Q du sujet des messages de ce fil).
Ce n'est pas une erreur de traduction d'un caractère en soi (ÀMHA), mais le
compilateur ne va pas trouver la fin du commentaire, donc il sera impossible
pour le compilateur de traduire quoi que ce soit.

Évidemment, il n'y a aucune différence ici du fait de la présence de
caractères accentués : la seule contrainte, c'est de représenter les
caractères '*' puis '/' qui terminent le commentaire avec les caractères du
jeu de base, donc dans l'état d'encodage « initial », _pas_ avec des
caractères équivalents dans un état d'encodage différent (pour en revenir à
mon analogie avec QP, le ?= qui termine la séquence doit se trouver au plus
tard avant le */). On est au niveau de la manière d'encoder le source, qui
est évidemment fonction des caractéristiques de l'implémentation (phase 1,
correspondance entre les caractères physiques et les caractères du jeu de
caractères source).

Et on a toujours la possibilité de ré-écrire le source de Pierre

* Adresse des voeux de No??/00ebl ??/00e0 la cit??/00e9 d'??/00C9vry

(ou mieux
* Adresse des v??/0153ux de No??/00ebl ??/00e0 la cit??/00e9 d'??/00C9vry
)

pour s'adapter aux contraintes les plus fortes sur cette 1re phase.

Antoine

Pierre Maurette

26/12/2005 à 12:23

[...]

(ou mieux
* Adresse des v??/0153ux de No??/00ebl ??/00e0 la cit??/00e9 d'??/00C9vry
)
Bonjour Antoine,

Feliz Navidad y próspero año nuevo
(o: Bon Nadal i feliç any nou)

Pour "l'o dans l'e", je ne le respecte que pour ce qui est publié sur
papier. Et alors je fais confiance à Microsoft Word et aux gens de la
PAO. Sur usenet, ou les courriels, le risque de n'importe quoi chez le
lecteur ne vaut pas la différence d'aspect entre b½uf, v½u, ½uf et
boeuf, voeu, oeuf. Ceci s'applique également à l'IHM en programmation.
Pourtant, avec les correcteurs orthographiques même sommaires, il
serait facile de respecter cette étrangeté de notre langue.

--
Pierre Maurette

Pierre Maurette

26/12/2005 à 12:27

"Pierre Maurette" wrote in
news::

puts("Happy Christmas every body !");

Tu aurais certainement reçu meilleur accueil ici
Salut,

Je ne me plains absolument pas de l'accueil reçu par mon message, qui
par ailleurs ne méritait pas le hit-parade. L'accueil fut nominal, et
chacun a joué son rôle. Ce qui est un projet de vie parfaitement
défendable. Ne joue-je pas le mien ?
;-)

--
Pierre Maurette

TERENCE

26/12/2005 à 14:58

"Pierre Maurette" a écrit dans le message de news:

Je ne me plains absolument pas de l'accueil reçu par mon message, qui
par ailleurs ne méritait pas le hit-parade. L'accueil fut nominal, et
chacun a joué son rôle. Ce qui est un projet de vie parfaitement
défendable. Ne joue-je pas le mien ?
;-)

Oui ... ton "jeu" est sympathique et agréablement dynamisant.
Un seul reproche : il n'est pas partagé par tous :-)

Vincent Lefevre

26/12/2005 à 16:32

Dans l'article <doohth$e8e$,
Antoine Leca écrit:

In news:20051225115934$, Vincent Lefevre va escriure:
Dans l'article <43ae6bd3$0$11351$,
Richard Delorme écrit:

D'après cet extrait, on peut mettre les caractères que l'on veut dans
les commentaires.

À condition qu'ils fassent partie du jeu de caractères

Oui.

ou qu'ils soient traduits sans erreur.

?

Soit ce sont des caractères, et ils font donc partie d'un jeu, et
l'implémentation est forcée de savoir les traduire (quitte à les refuser
ensuite, mais s'ils sont dans un commentaire on ne voit pas comment les
refuser, les commentaires disparaissant en phase 3, bien avant que les
règles d'analyse rentrent en ligne de compte).

Il est bien connu que la traduction effectuée par l'implémentation
n'est pas forcément celle attendue par l'utilisateur. Par exemple,
on a un fichier dans le jeu de caractères ISO-8859-1, mais
l'implémentation est libre de l'interpréter comme elle le veut. Si
l'implémentation traduit les caractères accentués en « ? » (comme cela
se fait souvent dans d'autres contextes), pas de problème ici. Mais si
par exemple le « é » est traduit en « */ », cela provoquerait une
fermeture de commentaire non voulue.

C'est en ce sens que j'entendais "sans erreur".

--
Vincent Lefèvre - 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

Vincent Lefevre

26/12/2005 à 16:40

Dans l'article <43af2993$0$11356$,
Richard Delorme écrit:

Celui accepté par l'implémentation, suivant le contexte.

Alors le problème se pose pour tous les caractères. Si j'ai un code
source codé en EBDIC, je ne peux pas le compiler sur mon implémentation
qui n'accepte que de l'ASCII.

Oui, sauf qu'en pratique, l'utilisateur va faire une conversion
EBCDIC -> ASCII. En revanche, les problèmes d'encodage avec les
jeux de caractères basés sur l'ASCII sont très courants. Sur
les systèmes basés sur l'ASCII, seul l'ASCII est véritablement
portable.

Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une
implémentation peut très bien refuser tout caractère accentué.

Pas s'il est dans les commentaires.

Le problème est qu'on ne sait pas encore s'il est dans un commentaire
ou non. D'ailleurs même avec les fichiers ASCII, la reconnaissance
des commentaires n'est pas reproductible d'un compilateur à l'autre
(gcc vs le reste du monde).

--
Vincent Lefèvre - 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

loufoque

26/12/2005 à 17:11

Sur usenet, ou les courriels, le risque de n'importe quoi chez le
lecteur

Parce qu'il y a des clients qui sont incapable de lire l'entête
indiquant l'encodage des caractères ?

loufoque

26/12/2005 à 17:15

UCS-32, un jeu de caractère bien connu...

Je voulais dire UCS-4 alias UTF-32 (Unicode avec caractères de taille fixe)
Enfin je suppose que ça se devinait, du fait que je disais bien "32 bits".

Des nombreuses « plateformes » utilisant 32 bits pour un "byte"

Je n'ai jamais prétendu qu'elles étaient nombreuses.
De nos jours un byte qui ne vaut pas un octet c'est plutôt une aberration.

Antoine Leca

26/12/2005 à 17:22

In news:20051226152131$, Vincent Lefevre va escriure:

Il est bien connu que la traduction effectuée par l'implémentation
n'est pas forcément celle attendue par l'utilisateur.

Certes.
Surtout quand l'utilisateur attend la lune.

Par exemple, on a un fichier dans le jeu de caractères ISO-8859-1,
mais l'implémentation est libre de l'interpréter comme elle le veut.

Pas vraiment. L'implémentation (conforme) est contrainte par ses
spécifications (et donc sa documentation) ; et l'utilisateur aussi devrait
être soumis au respect de cette contrainte, même si dans la réalité c'est
beaucoup demandé, comme observé ci-dessus.

Si les spécifications disent que l'implémentation interprète le source avec
le jeu 8859-1, aucun souci à avoir, et impossible d'avoir quoi que ce soit
d'autre qu'un e accent aigu (au moins dans le jeu source).
Si elles disent que le source est interprété dans la mesure où il est
compatible ASCII, ou quelque chose d'approchant (c'est le cas général), pas
de souci non plus, la signification exacte du caractère sera perdue mais
c'est tout (au grand maximum on aura le cas é->? comme tu expliquais, et
encore, mais plus probablement on aura quelque chose comme é->¿, ou si tu
préfères é->uFFFD).
Si elles ne le disent pas, effectivement on va avoir un problème, exactement
comme dans le cas où on fournit un source Fortran à un compilateur C : si
cela fonctionne, cela tient du hasard.

Si l'implémentation traduit les caractères accentués en « ? »
(comme cela se fait souvent dans d'autres contextes), pas de
problème ici.

Je reconnais qu'elle _peut_ le faire, mais je n'ai jamais vu une
implémentation faire ce genre de traduction en phase 1. Tu as trop de
risques d'obtenir des programmes ingérables, dans ton exemple un programme
avec éé/ va être interprété comme contenant un /backslash/, alors que rien
ne prévient... (C'est le même problème avec les ¥ dans les programmes
échangés avec le Japon, et c'est une source de soucis sans fin.)

À ce propos, quand on considère les caractères, _traduction_ se rapporte le
plus souvent à la transformation en phase 6 du jeu de caractères source à
celui d'exécution (transformation qui peut effectivement faire une réduction
de tous les caractères « accentués » en ?, et oui là cela existe) ; mais ce
n'est pas le cas ici : soit ce sont toujours des caractères du jeu source
(pour une implémentation ; soit ce sont toujours des caractères du jeu
d'exécution, si l'on considère le cas d'un compilateur C écrit en langage C,
utilisant <stdio.h>.

Mais si par exemple le « é » est traduit en « */ », cela provoquerait
une fermeture de commentaire non voulue.

Là par contre, c'est proprement impossible, sauf à utiliser des
manipulations de jeux de caractères (genre passer par deux ou trois filtres
en pipeline avant d'alimenter le compilateur) spécifiques de la DS9k.
Tu transformes un codet (au sens des jeux de caractères, ici e-accent-aigu)
en séquence de deux codets (étoile puis barre) qui sont par ailleurs des
caractères de base... c'est possible (par exemple avec les jeux de
caractères genre ISO-2022-XX) mais pas courant (d'habitude on fait
l'inverse), et surtout une telle transformation se fera « dans un état
d'encodage différent de l'initial », pour reprendre ce que dit la norme ;
alors si après cette transformation, tu filtres les codets qui indiquent les
changements d'état, et que tu passes le résultat au compilo, effectivement
l'implémentation va interpréter cela comme une fin de commentaire... mais il
y a tellement de source conformes qui vont devenir inutilisables que cela
devient une implémentation sans intérêt.

C'est en ce sens que j'entendais "sans erreur".

Où est l'erreur ?

Antoine

In news:20051226152131$1736@ay.vinc17.org, Vincent Lefevre va escriure:

Il est bien connu que la traduction effectuée par l'implémentation
n'est pas forcément celle attendue par l'utilisateur.

Certes.
Surtout quand l'utilisateur attend la lune.

Par exemple, on a un fichier dans le jeu de caractères ISO-8859-1,
mais l'implémentation est libre de l'interpréter comme elle le veut.

Pas vraiment. L'implémentation (conforme) est contrainte par ses
spécifications (et donc sa documentation) ; et l'utilisateur aussi devrait
être soumis au respect de cette contrainte, même si dans la réalité c'est
beaucoup demandé, comme observé ci-dessus.

Si les spécifications disent que l'implémentation interprète le source avec
le jeu 8859-1, aucun souci à avoir, et impossible d'avoir quoi que ce soit
d'autre qu'un e accent aigu (au moins dans le jeu source).
Si elles disent que le source est interprété dans la mesure où il est
compatible ASCII, ou quelque chose d'approchant (c'est le cas général), pas
de souci non plus, la signification exacte du caractère sera perdue mais
c'est tout (au grand maximum on aura le cas é->? comme tu expliquais, et
encore, mais plus probablement on aura quelque chose comme é->¿, ou si tu
préfères é->uFFFD).
Si elles ne le disent pas, effectivement on va avoir un problème, exactement
comme dans le cas où on fournit un source Fortran à un compilateur C : si
cela fonctionne, cela tient du hasard.

Si l'implémentation traduit les caractères accentués en « ? »
(comme cela se fait souvent dans d'autres contextes), pas de
problème ici.

Je reconnais qu'elle _peut_ le faire, mais je n'ai jamais vu une
implémentation faire ce genre de traduction en phase 1. Tu as trop de
risques d'obtenir des programmes ingérables, dans ton exemple un programme
avec éé/ va être interprété comme contenant un /backslash/, alors que rien
ne prévient... (C'est le même problème avec les ¥ dans les programmes
échangés avec le Japon, et c'est une source de soucis sans fin.)

À ce propos, quand on considère les caractères, _traduction_ se rapporte le
plus souvent à la transformation en phase 6 du jeu de caractères source à
celui d'exécution (transformation qui peut effectivement faire une réduction
de tous les caractères « accentués » en ?, et oui là cela existe) ; mais ce
n'est pas le cas ici : soit ce sont toujours des caractères du jeu source
(pour une implémentation ; soit ce sont toujours des caractères du jeu
d'exécution, si l'on considère le cas d'un compilateur C écrit en langage C,
utilisant <stdio.h>.

Mais si par exemple le « é » est traduit en « */ », cela provoquerait
une fermeture de commentaire non voulue.

Là par contre, c'est proprement impossible, sauf à utiliser des
manipulations de jeux de caractères (genre passer par deux ou trois filtres
en pipeline avant d'alimenter le compilateur) spécifiques de la DS9k.
Tu transformes un codet (au sens des jeux de caractères, ici e-accent-aigu)
en séquence de deux codets (étoile puis barre) qui sont par ailleurs des
caractères de base... c'est possible (par exemple avec les jeux de
caractères genre ISO-2022-XX) mais pas courant (d'habitude on fait
l'inverse), et surtout une telle transformation se fera « dans un état
d'encodage différent de l'initial », pour reprendre ce que dit la norme ;
alors si après cette transformation, tu filtres les codets qui indiquent les
changements d'état, et que tu passes le résultat au compilo, effectivement
l'implémentation va interpréter cela comme une fin de commentaire... mais il
y a tellement de source conformes qui vont devenir inutilisables que cela
devient une implémentation sans intérêt.

C'est en ce sens que j'entendais "sans erreur".

Où est l'erreur ?

Antoine

Vous avez filtré cet utilisateur ! Consultez son message

In news:20051226152131$, Vincent Lefevre va escriure:

Il est bien connu que la traduction effectuée par l'implémentation
n'est pas forcément celle attendue par l'utilisateur.

Certes.
Surtout quand l'utilisateur attend la lune.

Par exemple, on a un fichier dans le jeu de caractères ISO-8859-1,
mais l'implémentation est libre de l'interpréter comme elle le veut.

Pas vraiment. L'implémentation (conforme) est contrainte par ses
spécifications (et donc sa documentation) ; et l'utilisateur aussi devrait
être soumis au respect de cette contrainte, même si dans la réalité c'est
beaucoup demandé, comme observé ci-dessus.

Si les spécifications disent que l'implémentation interprète le source avec
le jeu 8859-1, aucun souci à avoir, et impossible d'avoir quoi que ce soit
d'autre qu'un e accent aigu (au moins dans le jeu source).
Si elles disent que le source est interprété dans la mesure où il est
compatible ASCII, ou quelque chose d'approchant (c'est le cas général), pas
de souci non plus, la signification exacte du caractère sera perdue mais
c'est tout (au grand maximum on aura le cas é->? comme tu expliquais, et
encore, mais plus probablement on aura quelque chose comme é->¿, ou si tu
préfères é->uFFFD).
Si elles ne le disent pas, effectivement on va avoir un problème, exactement
comme dans le cas où on fournit un source Fortran à un compilateur C : si
cela fonctionne, cela tient du hasard.

Si l'implémentation traduit les caractères accentués en « ? »
(comme cela se fait souvent dans d'autres contextes), pas de
problème ici.

Je reconnais qu'elle _peut_ le faire, mais je n'ai jamais vu une
implémentation faire ce genre de traduction en phase 1. Tu as trop de
risques d'obtenir des programmes ingérables, dans ton exemple un programme
avec éé/ va être interprété comme contenant un /backslash/, alors que rien
ne prévient... (C'est le même problème avec les ¥ dans les programmes
échangés avec le Japon, et c'est une source de soucis sans fin.)

À ce propos, quand on considère les caractères, _traduction_ se rapporte le
plus souvent à la transformation en phase 6 du jeu de caractères source à
celui d'exécution (transformation qui peut effectivement faire une réduction
de tous les caractères « accentués » en ?, et oui là cela existe) ; mais ce
n'est pas le cas ici : soit ce sont toujours des caractères du jeu source
(pour une implémentation ; soit ce sont toujours des caractères du jeu
d'exécution, si l'on considère le cas d'un compilateur C écrit en langage C,
utilisant <stdio.h>.

Mais si par exemple le « é » est traduit en « */ », cela provoquerait
une fermeture de commentaire non voulue.

Là par contre, c'est proprement impossible, sauf à utiliser des
manipulations de jeux de caractères (genre passer par deux ou trois filtres
en pipeline avant d'alimenter le compilateur) spécifiques de la DS9k.
Tu transformes un codet (au sens des jeux de caractères, ici e-accent-aigu)
en séquence de deux codets (étoile puis barre) qui sont par ailleurs des
caractères de base... c'est possible (par exemple avec les jeux de
caractères genre ISO-2022-XX) mais pas courant (d'habitude on fait
l'inverse), et surtout une telle transformation se fera « dans un état
d'encodage différent de l'initial », pour reprendre ce que dit la norme ;
alors si après cette transformation, tu filtres les codets qui indiquent les
changements d'état, et que tu passes le résultat au compilo, effectivement
l'implémentation va interpréter cela comme une fin de commentaire... mais il
y a tellement de source conformes qui vont devenir inutilisables que cela
devient une implémentation sans intérêt.

C'est en ce sens que j'entendais "sans erreur".

Où est l'erreur ?

Antoine

Antoine Leca

26/12/2005 à 17:49

In news:43b01636$0$31140$, loufoque va escriure:

Sur usenet, ou les courriels, le risque de n'importe quoi chez le
lecteur

Parce qu'il y a des clients qui sont incapable de lire l'entête
indiquant l'encodage des caractères ?

Oh oui !

Pour prendre un exemple dans ce fil, Pierre a ouvert avec
Subject: =?ISO-8859-15?Q?Noyeux_Joël_à_tous_...? Emmanuel a répondu avec
Subject: Re: Noyeux =?ISO-8859-15?Q?Joël_à_tous_...? Vincent, avec
Subject: Re: Noyeux Joël à tous ...
Jusque là, pas trop de souci. Celui de Vincent est en ligne avec l'ancienne
ligne (il faut aller lire d'autre entêtes pour savoir comment décoder le
sujet), tandis que Pierre et Emmanuel suivent les régles plus actuelles
(utilisation de l'encodage MIME, à la RFC 2047) ; mais tout le monde
préserve la règle du "Re: " préfixant les réponses, de manière compatible
qui plus est.
On trouve aussi (avec un pseudo fou)
Subject: Re: Noyeux =?ISO-8859-1?Q?Joël_à_tous_...? qui a modifié subrepticement le jeu de caractères...

Mais d'autres ont répondus avec :-(
Subject: =?ISO-8859-15?Q?Re:_Noyeux_Joël_à_tous_...? Et là, un client un peu simplet (qui ne comprend pas le MIME) ne va pas «
voir » le Re:, donc il va répondre avec un
Subject: Re: =?ISO-8859-15?Q?Re:_Noyeux_Joël_à_tous_...? (affiché "Re: Re: Noyeux Joël à tous ..." chez toi), voire s'il a un
encodeur MIME mais pas de décodeur (ou bien s'il a perdu le "Mime-version:
1.0") on a obtenir le « superbe »
Subject: Re: =?iso-8859-1?Q?=?ISO-8859-15?Q?Re:_? =?iso-8859-1?Noyeux_Jo�l_�_tous_...?=?
Et je te fais grâce des clients qui remplacent "Re: " par une variante
nationale, genre ("Re : " en français, louable intention), et le font...
dans le message envoyé en NNTP (bogue).

Enfin, sauf si tu es dans un environnement EBCDIC, tu as toutes les chances
qu'entre le texte du message, et le fichier source fourni au compilateur,
l'information du jeu de caractère aura disparu.

Antoine

Vous avez filtré cet utilisateur ! Consultez son message

Noyeux Joël à tous ...

10 réponses

Veuillez sélectionner un problème