x-windows-949 codepage is not decoded

UNCONFIRMED
Unassigned

Status

Thunderbird
Untriaged
UNCONFIRMED
4 years ago
4 years ago

People

(Reporter: Andrey Belevantsev, Unassigned)

Tracking

24 Branch
x86_64
Windows 7

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20131209204824

Steps to reproduce:

An email comes from my colleague which is a forwarded email with some addition at the top in Russian. The forwarded email is in turn forwarded from an email with Korean codepage.  This resulted in coding From: and To: field with x-windows-949 as well as the Russian addition over the forwarded email.  The From: and To: fields also have Russian names and last names. The client that sent the message was Thunderbird 3.1.20.

Here are the relevant headers I can disclose:

From: =?x-windows-949?B?rKWs0azirO6s8SCsv6zprNqs36zR?=
 <kontarez@ispras.ru>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: =?x-windows-949?B?rKKs1qzdrNas06zRrN+s6KzWrNMgrKGs36zVrOKs1qzbIKyhrN+s1Q==?=
 =?x-windows-949?B?rOKs1qzWrNOs2qzp?= <abel@ispras.ru>
Subject: Fwd: FW: Request for invoice
Content-Type: multipart/alternative;
 boundary="------------020700000606070207080905"
<A bunch of X-headers of Kaspersky anti-spam filters>

This is a multi-part message in MIME format.
--------------020700000606070207080905
Content-Type: text/plain; charset=x-windows-949
Content-Transfer-Encoding: 8bit

•Šˆ ‡ˆ <Russian text follows, that's an excerpt of what I see in the source window>


Actual results:

The names were not decoded by my Thunderbird version 24.2.0 as well as the Russian text but were left as in the base64 encoding.  The text is left as garbage.


Expected results:

Actually I would not expect this to happen correctly but I observe that the same email is decoded correctly by Alpine 2.0 (i.e. Russian names and text are printed correctly even if encoded with x-windows-949). Thus I assume that TB 3.1.20 is not at fault but rather the problem is with decoding on my side (TB 24.2.0).
You need to log in before you can comment on or make changes to this bug.