After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 206422 - chars with 8th bit set in header fields (from, subject, etc) are converted to underscores
chars with 8th bit set in header fields (from, subject, etc) are converted to...
Status: RESOLVED DUPLICATE of bug 201993
Product: evolution
Classification: Applications
Component: Mailer
pre-1.5 (obsolete)
Other All
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2001-08-05 13:21 UTC by Vlad
Modified: 2013-09-10 13:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vlad 2001-08-05 13:21:37 UTC
Characters with 8th bit set in header fields (From, Subject) are converted to underscores.
It's fatal feature in Evo. Yes, RFC prohibbits this, but AFAIK majority of mail with 8bit headers
is being sent by OutLook express. Of course this makes headers (most importantly subject) unreadable.
Use value of mail's charset from Content-Type header to interpret these characters.
Please fix it ASAP!
Comment 1 Jeffrey Stedfast 2001-08-06 16:04:56 UTC
the problem is that there's no way to get the Content-Type header (in
fact, god only knows if it even exists) easily while parsing the
headers since each header knows nothing about previously parsed
headers (or, heaven forbid) headers yet-to-be parsed.

Now, what I *have* done is to make Evolution use the user's locale
charset if it finds the header to contain 8-bit text without being
properly encoded. I'm not sure what else I can do...
Comment 2 Vlad 2001-08-06 16:59:48 UTC
Thanks for trying to fix this bug.
Unfortunately the fix you made doesn't  fix things for a lot of nations
which use different charsets under unix and under windows (japanese and
russians included). So the subject:and From: will be unreadable as
before..
The only way to fix this bug is not to parse headers one by one in
sequence, but first to peek value of Content-Type header, extract
charset, and then parse each of the headers. Even a simple hack would be
fine if you don't want to redesign headers parsing approach.
Or the encoder that will convert all header's value on arrival to
quoted-printable (Evo displays headers with quoted-printable in them
just fine).
This bug is extremely important, and with it Evo will be unusable for
a lot of people.
A lot of other popular MUAs show 8bit chars in headers just fine, using
value of content-type header. So the Evo is just an exception unfortunately.
Comment 3 Jeffrey Stedfast 2001-08-06 23:31:53 UTC

*** This bug has been marked as a duplicate of 201993 ***