Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[MacCafé 3.01.1 harrar] Probème d'encodage RFC 2047 en base64

0 views
Skip to first unread message

Olivier Miakinen

unread,
Feb 16, 2024, 5:59:12 PM2/16/24
to
Bonjour,

Avec la toute dernière version de MacCafé il semble y avoir un problème
d'encodage des entêtes dans <news:uqnae6$1ct4v$4...@news.usenet.ovh>.


Le sujet auquel il répondait était correctement encodé, en trois parties :
"Re: =?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZMOpY2hpZmZyw6llIGRlIGzigJnD?="
"=?UTF-8?B?rmxlIGRlIFDDonF1ZXMgcG91cnJhaXQgw6p0cmUgYW50w6lyaWV1cmUgw6AgbGEg?="
"=?UTF-8?B?Y29sb25pc2F0aW9uIGV1cm9ww6llbm5l?="

Décodées, ces trois parties donnent :
"Une écriture non déchiffrée de l’"
"ile de Pâques pourrait être antérieure à la "
"colonisation européenne"


Mais l'article généré par MacCafé a un sujet lui aussi en trois parties :
"=?UTF-8?B?PT9VVEYtOD9CP1ZXNWxJTU9wWTNKcGRIVnlaU0J1YjI0Z1o=?="
"=?UTF-8?B?TU9wWTJocFptWnl3NmxsSUdSbElHemlnSm5EPz1jb2xvbmlzYXRpb24=?="
"=?UTF-8?B?IGV1cm9ww6llbm5l?="

Décodées, ces trois parties donnent :
"=?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZ"
"MOpY2hpZmZyw6llIGRlIGzigJnD?=colonisation"
" européenne"


C'est-à-dire qu'on y retrouve la première ligne *encodée* de l'article
d'origine, collée (sans blanc) à la troisième ligne *décodée" du même
article, La deuxième ligne, elle, a complètement disparu.


Gilbert, j'espère avoir pu t'aider à diagnostiquer le problème pour mieux
le corriger.

--
Olivier Miakinen

Gilbert OLIVIER

unread,
Feb 17, 2024, 3:22:52 AM2/17/24
to
Le 16 février 2024, Olivier Miakinen a écrit :

> Gilbert, j'espère avoir pu t'aider à diagnostiquer le problème pour mieux
> le corriger.
>
Merci Olivier

N'étant pas abonné au groupe de ces messages et personne avant toi
n'ayant remonté le problème……

De mon côté, voilà ce que j'observe:

Dans le 1er message de ce fil
<news 65ce6b23$0$7516$426a...@news.free.fr>
MacCafé décode parfaitement le sujet.

Sujet copié et test sur fr.test
<news:uqpn62$acuv$1...@dont-email.me>
L'encodage semble correct.

Par contre, avec MacCafé le sujet du second message du fil (celui auquel
le message de MacCafé répond)
<news:uqm92c$3hgcf$1...@dont-email.me>
est décodé exactement comme il apparait dans le message de réponse.

Le problème est donc soit dans l'encodage de MesNews, soit dans le
décodage de MacCafé lié à une particularité dans l'encodage de MesNews
qui lui pose problème et qui ne semble pas avoir déjà été rencontré…
En décodant chaque partie du sujet indépendamment, seule la 3ème
retourne un décodage correct.

Voilà ou j'en suis.
Des idées ?

--
Gilbert
<https://maccafe.fr>
Liens vers une liste de serveurs gratuits conseillés pour les groupes fr et de
lecteurs de nouvelles sur la page <https://maccafe.fr/serveurs.html>

DV

unread,
Feb 17, 2024, 4:26:36 AM2/17/24
to
Gilbert OLIVIER a écrit ceci :

> Le problème est donc soit dans l'encodage de MesNews, soit dans le
> décodage de MacCafé lié à une particularité dans l'encodage de MesNews
> qui lui pose problème et qui ne semble pas avoir déjà été rencontré…

Ce que j'observe de mon côté, c'est que MesNews ne parvient pas à
afficher correctement le champ Subject qu'il a lui-même généré :

<https://lutim.lagout.org/RJ4B3fEM/fDditgEz.png>

