GNU bug report logs - #44307
27.1; UTF-8 parts transferred as 8bit in multipart messages fail to decode

Previous Next

Full log

View this message in rfc822 format

From: Alexandre Duret-Lutz <adl <at> lrde.epita.fr>
To: 44307 <at> debbugs.gnu.org
Subject: bug#44307: 27.1; UTF-8 parts transferred as 8bit in multipart messages fail to decode
Date: Sat, 02 Jan 2021 21:26:30 +0100

Hi,

I'm back to using Gnus after a 15-year hiatus, and this is the first
issue I've noticed in several emails.

I am able to reproduce it with "emacs -Q" (version 27.1 from Debian) as
follows:

1. manually copy the uuencoded mail from
   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44307#5
   in example.uu
2. sed -i 's/ <at> /@/g' example.uu
3. uudecode example.uu
4. emacs -Q
5. M-x gnus        (ignoring any error)
6. G f example.eml
7. press RET on nndoc+/path/to/example.eml:example.eml
8. press RET on top-level message "<* alternative> text"

Doing so renders the html part by default, but displays "dddd" instead
of "ääää".

Clicking inside this message on the "Attachement: [2. text/plain]"
button inserts "\344\344\344\344".   I.e., that's
the Latin-1 version of "ääää".  (M-x describe-char on these say that they
are "not encodable by coding system utf-8-unix")

Typing "C latin-1" on the "[2. text/plain]" button 
displays the characters correctly.

Typing "C-u g" to display the raw article shows the utf-8 encoded
characters as \303\244\303\244\303\244\303\244.

So my understanding is that the mime parts, which are utf-8 encoded,
get somehow converted to latin-1 before being displayed as utf-8.

-- 
Alexandre Duret-Lutz

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.