D'ailleurs, dans le manuel de MT-N, on peut lire : ========= > However, some articles labelled as "ISO-8859-1" are actually encoded using some totally different encoding -- MT-NewsWatcher tries to detect this by checking the article text for a high proportion of high-ASCII characters, and ignores the label in these cases. =========
Un ne dirait pas une histoire de paille et de poutre déjà entendue par ailleur là ;-))) -- Gilbert
le 3 novembre 2019; M.V. m'a confié :
D'ailleurs, dans le manuel de MT-N, on peut lire :
========= > However, some articles labelled as "ISO-8859-1" are
actually encoded using some totally different encoding --
MT-NewsWatcher tries to detect this by checking the article
text for a high proportion of high-ASCII characters, and
ignores the label in these cases.
=========
Un ne dirait pas une histoire de paille et de poutre déjà entendue par
ailleur là ;-)))
D'ailleurs, dans le manuel de MT-N, on peut lire : ========= > However, some articles labelled as "ISO-8859-1" are actually encoded using some totally different encoding -- MT-NewsWatcher tries to detect this by checking the article text for a high proportion of high-ASCII characters, and ignores the label in these cases. =========
Un ne dirait pas une histoire de paille et de poutre déjà entendue par ailleur là ;-))) -- Gilbert
josephb
MV wrote:
C'est donc MacSOUP qui a corrigé l'encodage en remplaçant ISO-8859-1 par ISO-8859-15 ! Et il affiche correctement "¼il pour ½il et ¤ pour ¤" dans le post auquel JB a répondu malgré le "Content-Type: text/plain; charset=ISO-8859-1" de l'entête !
Voilà, tu as tout compris ;-) J'imagine que MacSoup fait appel à l'Encodeur Système (je ne me rappelle pas le nom canonique) pour du 8859-15 même s'il voit 8859-1 dans l'entête. -- J. B.
MV <mv@orange.fr.invalid> wrote:
C'est donc MacSOUP qui a corrigé l'encodage en remplaçant ISO-8859-1 par
ISO-8859-15 !
Et il affiche correctement "¼il pour ½il et ¤ pour ¤" dans le post
auquel JB a répondu malgré le
"Content-Type: text/plain; charset=ISO-8859-1" de l'entête !
Voilà, tu as tout compris ;-)
J'imagine que MacSoup fait appel à l'Encodeur Système (je ne me rappelle
pas le nom canonique) pour du 8859-15 même s'il voit 8859-1 dans
l'entête.
--
J. B.
C'est donc MacSOUP qui a corrigé l'encodage en remplaçant ISO-8859-1 par ISO-8859-15 ! Et il affiche correctement "¼il pour ½il et ¤ pour ¤" dans le post auquel JB a répondu malgré le "Content-Type: text/plain; charset=ISO-8859-1" de l'entête !
Voilà, tu as tout compris ;-) J'imagine que MacSoup fait appel à l'Encodeur Système (je ne me rappelle pas le nom canonique) pour du 8859-15 même s'il voit 8859-1 dans l'entête. -- J. B.
M.V.
Le 3 novembre 2019 à 18:58, tu as écrit :
Un ne dirait pas une histoire de paille et de poutre déjà entendue par ailleur là
Si vraiment MT-NW cherche à vérifier que l'encodage correspond à ce qui est annoncé dans les entêtes, c'est effectivement une aide pour l'utilisateur en tant que lecteur mais l'effet pervers est effectivement d'envoyer des trucs illisibles à l'extérieur sans que l'expéditeur s'en rende compte. C'est donc, à mon avis, une très mauvaise idée. Je me trompe ou bien MacCafé envoie systématiquement de l'UTF-8 ? Et si oui, pourquoi certains logiciels envoient ou simplement peuvent envoyer autre chose ? Est-ce plus économique d'envoyer du Latin 1 que de l'UTF-8 ? Les anglo-saxons utilisent-ils des machins qui ne reconnaissent que de l'ASCII par exemple ? -- Michel VAUQUOIS - http://michelvauquois.fr
Le 3 novembre 2019 à 18:58, tu as écrit :
Un ne dirait pas une histoire de paille et de poutre déjà entendue par
ailleur là
Si vraiment MT-NW cherche à vérifier que l'encodage correspond à ce
qui est annoncé dans les entêtes, c'est effectivement une aide pour
l'utilisateur en tant que lecteur mais l'effet pervers est
effectivement d'envoyer des trucs illisibles à l'extérieur sans que
l'expéditeur s'en rende compte.
C'est donc, à mon avis, une très mauvaise idée.
Je me trompe ou bien MacCafé envoie systématiquement de l'UTF-8 ?
Et si oui, pourquoi certains logiciels envoient ou simplement peuvent
envoyer autre chose ? Est-ce plus économique d'envoyer du Latin 1 que
de l'UTF-8 ?
Les anglo-saxons utilisent-ils des machins qui ne reconnaissent que
de l'ASCII par exemple ?
Un ne dirait pas une histoire de paille et de poutre déjà entendue par ailleur là
Si vraiment MT-NW cherche à vérifier que l'encodage correspond à ce qui est annoncé dans les entêtes, c'est effectivement une aide pour l'utilisateur en tant que lecteur mais l'effet pervers est effectivement d'envoyer des trucs illisibles à l'extérieur sans que l'expéditeur s'en rende compte. C'est donc, à mon avis, une très mauvaise idée. Je me trompe ou bien MacCafé envoie systématiquement de l'UTF-8 ? Et si oui, pourquoi certains logiciels envoient ou simplement peuvent envoyer autre chose ? Est-ce plus économique d'envoyer du Latin 1 que de l'UTF-8 ? Les anglo-saxons utilisent-ils des machins qui ne reconnaissent que de l'ASCII par exemple ? -- Michel VAUQUOIS - http://michelvauquois.fr
JPP
In article <qpmu3v$stm$, DV wrote:
M.V. a écrit ceci :
Le 3 novembre 2019 à 16:02, Gilbert OLIVIER m'a répondu :
dans MTN tu vois le e dans l'o dans le titre !?
Ouiiiiiiii !
Je soupçonne que ton MTN l'affiche correctement parce qu'il en est à l'origine (c'est ce que je soupçonnais déjà en disant à JPP que ce qu'il voyait dans MTN importait peu). Maintenant, je serais curieux de savoir comment ce même titre s'affiche dans le MTN de JPP...
Bonsoir Denis, Ce titre s'affiche mal . "Re: ëil pour õil, le retour" en affichant tous les Headers : Subject: =?UTF-8?B?UmU6IMKRaWwgcG91ciDCpmlsLCBsZSByZXRvdXI=? Date: Sun, 3 Nov 2019 17:09:34 +0100 Organization: Posted through ALPHANET (http://www.alphanet.ch/) Lines: 15 Sender: Message-ID: <qpmu3v$stm$ References:
In article <qpmu3v$stm$1@shakotay.alphanet.ch>,
DV <dv@reply-to.not.invalid> wrote:
M.V. a écrit ceci :
> Le 3 novembre 2019 à 16:02, Gilbert OLIVIER m'a répondu :
>
>> dans MTN tu vois le e dans l'o dans le titre !?
>
> Ouiiiiiiii !
Je soupçonne que ton MTN l'affiche correctement parce qu'il en est à
l'origine (c'est ce que je soupçonnais déjà en disant à JPP que ce qu'il
voyait dans MTN importait peu). Maintenant, je serais curieux de savoir
comment ce même titre s'affiche dans le MTN de JPP...
Bonsoir Denis,
Ce titre s'affiche mal .
"Re: ëil pour õil, le retour"
en affichant tous les Headers :
Subject: =?UTF-8?B?UmU6IMKRaWwgcG91ciDCpmlsLCBsZSByZXRvdXI=? Date: Sun, 3 Nov 2019 17:09:34 +0100
Organization: Posted through ALPHANET (http://www.alphanet.ch/)
Lines: 15
Sender: chienflou@aorleans-654-1-22-241.w90-20.abo.wanadoo.fr
Message-ID: <qpmu3v$stm$1@shakotay.alphanet.ch>
References:
<michel.vauquois-821835.14214203112019@news.eternal-september.org>
<michel.vauquois-CF62FF.14245103112019@news.eternal-september.org>
<michel.vauquois-0CA4E4.14281703112019@news.eternal-september.org>
<michel.vauquois-F2D2E7.14344103112019@news.eternal-september.org>
<qpmnba$rs0$1@shakotay.alphanet.ch> <qpmob4$rq5$2@dont-email.me>
<qpmq6o$gg6$1@shakotay.alphanet.ch> <qpmrel$dse$1@dont-email.me>
Reply-To: dv@s173327841.onlinehome.fr
NNTP-Posting-Host: aorleans-654-1-22-241.w90-20.abo.wanadoo.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Le 3 novembre 2019 à 16:02, Gilbert OLIVIER m'a répondu :
dans MTN tu vois le e dans l'o dans le titre !?
Ouiiiiiiii !
Je soupçonne que ton MTN l'affiche correctement parce qu'il en est à l'origine (c'est ce que je soupçonnais déjà en disant à JPP que ce qu'il voyait dans MTN importait peu). Maintenant, je serais curieux de savoir comment ce même titre s'affiche dans le MTN de JPP...
Bonsoir Denis, Ce titre s'affiche mal . "Re: ëil pour õil, le retour" en affichant tous les Headers : Subject: =?UTF-8?B?UmU6IMKRaWwgcG91ciDCpmlsLCBsZSByZXRvdXI=? Date: Sun, 3 Nov 2019 17:09:34 +0100 Organization: Posted through ALPHANET (http://www.alphanet.ch/) Lines: 15 Sender: Message-ID: <qpmu3v$stm$ References:
Ouais, enfin au bout de quelques remarques je me serai pos plus de questions et demand des prcisions...
Vilain JPP !
Olivier Miakinen
Le 03/11/2019 17:16, Elephant Man répondait à MV :
Mac Café ne fait rien de tout ça. Quelle tambouille !
Oui, enfin, tant qu'il n'est pas accessible au public, on ne peut pas vraiment reprocher quelque chose à Mac Café. Mais ça doit s'ajouter à la todo list de ce pauvre GO :)
Non seulement il n'y a rien à reprocher à Mac Café, mais surtout il n'y a rien à ajouter à la todo list car Mac Café fait *ce qu'il faut*. De ce que je vois depuis le début de ces discussions, MT-NewsWatcher est capable : 1) d'envoyer un message avec un charset incompatible avec les caractères que l'utilisateur avait saisis, sans prévenir cet utilisateur ; 2) de passer outre le charset annoncé à la lecture, en se croyant plus intelligent que celui qui a écrit l'article. Le point numéro 1 est le pire. Si le charset par défaut est Latin 1 et que l'utilisateur essaye d'envoyer un ¤ ou un ½, le logiciel devrait prévenir son utilisateur que ce n'est pas possible, et lui proposer de choisir entre changer d'encodage (pour Latin 9 ou UTF-8 par exemple) ou réécrire son message pour supprimer les caractères incompatibles. Ou alors /a minima/, si poser la question à l'utilisateur n'est pas une option, le logiciel devrait choisir lui-même le charset le plus adapté. Mais ajouté à cet énorme bug, le point numéro 2 a comme conséquence que l'utilisateur de ce logiciel ne peut même pas se rendre compte que celui-ci est bugué ! J'y vois l'origine de l'évidente animosité de MV envers JPP, car JPP en toute bonne foi pouvait croire que son logiciel était parfait, alors que MV devait être persuadé que JPP était d'une mauvaise foi abyssale pour ne pas se rendre compte du bug. Et donc, si Gilbert ne veut pas que les utilisateurs de Mac Café suscitent la haine de la part des utilisateurs d'autres logiciels, il faut absolument qu'il ne copie pas ces mauvais choix d'implémentation qui sont dans MT-NewsWatcher. Par ailleurs j'espère que Michel, ayant compris qu'il n'y avait aucune mauvaise volonté dans l'attitude de Jean-Pierre, acceptera d'enterrer la hache de guerre et de repartir sur des bases plus saines. -- Olivier Miakinen
Le 03/11/2019 17:16, Elephant Man répondait à MV :
Mac Café ne fait rien de tout ça.
Quelle tambouille !
Oui, enfin, tant qu'il n'est pas accessible au public, on ne peut pas
vraiment reprocher quelque chose à Mac Café. Mais ça doit s'ajouter à
la todo list de ce pauvre GO :)
Non seulement il n'y a rien à reprocher à Mac Café, mais surtout il n'y
a rien à ajouter à la todo list car Mac Café fait *ce qu'il faut*.
De ce que je vois depuis le début de ces discussions, MT-NewsWatcher
est capable :
1) d'envoyer un message avec un charset incompatible avec les caractères
que l'utilisateur avait saisis, sans prévenir cet utilisateur ;
2) de passer outre le charset annoncé à la lecture, en se croyant plus
intelligent que celui qui a écrit l'article.
Le point numéro 1 est le pire. Si le charset par défaut est Latin 1
et que l'utilisateur essaye d'envoyer un ¤ ou un ½, le logiciel
devrait prévenir son utilisateur que ce n'est pas possible, et lui
proposer de choisir entre changer d'encodage (pour Latin 9 ou UTF-8
par exemple) ou réécrire son message pour supprimer les caractères
incompatibles. Ou alors /a minima/, si poser la question à l'utilisateur
n'est pas une option, le logiciel devrait choisir lui-même le charset
le plus adapté.
Mais ajouté à cet énorme bug, le point numéro 2 a comme conséquence
que l'utilisateur de ce logiciel ne peut même pas se rendre compte
que celui-ci est bugué ! J'y vois l'origine de l'évidente animosité
de MV envers JPP, car JPP en toute bonne foi pouvait croire que son
logiciel était parfait, alors que MV devait être persuadé que JPP
était d'une mauvaise foi abyssale pour ne pas se rendre compte du bug.
Et donc, si Gilbert ne veut pas que les utilisateurs de Mac Café
suscitent la haine de la part des utilisateurs d'autres logiciels, il
faut absolument qu'il ne copie pas ces mauvais choix d'implémentation
qui sont dans MT-NewsWatcher.
Par ailleurs j'espère que Michel, ayant compris qu'il n'y avait aucune
mauvaise volonté dans l'attitude de Jean-Pierre, acceptera d'enterrer
la hache de guerre et de repartir sur des bases plus saines.
Le 03/11/2019 17:16, Elephant Man répondait à MV :
Mac Café ne fait rien de tout ça. Quelle tambouille !
Oui, enfin, tant qu'il n'est pas accessible au public, on ne peut pas vraiment reprocher quelque chose à Mac Café. Mais ça doit s'ajouter à la todo list de ce pauvre GO :)
Non seulement il n'y a rien à reprocher à Mac Café, mais surtout il n'y a rien à ajouter à la todo list car Mac Café fait *ce qu'il faut*. De ce que je vois depuis le début de ces discussions, MT-NewsWatcher est capable : 1) d'envoyer un message avec un charset incompatible avec les caractères que l'utilisateur avait saisis, sans prévenir cet utilisateur ; 2) de passer outre le charset annoncé à la lecture, en se croyant plus intelligent que celui qui a écrit l'article. Le point numéro 1 est le pire. Si le charset par défaut est Latin 1 et que l'utilisateur essaye d'envoyer un ¤ ou un ½, le logiciel devrait prévenir son utilisateur que ce n'est pas possible, et lui proposer de choisir entre changer d'encodage (pour Latin 9 ou UTF-8 par exemple) ou réécrire son message pour supprimer les caractères incompatibles. Ou alors /a minima/, si poser la question à l'utilisateur n'est pas une option, le logiciel devrait choisir lui-même le charset le plus adapté. Mais ajouté à cet énorme bug, le point numéro 2 a comme conséquence que l'utilisateur de ce logiciel ne peut même pas se rendre compte que celui-ci est bugué ! J'y vois l'origine de l'évidente animosité de MV envers JPP, car JPP en toute bonne foi pouvait croire que son logiciel était parfait, alors que MV devait être persuadé que JPP était d'une mauvaise foi abyssale pour ne pas se rendre compte du bug. Et donc, si Gilbert ne veut pas que les utilisateurs de Mac Café suscitent la haine de la part des utilisateurs d'autres logiciels, il faut absolument qu'il ne copie pas ces mauvais choix d'implémentation qui sont dans MT-NewsWatcher. Par ailleurs j'espère que Michel, ayant compris qu'il n'y avait aucune mauvaise volonté dans l'attitude de Jean-Pierre, acceptera d'enterrer la hache de guerre et de repartir sur des bases plus saines. -- Olivier Miakinen
Olivier Miakinen
Bonjour, Le 03/11/2019 18:02, DV a écrit :
M.V. a écrit ceci :
D'ailleurs, dans le manuel de MT-N, on peut lire : ========= >> However, some articles labelled as "ISO-8859-1" are actually encoded using some totally different encoding -- MT-NewsWatcher tries to detect this by checking the article text for a high proportion of high-ASCII characters, and ignores the label in these cases. ========= >> Ceci explique peut-être cela.
C'est bien possible en effet. C'est sympa que MT-N fasse ce travail,
Je ne peux qu'être en complet désaccord avec cette opinion. Ce n'est pas sympa, c'est désastreux.
mais s'il corrige aussi ses propres productions mal encodées, cela ne peut que compliquer le diagnostic.
Voilà. Et faire croire à un non-utilisateur de MT-N qu'un utilisateur de ce logiciel se fout de sa gueule, alors que ce n'était pas du tout le cas. -- Olivier Miakinen
Bonjour,
Le 03/11/2019 18:02, DV a écrit :
M.V. a écrit ceci :
D'ailleurs, dans le manuel de MT-N, on peut lire :
========= >> However, some articles labelled as "ISO-8859-1" are
actually encoded using some totally different encoding --
MT-NewsWatcher tries to detect this by checking the article
text for a high proportion of high-ASCII characters, and
ignores the label in these cases.
========= >>
Ceci explique peut-être cela.
C'est bien possible en effet. C'est sympa que MT-N fasse ce travail,
Je ne peux qu'être en complet désaccord avec cette opinion. Ce n'est
pas sympa, c'est désastreux.
mais s'il corrige aussi ses propres productions mal encodées, cela ne
peut que compliquer le diagnostic.
Voilà. Et faire croire à un non-utilisateur de MT-N qu'un utilisateur
de ce logiciel se fout de sa gueule, alors que ce n'était pas du tout
le cas.
D'ailleurs, dans le manuel de MT-N, on peut lire : ========= >> However, some articles labelled as "ISO-8859-1" are actually encoded using some totally different encoding -- MT-NewsWatcher tries to detect this by checking the article text for a high proportion of high-ASCII characters, and ignores the label in these cases. ========= >> Ceci explique peut-être cela.
C'est bien possible en effet. C'est sympa que MT-N fasse ce travail,
Je ne peux qu'être en complet désaccord avec cette opinion. Ce n'est pas sympa, c'est désastreux.
mais s'il corrige aussi ses propres productions mal encodées, cela ne peut que compliquer le diagnostic.
Voilà. Et faire croire à un non-utilisateur de MT-N qu'un utilisateur de ce logiciel se fout de sa gueule, alors que ce n'était pas du tout le cas. -- Olivier Miakinen
Olivier Miakinen
Le 03/11/2019 20:07, M.V. a écrit :
Si vraiment MT-NW cherche à vérifier que l'encodage correspond à ce qui est annoncé dans les entêtes, c'est effectivement une aide pour l'utilisateur en tant que lecteur mais l'effet pervers est effectivement d'envoyer des trucs illisibles à l'extérieur sans que l'expéditeur s'en rende compte. C'est donc, à mon avis, une très mauvaise idée.
Nous sommes bien d'accord.
Je me trompe ou bien MacCafé envoie systématiquement de l'UTF-8 ? Et si oui, pourquoi certains logiciels envoient ou simplement peuvent envoyer autre chose ? Est-ce plus économique d'envoyer du Latin 1 que de l'UTF-8 ? Les anglo-saxons utilisent-ils des machins qui ne reconnaissent que de l'ASCII par exemple ?
À l'heure du web 2.0 où la moindre page web est surchargée de dizaines de milliers d'octets de JavaScript là où quelques dizaines d'octets suffiraient pour le contenu réel, c'est vrai que choisir systématiquement l'UTF-8 ne change pas grand chose. Mais dans l'absolu, oui, le Latin-1 est un peu plus économique que l'UTF-8 dès qu'il y a des caractères accentués (2 octets au lieu d'1 par caractère accentué, alors que l'UTF-8 est équivalent à Latin-1 et à US-ASCII quand il n'y en a pas). Ça c'est pour le français. Pour le japonais, par exemple, des charsets nationaux à 2 octets par caractère sont plus efficaces que l'UTF-8 qui, le plus souvent, en a besoin de 3. Et je crois qu'il y a encore un assez grand nombre de logiciels qui adaptent le charset au contenu : US-ASCII si on n'utilise aucun caractère accentué, Latin-1 s'il y a des « é », des « à » et des « ç », éventuellement Latin-9 si on y ajoute un « ½ » ou un « ¤ », pour finir par UTF-8 dans les cas insolubles. -- Olivier Miakinen
Le 03/11/2019 20:07, M.V. a écrit :
Si vraiment MT-NW cherche à vérifier que l'encodage correspond à ce
qui est annoncé dans les entêtes, c'est effectivement une aide pour
l'utilisateur en tant que lecteur mais l'effet pervers est
effectivement d'envoyer des trucs illisibles à l'extérieur sans que
l'expéditeur s'en rende compte.
C'est donc, à mon avis, une très mauvaise idée.
Nous sommes bien d'accord.
Je me trompe ou bien MacCafé envoie systématiquement de l'UTF-8 ?
Et si oui, pourquoi certains logiciels envoient ou simplement peuvent
envoyer autre chose ? Est-ce plus économique d'envoyer du Latin 1 que
de l'UTF-8 ?
Les anglo-saxons utilisent-ils des machins qui ne reconnaissent que
de l'ASCII par exemple ?
À l'heure du web 2.0 où la moindre page web est surchargée de dizaines
de milliers d'octets de JavaScript là où quelques dizaines d'octets
suffiraient pour le contenu réel, c'est vrai que choisir systématiquement
l'UTF-8 ne change pas grand chose.
Mais dans l'absolu, oui, le Latin-1 est un peu plus économique que
l'UTF-8 dès qu'il y a des caractères accentués (2 octets au lieu d'1
par caractère accentué, alors que l'UTF-8 est équivalent à Latin-1
et à US-ASCII quand il n'y en a pas).
Ça c'est pour le français. Pour le japonais, par exemple, des
charsets nationaux à 2 octets par caractère sont plus efficaces
que l'UTF-8 qui, le plus souvent, en a besoin de 3.
Et je crois qu'il y a encore un assez grand nombre de logiciels qui
adaptent le charset au contenu : US-ASCII si on n'utilise aucun
caractère accentué, Latin-1 s'il y a des « é », des « à » et des
« ç », éventuellement Latin-9 si on y ajoute un « ½ » ou un « ¤ »,
pour finir par UTF-8 dans les cas insolubles.
Si vraiment MT-NW cherche à vérifier que l'encodage correspond à ce qui est annoncé dans les entêtes, c'est effectivement une aide pour l'utilisateur en tant que lecteur mais l'effet pervers est effectivement d'envoyer des trucs illisibles à l'extérieur sans que l'expéditeur s'en rende compte. C'est donc, à mon avis, une très mauvaise idée.
Nous sommes bien d'accord.
Je me trompe ou bien MacCafé envoie systématiquement de l'UTF-8 ? Et si oui, pourquoi certains logiciels envoient ou simplement peuvent envoyer autre chose ? Est-ce plus économique d'envoyer du Latin 1 que de l'UTF-8 ? Les anglo-saxons utilisent-ils des machins qui ne reconnaissent que de l'ASCII par exemple ?
À l'heure du web 2.0 où la moindre page web est surchargée de dizaines de milliers d'octets de JavaScript là où quelques dizaines d'octets suffiraient pour le contenu réel, c'est vrai que choisir systématiquement l'UTF-8 ne change pas grand chose. Mais dans l'absolu, oui, le Latin-1 est un peu plus économique que l'UTF-8 dès qu'il y a des caractères accentués (2 octets au lieu d'1 par caractère accentué, alors que l'UTF-8 est équivalent à Latin-1 et à US-ASCII quand il n'y en a pas). Ça c'est pour le français. Pour le japonais, par exemple, des charsets nationaux à 2 octets par caractère sont plus efficaces que l'UTF-8 qui, le plus souvent, en a besoin de 3. Et je crois qu'il y a encore un assez grand nombre de logiciels qui adaptent le charset au contenu : US-ASCII si on n'utilise aucun caractère accentué, Latin-1 s'il y a des « é », des « à » et des « ç », éventuellement Latin-9 si on y ajoute un « ½ » ou un « ¤ », pour finir par UTF-8 dans les cas insolubles. -- Olivier Miakinen
DV
Olivier Miakinen a écrit ceci :
Je ne peux qu'être en complet désaccord avec cette opinion. Ce n'est pas sympa, c'est désastreux.
Quand je dis "c'est sympa", je veux dire que ça part d'un bon sentiment, pas que c'est une bonne chose, cf. la suite de ma réponse. -- Denis
Olivier Miakinen a écrit ceci :
Je ne peux qu'être en complet désaccord avec cette opinion. Ce n'est
pas sympa, c'est désastreux.
Quand je dis "c'est sympa", je veux dire que ça part d'un bon sentiment,
pas que c'est une bonne chose, cf. la suite de ma réponse.