(Capture d'écran de MesNews sous W10.)

--
Denis

Serveurs de news et passerelles web : <http://usenet-fr.yakakwatik.org>
Lecteurs de news : <http://usenet-fr.yakakwatik.org/lecteurs-de-news.html>

Gilbert OLIVIER

unread,
Feb 17, 2024, 4:55:17 AM2/17/24
to
Le 17 février 2024, M.V. a écrit :

bonjour

> Comme tu réponds ici et que j'ai vu ce qu'il se passait, je réponds
> également ici puisque le problème, maintes fois évoqué dans le passé,
> provient de MesNews qui découpe le sujet encodé à la va-comme-j'te-pousse.

Je répondais ici car analyse faite, il me semblait (et de plus en plus
maintenant) que le problème venait de MesNews.
>
> Si on recolle les 2 premières lignes, le décodage se fait correctement.
>
> Il y a le même problème avec le message
> <news:uqlqkb$3f414$1...@dont-email.me> émanant d'un utilisateur de MesNews
> et que MacCafé ne décode pas car là encore, MesNews a découpé le sujet
> encodé n'importe comment.

Comme indiqué dans la Réponse à Denis, MacCafé traite déjà un autre
problème dans l'encodage de MesNews, mais celui là, je ne vois pas trop
comment le détecter pour le résoudre dans le code.

Gilbert OLIVIER

unread,
Feb 17, 2024, 4:55:18 AM2/17/24
to
Le 17 février 2024, DV a écrit :

> Gilbert OLIVIER a écrit ceci :
>
>> Le problème est donc soit dans l'encodage de MesNews, soit dans le
>> décodage de MacCafé lié à une particularité dans l'encodage de MesNews
>> qui lui pose problème et qui ne semble pas avoir déjà été rencontré…
>
> Ce que j'observe de mon côté, c'est que MesNews ne parvient pas à
> afficher correctement le champ Subject qu'il a lui-même généré :

Alors me voilà rassuré ;-)

En analysant un peu le problème pour voir, j'ai vu qu'un cas
"particulier" des encodages de Mesnews avait été traité spécifiquement
dans le décodage mime.
Là, selon ce que signale Michel, j'ai bien peur de ne pas trouver de
tourne autour…

Cette alerte n'aura cependant pas été inutile, elle m'a fait découvrir
un petit bug cosmétique dans les lecture des "messages en ligne".
>
> <https://lutim.lagout.org/RJ4B3fEM/fDditgEz.png>
>
> (Capture d'écran de MesNews sous W10.)
>

--

Jean-Pierre Kuypers

unread,
Feb 17, 2024, 5:02:53 AM2/17/24
to
In article (Dans l'article) <uqpvq4$bnqg$2...@dont-email.me>, Gilbert
OLIVIER <gibert....@orange.fr.invalid> wrote (écrivait) :

> Cette alerte n'aura cependant pas été inutile, elle m'a fait découvrir
> un petit bug cosmétique dans les lecture des "messages en ligne".

Et Benoit ne l'a pas signalé ?

--
Jean-Pierre Kuypers

yamo'

unread,
Feb 17, 2024, 5:12:08 AM2/17/24
to
Salut,
Gilbert OLIVIER a tapoté :
>
>
> Par contre, avec MacCafé le sujet du second message du fil (celui auquel
> le message de MacCafé répond)
> <news:uqm92c$3hgcf$1...@dont-email.me>
> est décodé exactement comme il apparait dans le message de réponse.

flnews me donne :
/ligne volontairement non coupée/
Sujet: Re: Une écriture non déchiffrée de l’�le de Pâques pourrait être antérieure à la colonisation européenne




--
Stéphane

Olivier Miakinen

unread,
Feb 17, 2024, 5:49:09 AM2/17/24
to
Bonjour,

Ainsi que vous avez été plusieurs à le signaler, le problème vient
initialement de MesNews même s'il y en a quand même un dans MacCafé.

Le 16/02/2024 23:59, Olivier Miakinen a écrit :
>
> "Re: =?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZMOpY2hpZmZyw6llIGRlIGzigJnD?="
> "=?UTF-8?B?rmxlIGRlIFDDonF1ZXMgcG91cnJhaXQgw6p0cmUgYW50w6lyaWV1cmUgw6AgbGEg?="
> "=?UTF-8?B?Y29sb25pc2F0aW9uIGV1cm9ww6llbm5l?="

Cet entête était donc INcorrectement encodé par MesNews. En effet, le
« î » de « île », encodé en UTF-8 par les octets C3 et AE, a son C3 codé
à la fin du premier encoded-word tandis que le AE est dans le début du
deuxième encoded-word. C'est spécifiquement interdit par le RFC2047, et
il est probable que j'aie déjà signalé le problème ici-même (mais je
l'avais oublié, mauvaise mémoire tout ça).

MacCafé a donc bien raison de ne pas décoder les deux mots qui ressemblent
à des encoded-words mais qui n'en sont pas. Le vrai décodage de ce titre
devrait en réalité contenir cinq mots :
1) Re:
2) =?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZMOpY2hpZmZyw6llIGRlIGzigJnD?=
3) =?UTF-8?B?rmxlIGRlIFDDonF1ZXMgcG91cnJhaXQgw6p0cmUgYW50w6lyaWV1cmUgw6AgbGEg?=
4) colonisation
5) européenne

