Path: ...!goblin2!goblin3!goblin.stu.neva.ru!news.gegeweb.eu!gegeweb.org!usenet-fr.net!.POSTED!not-for-mail From: Olivier Miakinen Newsgroups: fr.comp.applications.emacs Subject: Re: Configuration Gnus Date: Mon, 25 Jan 2021 12:46:19 +0100 Organization: There's no cabale Lines: 25 Message-ID: References: <6009c3a4$0$21606$426a34cc@news.free.fr> <877do4kjq3.fsf@maine-ocean.rail.eu.org> <3h40eh-54.ln1@srvbsdfenssv.interne.associated-bears.org> NNTP-Posting-Host: 220.12.205.77.rev.sfr.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Trace: cabale.usenet-fr.net 1611575180 42925 77.205.12.220 (25 Jan 2021 11:46:20 GMT) X-Complaints-To: abuse@usenet-fr.net NNTP-Posting-Date: Mon, 25 Jan 2021 11:46:20 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 In-Reply-To: Bytes: 2636 Le 24/01/2021 16:16, Eric Masson a cité puis écrit : > > [...] > >>> From: =?utf-8?Q?=C9ric?= Masson >>> Organization: =?utf-8?Q?M=E9ritoire?= > > Il semble donc que rfc2047-encode-message-header ne détecte pas > correctement l'encodage des headers et annonce donc un charset différent > de celui dans lequel les caractères 8 bits sont encodés. Ce qui me semble le plus curieux, c'est que la génération d'un « encoded-word » MIME doit être faite par une seule fonction, qui fait à la fois l'encodage selon un charset donné et la déclaration dudit charset. Je ne vois pas comment une telle fonction pourrait untiliser Latin1 pour l'un et UTF-8 pour l'autre. Ou alors, c'est que cette fonction « croit » que la chaîne est déjà en UTF-8, qui est le charset qu'elle annonce. Du coup, ce comportement pourrait dépendre de paramètres extérieurs, par exemple un paramètre LANG non-UTF-8 utilisé par l'éditeur de texte, tandis qu'un paramètre interne à Gnus lui dirait qu'on est en UTF-8. -- Olivier Miakinen