[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44307: 27.1; UTF-8 parts transferred as 8bit in multipart messages f
From: |
Alexandre Duret-Lutz |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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
- bug#44307: 27.1; UTF-8 parts transferred as 8bit in multipart messages fail to decode,
Alexandre Duret-Lutz <=