Mais du coup, le titre rendu par MacCafé lors de la réponse n'est pas correct,
d'une part parce que le 3e mot a disparu, et d'autre part parce que le deuxième
mot se retrouve collé au quatrième, chose qui n'est permise (et même obligée)
*que* lorsque ce sont deux vrais encoded-words qui se suivent.

> Mais l'article généré par MacCafé a un sujet lui aussi en trois parties :
> "=?UTF-8?B?PT9VVEYtOD9CP1ZXNWxJTU9wWTNKcGRIVnlaU0J1YjI0Z1o=?="
> "=?UTF-8?B?TU9wWTJocFptWnl3NmxsSUdSbElHemlnSm5EPz1jb2xvbmlzYXRpb24=?="
> "=?UTF-8?B?IGV1cm9ww6llbm5l?="
>
> Décodées, ces trois parties donnent :
> "=?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZ"
> "MOpY2hpZmZyw6llIGRlIGzigJnD?=colonisation"
> " européenne"

Ici, le « gJnD?=colonisation » est bien le collage qui n'aurait pas dû
se produire.



--
Olivier Miakinen

Olivier Miakinen

unread,
Feb 17, 2024, 6:01:23 AM2/17/24
to
[crosspost avec suivi]

Le 17/02/2024 11:25, M.V. a écrit :
>
> [...] le défaut de MesNews ayant été
> plusieurs fois décrit par ledit Olivier, il ne pouvait pas s'agir de
> celui-ci.

Hélas, j'ai réellement des problèmes de mémoire.

> Olivier avait notamment décrit ce défaut de MesNews ici :
> <news:s9dtc9$2ml1$1...@cabale.usenet-fr.net>
> ou bien là :
> <news:t9vigr$ep4$1...@cabale.usenet-fr.net>

Dont acte.

Note que les deux fois j'ai signalé (pour deux raisons différentes) que les
problèmes d'encodage devraient être signalés sur fr.comp.usenet.lecteurs-de-news
plutôt que sur fr.comp.sys.mac.communication. Si vraiment tu veux en parler sur
fcsmc, alors il faudrait au moins en faire un crosspost sur fcul avec suivi
vers ce dernier. En effet, même dans le cas où le bug serait exclusivement sur
MacCafé, ces problèmes d'encodage ont quasi systématiquement des répercussions
sur les autres lecteurs de news.


--
Olivier Miakinen

Eric M

unread,
Feb 17, 2024, 6:01:38 AM2/17/24
to
Le 17/02/2024 à 11:49, Olivier Miakinen a écrit :

> Cet entête était donc INcorrectement encodé par MesNews. En effet, le
> « î » de « île », encodé en UTF-8 par les octets C3 et AE, a son C3 codé
> à la fin du premier encoded-word tandis que le AE est dans le début du
> deuxième encoded-word. C'est spécifiquement interdit par le RFC2047, et
> il est probable que j'aie déjà signalé le problème ici-même (mais je
> l'avais oublié, mauvaise mémoire tout ça).

On voit bien ici tout le problème d'usenet, je doute fortement que Arnaud
(MesNews) lise encore ce forum et corrige spontanément ce bug, même en
lui écrivant un mail c'est pas certain (mais ça se tente ceci dit),
pourtant même avec le bug non corrigé des tas de gens vont continuer à
utiliser MesNews. Si on ne peut pas corriger un bug mineur sur un logiciel
populaire, quelles sont les chances qu'il intègre les NoCem ou les
cancel-lock ?

