Question sur la solut =?UTF-8?Q?ion_Némo?
Mal encodé mais guillemets supprimées pour voir la réaction de MacCafé.
--
Michel VAUQUOIS - <http://michelvauquois.fr>
Le 17 juin 2021 Í 20:20, Olivier Miakinen s'est exprimé en ces termes :
De plus, comme l'a indiqué O.M., quand un caractère est introuvable ce n'est pas forcément ce « replacement character » qui est utilisé :
Je ne crois pas l'avoir dit (en tout cas pas récemment) mais je suis d'accord avec ça.
Ce n'est pas ce que tu as dit *très très très* récemment ici : <news:sag20p$u87$ ? -- Michel VAUQUOIS - <http://michelvauquois.fr>
Le 17 juin 2021 Í 20:20, Olivier Miakinen s'est exprimé en ces termes :
De plus, comme l'a indiqué O.M., quand un caractère est introuvable ce
n'est pas forcément ce « replacement character » qui est utilisé :
Je ne crois pas l'avoir dit (en tout cas pas récemment) mais je suis
d'accord avec ça.
Ce n'est pas ce que tu as dit *très très très* récemment ici :
<news:sag20p$u87$1@cabale.usenet-fr.net> ?
--
Michel VAUQUOIS - <http://michelvauquois.fr>
Le 17 juin 2021 Í 20:20, Olivier Miakinen s'est exprimé en ces termes :
De plus, comme l'a indiqué O.M., quand un caractère est introuvable ce n'est pas forcément ce « replacement character » qui est utilisé :
Je ne crois pas l'avoir dit (en tout cas pas récemment) mais je suis d'accord avec ça.
Ce n'est pas ce que tu as dit *très très très* récemment ici : <news:sag20p$u87$ ? -- Michel VAUQUOIS - <http://michelvauquois.fr>
Olivier Miakinen
Le 17/06/2021 20:56, M.V. a écrit :
De plus, comme l'a indiqué O.M., quand un caractère est introuvable ce n'est pas forcément ce « replacement character » qui est utilisé :
Je ne crois pas l'avoir dit (en tout cas pas récemment) mais je suis d'accord avec ça.
Ce n'est pas ce que tu as dit *très très très* récemment ici : <news:sag20p$u87$ ?
Non. Je parlais dans cet article de ce que *devrait* faire une application quand elle cherche le caractère de remplacement pour remplacer un caractère introuvable, et que ce caractère est lui-même introuvable. Plus exactement je parlais du fait qu'il n'y a rien qu'on *devrait* attendre d'elle dans ce cas. Je ne parlais pas du fait que certaines applications ne cherchent même pas Í utiliser ce caractère de remplacement défini dans Unicode (ce avec quoi j'ai dit que j'étais d'accord alors que je n'en avais pas parlé récemment). -- Olivier Miakinen
Le 17/06/2021 20:56, M.V. a écrit :
De plus, comme l'a indiqué O.M., quand un caractère est introuvable ce
n'est pas forcément ce « replacement character » qui est utilisé :
Je ne crois pas l'avoir dit (en tout cas pas récemment) mais je suis
d'accord avec ça.
Ce n'est pas ce que tu as dit *très très très* récemment ici :
<news:sag20p$u87$1@cabale.usenet-fr.net> ?
Non. Je parlais dans cet article de ce que *devrait* faire une application
quand elle cherche le caractère de remplacement pour remplacer un caractère
introuvable, et que ce caractère est lui-même introuvable. Plus exactement
je parlais du fait qu'il n'y a rien qu'on *devrait* attendre d'elle dans ce
cas.
Je ne parlais pas du fait que certaines applications ne cherchent même pas
Í utiliser ce caractère de remplacement défini dans Unicode (ce avec quoi
j'ai dit que j'étais d'accord alors que je n'en avais pas parlé récemment).
De plus, comme l'a indiqué O.M., quand un caractère est introuvable ce n'est pas forcément ce « replacement character » qui est utilisé :
Je ne crois pas l'avoir dit (en tout cas pas récemment) mais je suis d'accord avec ça.
Ce n'est pas ce que tu as dit *très très très* récemment ici : <news:sag20p$u87$ ?
Non. Je parlais dans cet article de ce que *devrait* faire une application quand elle cherche le caractère de remplacement pour remplacer un caractère introuvable, et que ce caractère est lui-même introuvable. Plus exactement je parlais du fait qu'il n'y a rien qu'on *devrait* attendre d'elle dans ce cas. Je ne parlais pas du fait que certaines applications ne cherchent même pas Í utiliser ce caractère de remplacement défini dans Unicode (ce avec quoi j'ai dit que j'étais d'accord alors que je n'en avais pas parlé récemment). -- Olivier Miakinen
DV
Olivier Miakinen a écrit ceci :
Lorsque j'ai vu la même chose dans Internet Explorer, je crois bien que c'était sur Windows 2000, mais peut-être aussi sur Windows 7.
J'ai trouvé ça, si ça peut aider Í dater les choses : <https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows> -- Denis
Olivier Miakinen a écrit ceci :
Lorsque j'ai vu la même chose dans Internet Explorer, je crois bien que c'était
sur Windows 2000, mais peut-être aussi sur Windows 7.
J'ai trouvé ça, si ça peut aider Í dater les choses :
Lorsque j'ai vu la même chose dans Internet Explorer, je crois bien que c'était sur Windows 2000, mais peut-être aussi sur Windows 7.
J'ai trouvé ça, si ça peut aider Í dater les choses : <https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows> -- Denis
M.V.
Le 17 juin 2021 Í 21:07, Olivier Miakinen s'est exprimé en ces termes :
Ce n'est pas ce que tu as dit *très très très* récemment ici : <news:sag20p$u87$ ?
Non.
OK. Ce que je comprends et constate c'est que « caractère introuvable » n'est pas équivalent Í ï¿½ ie � ne signifie pas forcément « caractère introuvable » et « caractère introuvable » ne se traduit pas forcément par �. -- Michel VAUQUOIS - <http://michelvauquois.fr>
Le 17 juin 2021 Í 21:07, Olivier Miakinen s'est exprimé en ces termes :
Ce n'est pas ce que tu as dit *très très très* récemment ici :
<news:sag20p$u87$1@cabale.usenet-fr.net> ?
Non.
OK.
Ce que je comprends et constate c'est que
« caractère introuvable » n'est pas équivalent Í ï¿½
ie
� ne signifie pas forcément « caractère introuvable » et « caractère
introuvable » ne se traduit pas forcément par �.
--
Michel VAUQUOIS - <http://michelvauquois.fr>
Le 17 juin 2021 Í 21:07, Olivier Miakinen s'est exprimé en ces termes :
Ce n'est pas ce que tu as dit *très très très* récemment ici : <news:sag20p$u87$ ?
Non.
OK. Ce que je comprends et constate c'est que « caractère introuvable » n'est pas équivalent Í ï¿½ ie � ne signifie pas forcément « caractère introuvable » et « caractère introuvable » ne se traduit pas forcément par �. -- Michel VAUQUOIS - <http://michelvauquois.fr>
Olivier Miakinen
Salut, je m'aperçois que j'ai écrit un peu n'importe quoi. Le 17/06/2021 20:20, Olivier Miakinen a écrit :
Le 17/06/2021 20:11, M.V. a écrit :
Le 17 juin 2021 Í 19:34, yamo' s'est exprimé en ces termes :
Mais d'habitude, ce caractère indique que le caractère est introuvable.
Tout Í fait… sauf quand le caractère soi-disant introuvable est… � !
[Oui]
En fait [Non]. Le caractère de remplacement FFFD ne sert pas Í remplacer un caractère dont le glyphe est introuvable (en général les applications ne peuvent même pas le savoir). Il sert Í remplacer quelque chose qui n'est *pas* un caractère. Par exemple un octet unique de valeur E9 dans une chaÍ®ne censée être de l'UTF-8.
De plus, comme l'a indiqué O.M., quand un caractère est introuvable ce n'est pas forcément ce « replacement character » qui est utilisé :
Je ne crois pas l'avoir dit (en tout cas pas récemment) mais je suis d'accord avec ça.
Et donc oui, je l'avais dit. Quand un caractère est introuvable (quoique correctement décodé en une valeur Unicode valide), SeaMonkey affiche la valeur Unicode dans un rectangle et pas le caractère de remplacement. Toutes mes confuses, donc, je m'étais gourré. Qui plus est, je ne suis même pas très sÍ»r de savoir qui est responsable de l'affichage du glyphe, entre l'application et le système d'exploitation. -- Olivier Miakinen
Salut, je m'aperçois que j'ai écrit un peu n'importe quoi.
Le 17/06/2021 20:20, Olivier Miakinen a écrit :
Le 17/06/2021 20:11, M.V. a écrit :
Le 17 juin 2021 Í 19:34, yamo' s'est exprimé en ces termes :
Mais d'habitude, ce caractère indique que le caractère est introuvable.
Tout Í fait… sauf quand le caractère soi-disant introuvable est… � !
[Oui]
En fait [Non].
Le caractère de remplacement FFFD ne sert pas Í remplacer un caractère dont
le glyphe est introuvable (en général les applications ne peuvent même pas
le savoir). Il sert Í remplacer quelque chose qui n'est *pas* un caractère.
Par exemple un octet unique de valeur E9 dans une chaÍ®ne censée être de
l'UTF-8.
De plus, comme l'a indiqué O.M., quand un caractère est introuvable ce
n'est pas forcément ce « replacement character » qui est utilisé :
Je ne crois pas l'avoir dit (en tout cas pas récemment) mais je suis
d'accord avec ça.
Et donc oui, je l'avais dit. Quand un caractère est introuvable (quoique
correctement décodé en une valeur Unicode valide), SeaMonkey affiche la
valeur Unicode dans un rectangle et pas le caractère de remplacement.
Toutes mes confuses, donc, je m'étais gourré. Qui plus est, je ne suis
même pas très sÍ»r de savoir qui est responsable de l'affichage du glyphe,
entre l'application et le système d'exploitation.
Salut, je m'aperçois que j'ai écrit un peu n'importe quoi. Le 17/06/2021 20:20, Olivier Miakinen a écrit :
Le 17/06/2021 20:11, M.V. a écrit :
Le 17 juin 2021 Í 19:34, yamo' s'est exprimé en ces termes :
Mais d'habitude, ce caractère indique que le caractère est introuvable.
Tout Í fait… sauf quand le caractère soi-disant introuvable est… � !
[Oui]
En fait [Non]. Le caractère de remplacement FFFD ne sert pas Í remplacer un caractère dont le glyphe est introuvable (en général les applications ne peuvent même pas le savoir). Il sert Í remplacer quelque chose qui n'est *pas* un caractère. Par exemple un octet unique de valeur E9 dans une chaÍ®ne censée être de l'UTF-8.
De plus, comme l'a indiqué O.M., quand un caractère est introuvable ce n'est pas forcément ce « replacement character » qui est utilisé :
Je ne crois pas l'avoir dit (en tout cas pas récemment) mais je suis d'accord avec ça.
Et donc oui, je l'avais dit. Quand un caractère est introuvable (quoique correctement décodé en une valeur Unicode valide), SeaMonkey affiche la valeur Unicode dans un rectangle et pas le caractère de remplacement. Toutes mes confuses, donc, je m'étais gourré. Qui plus est, je ne suis même pas très sÍ»r de savoir qui est responsable de l'affichage du glyphe, entre l'application et le système d'exploitation. -- Olivier Miakinen
M.V.
Hormis dans un lecteur de nouvelles ou sur une page web, je ne dois pas avoir rencontré ce � très souvent. Le 17 juin 2021 Í 23:42, Olivier Miakinen s'est exprimé en ces termes :
Mais d'habitude, ce caractère indique que le caractère est introuvable.
Tout Í fait… sauf quand le caractère soi-disant introuvable est… � !
[Oui]
En fait [Non]. Le caractère de remplacement FFFD ne sert pas Í remplacer un caractère dont le glyphe est introuvable (en général les applications ne peuvent même pas le savoir). Il sert Í remplacer quelque chose qui n'est *pas* un caractère.
J'explicite ce que j'ai répondu Í yamo' : Ce que j'ai compris de ce que voulait dire yamo', c'est que, et c'est me semble-t-il le cas, le caractère � se rencontre souvent (mais pas toujours notamment ici ! ) lorsqu'il y a un problème d'affichage de caractère notamment dans le cas d'un mauvais encodage comme lorsque, par exemple, SeaMonkey rencontre =?UTF-8?Q?é?= (C'est en tout cas ce que m'a rapporté DV) et pas vraiment quand le caractère est introuvable au sens strict. Mais quand on voit ici �, ce n'est pas parce qu'il y a un problème d'aucune sorte mais parce que… j'ai tapé � !
je ne suis même pas très sÍ»r de savoir qui est responsable de l'affichage du glyphe, entre l'application et le système d'exploitation.
Mais pour en revenir Í un lecteur de news, ce serait plutÍ´t le logiciel qui choisit ce qu'il affiche en rencontrant =?UTF-8?Q?é?=, non ? -- Michel VAUQUOIS - <http://michelvauquois.fr>
Hormis dans un lecteur de nouvelles ou sur une page web, je ne dois pas
avoir rencontré ce � très souvent.
Le 17 juin 2021 Í 23:42, Olivier Miakinen s'est exprimé en ces termes :
Mais d'habitude, ce caractère indique que le caractère est introuvable.
Tout Í fait… sauf quand le caractère soi-disant introuvable est… � !
[Oui]
En fait [Non].
Le caractère de remplacement FFFD ne sert pas Í remplacer un caractère dont
le glyphe est introuvable (en général les applications ne peuvent même pas
le savoir). Il sert Í remplacer quelque chose qui n'est *pas* un caractère.
J'explicite ce que j'ai répondu Í yamo' :
Ce que j'ai compris de ce que voulait dire yamo', c'est que, et c'est me
semble-t-il le cas, le caractère � se rencontre souvent (mais pas
toujours notamment ici ! ) lorsqu'il y a un problème d'affichage de
caractère notamment dans le cas d'un mauvais encodage comme lorsque, par
exemple, SeaMonkey rencontre =?UTF-8?Q?é?= (C'est en tout cas ce que
m'a rapporté DV) et pas vraiment quand le caractère est introuvable au
sens strict.
Mais quand on voit ici �, ce n'est pas parce qu'il y a un problème
d'aucune sorte mais parce que… j'ai tapé � !
je ne suis même pas très sÍ»r de savoir qui est responsable de
l'affichage du glyphe, entre l'application et le système d'exploitation.
Mais pour en revenir Í un lecteur de news, ce serait plutÍ´t le logiciel
qui choisit ce qu'il affiche en rencontrant =?UTF-8?Q?é?=, non ?
--
Michel VAUQUOIS - <http://michelvauquois.fr>
Hormis dans un lecteur de nouvelles ou sur une page web, je ne dois pas avoir rencontré ce � très souvent. Le 17 juin 2021 Í 23:42, Olivier Miakinen s'est exprimé en ces termes :
Mais d'habitude, ce caractère indique que le caractère est introuvable.
Tout Í fait… sauf quand le caractère soi-disant introuvable est… � !
[Oui]
En fait [Non]. Le caractère de remplacement FFFD ne sert pas Í remplacer un caractère dont le glyphe est introuvable (en général les applications ne peuvent même pas le savoir). Il sert Í remplacer quelque chose qui n'est *pas* un caractère.
J'explicite ce que j'ai répondu Í yamo' : Ce que j'ai compris de ce que voulait dire yamo', c'est que, et c'est me semble-t-il le cas, le caractère � se rencontre souvent (mais pas toujours notamment ici ! ) lorsqu'il y a un problème d'affichage de caractère notamment dans le cas d'un mauvais encodage comme lorsque, par exemple, SeaMonkey rencontre =?UTF-8?Q?é?= (C'est en tout cas ce que m'a rapporté DV) et pas vraiment quand le caractère est introuvable au sens strict. Mais quand on voit ici �, ce n'est pas parce qu'il y a un problème d'aucune sorte mais parce que… j'ai tapé � !
je ne suis même pas très sÍ»r de savoir qui est responsable de l'affichage du glyphe, entre l'application et le système d'exploitation.
Mais pour en revenir Í un lecteur de news, ce serait plutÍ´t le logiciel qui choisit ce qu'il affiche en rencontrant =?UTF-8?Q?é?=, non ? -- Michel VAUQUOIS - <http://michelvauquois.fr>
DV
M.V. a écrit ceci :
Le 17 juin 2021 Í 23:42, Olivier Miakinen s'est exprimé en ces termes :
je ne suis même pas très sÍ»r de savoir qui est responsable de l'affichage du glyphe, entre l'application et le système d'exploitation.
Mais pour en revenir Í un lecteur de news, ce serait plutÍ´t le logiciel qui choisit ce qu'il affiche en rencontrant =?UTF-8?Q?é?=, non ?
C'est plus que probable. Voici ce que je lis pour l'article <news: publié sur fr.usenet.divers : - Thunderbird : Re: Question sur la solution "N�mo" - Pan :         Re: Question sur la solution "N?mo" - Claws Mail :  Re: Question sur la solution "N_mo" ces trois lecteurs de news étant installés sur la même machine sous Ubuntu. -- Denis
M.V. a écrit ceci :
Le 17 juin 2021 Í 23:42, Olivier Miakinen s'est exprimé en ces termes :
je ne suis même pas très sÍ»r de savoir qui est responsable de
l'affichage du glyphe, entre l'application et le système d'exploitation.
Mais pour en revenir Í un lecteur de news, ce serait plutÍ´t le logiciel
qui choisit ce qu'il affiche en rencontrant =?UTF-8?Q?é?=, non ?
C'est plus que probable. Voici ce que je lis pour l'article
<news:gdjecg9frl956gpd0602sd8icfoo7emfhe@news.free.fr> publié sur
fr.usenet.divers :
- Thunderbird : Re: Question sur la solution "N�mo"
- Pan :         Re: Question sur la solution "N?mo"
- Claws Mail :  Re: Question sur la solution "N_mo"
ces trois lecteurs de news étant installés sur la même machine sous
Ubuntu.
Le 17 juin 2021 Í 23:42, Olivier Miakinen s'est exprimé en ces termes :
je ne suis même pas très sÍ»r de savoir qui est responsable de l'affichage du glyphe, entre l'application et le système d'exploitation.
Mais pour en revenir Í un lecteur de news, ce serait plutÍ´t le logiciel qui choisit ce qu'il affiche en rencontrant =?UTF-8?Q?é?=, non ?
C'est plus que probable. Voici ce que je lis pour l'article <news: publié sur fr.usenet.divers : - Thunderbird : Re: Question sur la solution "N�mo" - Pan :         Re: Question sur la solution "N?mo" - Claws Mail :  Re: Question sur la solution "N_mo" ces trois lecteurs de news étant installés sur la même machine sous Ubuntu. -- Denis
M.V.
Le 18 juin 2021 Í 09:52, DV s'est exprimé en ces termes :
C'est plus que probable. Voici ce que je lis pour l'article <news: publié sur fr.usenet.divers : - Thunderbird : Re: Question sur la solution "N�mo" - Pan :         Re: Question sur la solution "N?mo" - Claws Mail :  Re: Question sur la solution "N_mo" ces trois lecteurs de news étant installés sur la même machine sous Ubuntu.
Et j'ajouterais (tu me corrigeras si je me trompe) que ces 3 lecteurs affichent sans problème mon �. Maintenant (et j'hésite Í faire suivre la discussion sur fcul-d-n), que devrait afficher un lecteur de news lorsqu'il reçoit le titre du message que tu évoques et dont l'encodage est foireux, et que je retranscris ici : Re: =?UTF-8?Q?Question_sur_la_solut?= =?UTF-8?Q?ion_"Némo"? Le lecteur doit-il s'efforcer de décoder ce qu'il peut comme le font les 3 lecteurs que tu cites (et peu importe le « replacement character » utilisé) ou doit-il se contenter de : Re: Question sur la solut =?UTF-8?Q?ion_"Némo"?(avec espace ou pas entre l'encoded-word correct et celui qui ne l'est pas) ? Allez zou… je mets fcul-d-n en copie avec fu2 -- Michel VAUQUOIS - <http://michelvauquois.fr>
Le 18 juin 2021 Í 09:52, DV s'est exprimé en ces termes :
C'est plus que probable. Voici ce que je lis pour l'article
<news:gdjecg9frl956gpd0602sd8icfoo7emfhe@news.free.fr> publié sur
fr.usenet.divers :
- Thunderbird : Re: Question sur la solution "N�mo"
- Pan :         Re: Question sur la solution "N?mo"
- Claws Mail :  Re: Question sur la solution "N_mo"
ces trois lecteurs de news étant installés sur la même machine sous
Ubuntu.
Et j'ajouterais (tu me corrigeras si je me trompe) que ces 3 lecteurs
affichent sans problème mon �.
Maintenant (et j'hésite Í faire suivre la discussion sur fcul-d-n), que
devrait afficher un lecteur de news lorsqu'il reçoit le titre du message
que tu évoques et dont l'encodage est foireux, et que je retranscris ici :
Re: =?UTF-8?Q?Question_sur_la_solut?= =?UTF-8?Q?ion_"Némo"?
Le lecteur doit-il s'efforcer de décoder ce qu'il peut comme le font les
3 lecteurs que tu cites (et peu importe le « replacement character »
utilisé) ou doit-il se contenter de :
Re: Question sur la solut =?UTF-8?Q?ion_"Némo"?(avec espace ou pas entre l'encoded-word correct et celui qui ne l'est
pas) ?
Allez zou… je mets fcul-d-n en copie avec fu2
--
Michel VAUQUOIS - <http://michelvauquois.fr>
Le 18 juin 2021 Í 09:52, DV s'est exprimé en ces termes :
C'est plus que probable. Voici ce que je lis pour l'article <news: publié sur fr.usenet.divers : - Thunderbird : Re: Question sur la solution "N�mo" - Pan :         Re: Question sur la solution "N?mo" - Claws Mail :  Re: Question sur la solution "N_mo" ces trois lecteurs de news étant installés sur la même machine sous Ubuntu.
Et j'ajouterais (tu me corrigeras si je me trompe) que ces 3 lecteurs affichent sans problème mon �. Maintenant (et j'hésite Í faire suivre la discussion sur fcul-d-n), que devrait afficher un lecteur de news lorsqu'il reçoit le titre du message que tu évoques et dont l'encodage est foireux, et que je retranscris ici : Re: =?UTF-8?Q?Question_sur_la_solut?= =?UTF-8?Q?ion_"Némo"? Le lecteur doit-il s'efforcer de décoder ce qu'il peut comme le font les 3 lecteurs que tu cites (et peu importe le « replacement character » utilisé) ou doit-il se contenter de : Re: Question sur la solut =?UTF-8?Q?ion_"Némo"?(avec espace ou pas entre l'encoded-word correct et celui qui ne l'est pas) ? Allez zou… je mets fcul-d-n en copie avec fu2 -- Michel VAUQUOIS - <http://michelvauquois.fr>