Eric M

unread,
Feb 17, 2024, 7:10:58 AM2/17/24
to
Le 17/02/2024 à 13:03, "M.V." a écrit :

>> Si on ne peut pas corriger un bug mineur sur un logiciel
>> populaire, quelles sont les chances qu'il intègre les NoCem ou les
>> cancel-lock ?

> Les NoCeMs ne sont pas l'affaire des lecteurs de nouvelles mais des
> gestionnaires des serveurs, si ?

Il me semble que théoriquement chaque personne devrait pouvoir accepter
les NoCems de telle ou telle source. J'ai cru comprendre que de rares
lecteurs sous Linux le permettaient.

> Même chose pour les Cancel-Key/Cancel-Lock : ce sont les serveurs qui
> s'en occupent ou devraient s'en occuper.

Oui, et ceux qui ne le font pas continuent de tourner et d'envoyer et de
recevoir des feeds. Usenet 2 c'est pas pour demain.

Gilbert OLIVIER

unread,
Feb 17, 2024, 10:52:26 AM2/17/24
to
Le 17 février 2024, Olivier Miakinen a écrit :

Bonjour

> Mais du coup, le titre rendu par MacCafé lors de la réponse n'est pas correct,
> d'une part parce que le 3e mot a disparu, et d'autre part parce que le deuxième
> mot se retrouve collé au quatrième, chose qui n'est permise (et même obligée)
> *que* lorsque ce sont deux vrais encoded-words qui se suivent.

Oui, mais non ;-)

Pour MacCafé, ce qu'il encode, c'est la chaine qui est dans le titre
comme il l'a décodée. donc pour lui une suite de caractères ASCII et
s'il encode en UTF-8, c'est parce qu'elle contient le "à" de "à la
colonisation…"

Donc pour l'instant cela reste cela reste un bug de MesNews non
contourné. Je vais voir si je trouve un moyen de rendre cela "moins
pire", mais même ayant compris le problème que tu as très bien décrit,
pour l'instant je n'ai pas trop d'idée pour coder la détection de ce
problème :-(

DV

unread,
Feb 17, 2024, 12:34:20 PM2/17/24
to
M.V. a écrit ceci :

> Il faudrait que MacCafé reconnaisse que ça provient de MesNews,

Cela ne devrait pas être trop difficile, sachant que MesNews s'identifie
au moyen du champ « X-Newsreader: MesNews/[N° de version] », et
qu'apparemment il est impossible de modifier ni de supprimer ce champ
avant l'envoi.

Pour le reste, je passe le micro à Gilbert...

DV

unread,
Feb 17, 2024, 12:49:47 PM2/17/24
to
M.V. a écrit ceci :

> Bien sûr mais ce que je voulais dire, c'est que le bidouillage que je
> suggère (et dont je n'ai aucune idée s'il peut être mis en œuvre) ne
> doit être fait que pour MesNews.

J'avais bien compris. Mais dans ce cas, la première chose à vérifier est
la possibilité d'identifier MesNews à coup sûr. Il se trouve que c'est
facile, alors que ça le serait moins avec d'autres lecteurs de news qui
autorisent l'escamotage du champ User-Agent ou X-Newsreader.

Olivier Miakinen

unread,
Feb 17, 2024, 1:18:11 PM2/17/24
to
Bonjour,

Pour mémoire voici les deux articles en question.

Celui de Jac avec MesNews :
<news:uqm92c$3hgcf$1...@dont-email.me>
<http://al.howardknight.net/?ID=170819270700>

La réponse de Ruprecht avec MacCafé :
<news:uqnae6$1ct4v$4...@news.usenet.ovh>
<http://al.howardknight.net/?ID=170819255700>

Le 17/02/2024 12:14, M.V. a écrit :
> Dans le message <uqq2v3$24ts$1...@cabale.usenet-fr.net>, Olivier Miakinen a écrit le 17 février 2024 à 11 h 49 :
>
>> Cet entête était donc INcorrectement encodé par MesNews. En effet, le
>> « î » de « île », encodé en UTF-8 par les octets C3 et AE, a son C3 codé
>> à la fin du premier encoded-word tandis que le AE est dans le début du
>> deuxième encoded-word. C'est spécifiquement interdit par le RFC2047, et
>> il est probable que j'aie déjà signalé le problème ici-même (mais je
>> l'avais oublié, mauvaise mémoire tout ça).
>
> Oui… au moins deux fois dans fcsmc : voir <news:uqq1jm$c1gk$1...@dont-email.me>
>
>> MacCafé a donc bien raison de ne pas décoder les deux mots qui ressemblent
>> à des encoded-words mais qui n'en sont pas. Le vrai décodage de ce titre
>> devrait en réalité contenir cinq mots :
>> 1) Re:
>> 2) =?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZMOpY2hpZmZyw6llIGRlIGzigJnD?=
>> 3) =?UTF-8?B?rmxlIGRlIFDDonF1ZXMgcG91cnJhaXQgw6p0cmUgYW50w6lyaWV1cmUgw6AgbGEg?=
>> 4) colonisation
>> 5) européenne
>>
>> Mais du coup, le titre rendu par MacCafé lors de la réponse n'est pas correct,
>> d'une part parce que le 3e mot a disparu,
>
> Pas tout à fait : il a traité les deux premiers encoded words en les
> laissant tels quels puisqu'ils sont mal foutus comme le fait mon décodeur
> puis en raboutant les 2 résultats :
> VW5lIMOpY3JpdHVyZSBub24gZMOpY2hpZmZyw6llIGRlIGzigJnDrmxlIGRlIFDDonF1ZXMgcG91cnJhaXQgw6p0cmUgYW50w6lyaWV1cmUgw6AgbGEg

Je ne suis pas d'accord. Dans la réponse faite par Ruprecht avec MacCafé, le
titre une fois décodé ne contient plus que trois mots au lieu de cinq, le
deuxième mot étant la concaténation des 2e et 4e mots de l'article d'origine
avec disparition complète du 3e mot :
1)"Re:"
2)"=?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZMOpY2hpZmZyw6llIGRlIGzigJnD?=colonisation"
3)"européenne"

>> et d'autre part parce que le deuxième
>> mot se retrouve collé au quatrième, chose qui n'est permise (et même obligée)
>> *que* lorsque ce sont deux vrais encoded-words qui se suivent.
>
> Même chose ici : après avoir décodé
> =?UTF-8?B?Y29sb25pc2F0aW9uIGV1cm9ww6llbm5l?=
> MacCafé a collé le résultat à ce qui précède, tout comme le fait mon décodeur.
>
> Quand tu parles de « vrais encoded-words », faudrait alors que MacCafé
> et mon décodeur soient capables de distinguer un encoded-word
> correctement foutu d'un autre mal foutu.

C'est à la fois plus radical et plus simple. Une fois récupéré tous les mots
d'un champ d'entête, le logiciel doit décider pour chaque mot si, selon lui,
c'est ou non un encoded-word MIME. Si c'en est un, alors il le décode, et les
résultats du décodage de deux encoded-words de suite devront être collés. Si
ce n'en est pas un, il ne doit pas être décodé et il ne doit pas être collé
aux éventuels mots qui l'entourent.

Prenons un exemple : =?trucA?= =?trucB?= =?trucC?=

Si on considère que "=?trucA?=" doit se décoder en "A", que "=?trucB?=" doit
se décoder en "B" et que "=?trucC?=" doit se décoder en "C", alors le résultat
doit être "ABC" tout collé.

mais si ni "=?trucA?=" ni "=?trucB?=" ne sont considérés comme des encoded-words
alors le résultat doit être "=?trucA?= =?trucB?= C" et pas "=?trucA?==?trucB?=C"
ni (comme dans le cas présent) "=?trucA?=C".

Or là, il semble que MacCafé ait considéré d'une part que c'étaient des encoded-
words d'où le collage, et d'autre part que ce n'en était pas d'où l'absence de
décodage. L'oubli de celui du milieu est assez curieux dans tout ça, mais après
tout c'est forcément dû au fait que MacCafé est tombé dans un cas non prévu.


--
Olivier Miakinen

Gilbert OLIVIER

unread,
Feb 17, 2024, 1:19:48 PM2/17/24
to
Le 17 février 2024, DV a écrit :

> M.V. a écrit ceci :
>
>> Bien sûr mais ce que je voulais dire, c'est que le bidouillage que je
>> suggère (et dont je n'ai aucune idée s'il peut être mis en œuvre) ne
>> doit être fait que pour MesNews.
>
> J'avais bien compris. Mais dans ce cas, la première chose à vérifier est
> la possibilité d'identifier MesNews à coup sûr. Il se trouve que c'est
> facile, alors que ça le serait moins avec d'autres lecteurs de news qui
> autorisent l'escamotage du champ User-Agent ou X-Newsreader.
>
Identifier MesNnews n'est pas le problème, le tout est de savoir si l'on
ne risque pas de créer plus de problèmes que l'on en résout avec mesnews.

Demain je commence par faire un petit audit dans les messages de la base
postés avec Mesnews pour voir.

Olivier Miakinen

unread,
Feb 17, 2024, 1:34:47 PM2/17/24
to
Le 17/02/2024 16:52, Gilbert OLIVIER a écrit :
> Le 17 février 2024, Olivier Miakinen a écrit :
>
> Bonjour
>
>> Mais du coup, le titre rendu par MacCafé lors de la réponse n'est pas correct,
>> d'une part parce que le 3e mot a disparu, et d'autre part parce que le deuxième
>> mot se retrouve collé au quatrième, chose qui n'est permise (et même obligée)
>> *que* lorsque ce sont deux vrais encoded-words qui se suivent.
>
> Oui, mais non ;-)
>
> Pour MacCafé, ce qu'il encode, c'est la chaine qui est dans le titre
> comme il l'a décodée.

Justement, ce que je critique dans le fonctionnement (enfin... dans ce
que j'en vois d'après la réponse de Ruprecht), ce n'est pas la façon
dont MacCafé réencode le titre mais la façon dont il l'a décodé.

Voir ma réponse précédente. C'est comme si, en recevant :
=?trucA?= =?trucB?= =?trucC?=
et en considérant que les deux premiers ne sont pas corrects, il le
décodait comme :
=?trucA?=(décodage de =?trucC?=) (remarquer l'absence d'espace)
au lieu de :
=?trucA?= =?trucB?= (décodage de =?trucC?=)

> donc pour lui une suite de caractères ASCII et
> s'il encode en UTF-8, c'est parce qu'elle contient le "à" de "à la
> colonisation…"

Oui, pas de problème pour le réencodage.

> Donc pour l'instant cela reste cela reste un bug de MesNews non
> contourné.

Pas seulement.

> Je vais voir si je trouve un moyen de rendre cela "moins
> pire", mais même ayant compris le problème que tu as très bien décrit,
> pour l'instant je n'ai pas trop d'idée pour coder la détection de ce
> problème :-(

Un contournement très simple existe. Si des encoded-words qui se suivent
ont exactement le même charset (par exemple UTF-8) et le même type d'encodage
(soit Q soit B), alors tu transformes :
=?charset?x?(trucA)?= =?charset?x?(trucB)?= =?charset?x?(trucC)?=
en :
=?charset?x?(trucA)(trucB)(trucC)?=
puis c'est ça que tu décodes.


... (réflexion) ...

Ah, petit bémol avant de faire ça, si l'encodage est B et qu'une chaîne se
termine par un "=" avant "?=" (en d'autres termes si elle finit par "=?=")
alors il ne faut pas la fusionner avec la chaîne suivante. C'est seulement
si elle se termine par un autre caractère que "=", donc une lettre ou un
chiffre, que d'une part le bug est peut-être là et que d'autre part ça
n'introduira pas de bug de fusionner.

--
Olivier Miakinen

Olivier Miakinen

unread,
Feb 17, 2024, 1:41:00 PM2/17/24
to
Le 17/02/2024 18:03, M.V. a écrit :
> Dans le message <uqqknp$fpt9$1...@dont-email.me>, Gilbert OLIVIER a écrit le 17 février 2024 à 16 h 52 :
>
>> Donc pour l'instant cela reste cela reste un bug de MesNews non
>> contourné. Je vais voir si je trouve un moyen de rendre cela "moins
>> pire", mais même ayant compris le problème que tu as très bien décrit,
>> pour l'instant je n'ai pas trop d'idée pour coder la détection de ce
>> problème
>
> Je reprends les deux premières lignes qui ont fait problème :
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> Re: =?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZMOpY2hpZmZyw6llIGRlIGzigJnD?=
> =?UTF-8?B?rmxlIGRlIFDDonF1ZXMgcG91cnJhaXQgw6p0cmUgYW50w6lyaWV1cmUgw6AgbGEg?=
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
>
> Si je ne me trompe pas, MacCafé décode la 1ère ligne mais la laisse
> telle quelle (en enlevant les marques d'encodage en début et fin
> de ligne)

Non, ça c'était ce que faisait MesNews 1.08.03 avec le quoted-printable
en minuscules, et à l'époque Arnaud avait corrigé en 1.08.06. ;-)

> Il faudrait que MacCafé reconnaisse que ça provient de MesNews,
> puis supprime la marque d'encodage de la fin de la 1ère ligne
> puis la marque d'encodage de début de la 2ème ligne et recolle les 2
> morceaux sans espace pour obtenir :
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> Re: =?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZMOpY2hpZmZyw6llIGRlIGzigJnDrmxlIGRlIFDDonF1ZXMgcG91cnJhaXQgw6p0cmUgYW50w6lyaWV1cmUgw6AgbGEg?=
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> avant de le décoder en :
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> Re: Une écriture non déchiffrée de l’île de Pâques pourrait être antérieure à la
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Oui, je suis d'accord. Mais plutôt que de reconnaître que ça provient de
MesNews, il suffit que le 1er encoded-word ne se termine pas par "=?=". D'abord
ce sera plus général (parce que d'autres logiciels que MesNews pourraient
avoir le même bug) et surtout c'est moins dangereux (pour le cas où MesNews
corrigerait et génèrerait donc des encoded-words de suite avec des « = »
à la fin d'un base64 qui n'est pas le dernier).



--
Olivier Miakinen

Olivier Miakinen

unread,
Feb 17, 2024, 2:23:03 PM2/17/24
to
Le 17/02/2024 20:00, M.V. a écrit :
>
>> Ah, petit bémol avant de faire ça, si l'encodage est B et qu'une chaîne se
>> termine par un "=" avant "?=" (en d'autres termes si elle finit par "=?=")
>> alors il ne faut pas la fusionner avec la chaîne suivante.
>
> Tu as raison mais est-ce que ça risque d'arriver avec un sujet encodé
> par MesNews,

Qui peut le savoir ?

> parce que c'est de MesNews dont on parle ?

Il s'est trouvé que le bug a été identifié sur un article de MesNews.

Mais cette façon de procéder (tout encoder en base64 puis couper aux
longueurs requises) semble à la fois tellement logique et tellement
facile à coder que je parierais bien qu'on pourrait la rencontrer dans
d'autres nouvelleurs. Ne serait-ce que sur les téléphones portables.

C'est pour ça que, plutôt qu'identifier un coupable et de faire un
contournement d'après son identité, il vaut mieux identifier dans quelles
conditions le bug, s'il existe, peut être contourné sans risque. Et ces
conditions sont :

- même charset (par exemple UTF-8, mais ça concerne tout charset qui
ne soit pas mono-octet)
- même encodage (donc Q ou B)
- que la première des deux chaînes ne se termine pas par un « = » si
l'encodage est « B ».

Noter que le fait de tester l'encodage B pour la troisième condition
pourrait éventuellement être nécessaire, pour le cas où un nouvelleur
couperait au milieu d'un « =C3=AE » en encodage quoted-printable.


--
Olivier Miakinen

Gilbert OLIVIER

unread,
Feb 18, 2024, 5:23:42 AM2/18/24
to
Le 17 février 2024, Olivier Miakinen a écrit :

Bonjour Olivier

Un grand merci de toutes tes explication qui sont une aide précieuse.

> Un contournement très simple existe. Si des encoded-words qui se suivent
> ont exactement le même charset (par exemple UTF-8) et le même type d'encodage
> (soit Q soit B), alors tu transformes :
> =?charset?x?(trucA)?= =?charset?x?(trucB)?= =?charset?x?(trucC)?=
> en :
> =?charset?x?(trucA)(trucB)(trucC)?=
> puis c'est ça que tu décodes.
>
>
> ... (réflexion) ...
>
> Ah, petit bémol avant de faire ça, si l'encodage est B et qu'une chaîne se
> termine par un "=" avant "?=" (en d'autres termes si elle finit par "=?=")
> alors il ne faut pas la fusionner avec la chaîne suivante. C'est seulement
> si elle se termine par un autre caractère que "=", donc une lettre ou un
> chiffre, que d'une part le bug est peut-être là et que d'autre part ça
> n'introduira pas de bug de fusionner.

Donc grâce à ce qui précède, mise au point d'un code générique (quel que
soit l'appli de nouvelles tu as bien fait de dire de ne pas se limiter à
MesNews, MicroPlanet-Gravity souffre du même problème, tant pour un
codage "binary" que "quoted printable"

le preuve en image ;-)
<https://www.cjoint.com/doc/24_02/NBskkftZt00_Decodage.png>

messages:
<news:uqm92c$3hgcf$1...@dont-email.me>
<news:MPG.403b670c5...@news.individual.net>

Olivier Miakinen

unread,
Feb 18, 2024, 5:29:27 AM2/18/24
to
Le 18/02/2024 09:43, M.V. a écrit :
>
>>> parce que c'est de MesNews dont on parle ?
>>
>> Il s'est trouvé que le bug a été identifié sur un article de MesNews.
>
> Le bug a été identifié dans Gravity !…
> Voir : <news:uqsftp$v9lu$1...@dont-email.me>

Merci de la confirmation. Et ce bug est bien présent aussi en quoted-printable,
même si la coupure ne va pas jusqu’à se faire au milieu d'un « =NN » mais entre
« =E2=80 » et « =99 » (encodage de l’apostrophe « ’ »).

--
Olivier Miakinen

Olivier Miakinen

unread,
Feb 18, 2024, 5:33:01 AM2/18/24
to
Le 18/02/2024 11:23, Gilbert OLIVIER a écrit :
>
> Donc grâce à ce qui précède, mise au point d'un code générique (quel que
> soit l'appli de nouvelles tu as bien fait de dire de ne pas se limiter à
> MesNews, MicroPlanet-Gravity souffre du même problème, tant pour un
> codage "binary" que "quoted printable"
>
> le preuve en image ;-)
> <https://www.cjoint.com/doc/24_02/NBskkftZt00_Decodage.png>

Bravo, et merci !

--
Olivier Miakinen

DV

unread,
Feb 18, 2024, 9:25:31 AM2/18/24
to
M.V. a écrit ceci :

> Tu pourras vérifier sur ce message <news:uqrdim$kskc$1...@dont-email.me>
> émis avec MesNews qu'il n'y a pas de problème ?
>
> La mise bout à bout des encoded-words donne un résultat différent des autres :
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> Re: =?UTF-8?B?VW5lIMOpY3JpdHVyZSBub24gZMOpY2hpZmZyw6llIGRlIGzigJnDgD9Qw6JxdWVzIHBvdXJyYWl0IMOqdHJlIGFudMOpcmlldXJlIMOgIGxhIGNvbG9uaXNhdGlvbiBldXJvcMOpZW5uZQ==?=
> →
> Re: Une écriture non déchiffrée de l’À?Pâques pourrait être antérieure à la colonisation européenne
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Cela correspond exactement à ce que MesNews lui-même affiche pour ce
message, tout comme pour le message à l'origine de cette discussion. Cf.
la capture d'écran de MesNews que j'avais déjà publiée :

<<https://lutim.lagout.org/RJ4B3fEM/fDditgEz.png>

Gilbert OLIVIER

unread,
Feb 18, 2024, 12:18:59 PM2/18/24
to
Le 18 février 2024, M.V. a écrit :

> Tu pourras vérifier sur ce message <news:uqrdim$kskc$1...@dont-email.me>
> émis avec MesNews qu'il n'y a pas de problème ?
>
C'est décodé exactement comme dans ton message.

C'est normal puisque MacCafé fait ce que tu as fais "à la main".

Maintenant que veut-il vraiment dire en écrivant:
> EDIT : c'est après que ça se gâte.

A noter qu'il à fait un supersedes, comment mesnews gère-t-il l'encodage
du sujet dans cette opération…

Je trouve le message remplacé sur CSIPH et aucun problème avec le
décodage du sujet. De là à penser que mesnews s'est marché sur les pieds
dans la manip comme il n'arrive pas à lire son encodage (cf essai de
Denis)…
0 new messages