Describe the bug
MimeUtility.decodeText() incorrectly decodes base64/utf8 atttachment file name divided into two parts.
Example:
Content-Type: application/octet-stream;
name="=?utf-8?B?MV90b18xX2NoYXRfMjE5ODMxMjRfMTkwMzIwMjRf5p2O55SzX+Wwj+ax?=
=?utf-8?B?h+axh0nlj7fmnLouanNvbg==?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment*/
To Reproduce
Steps to reproduce the behavior:
- Execute: MimeUtility.decodeText("=?utf-8?B?MV90b18xX2NoYXRfMjE5ODMxMjRfMTkwMzIwMjRf5p2O55SzX+Wwj+ax?= =?utf-8?B?h+axh0nlj7fmnLouanNvbg==?=");
Expected behavior
Decoded result: "1_to_1_chat_21983124_19032024_李申_小汇汇I号机.json" (according to any mail client)
Actual Behaviour
Decoded result: "1_to_1_chat_21983124_19032024_李申_小��汇I号机.json"
(Hieroglyph 汇 decoded as ��)
If to concatinate two parts of encoded name in advance we receive correct value. It seems that MimeUtility should concatinate encoded parts first and only after that to decode them.
MimeUtility.decodeText("=?utf-8?B?MV90b18xX2NoYXRfMjE5ODMxMjRfMTkwMzIwMjRf5p2O55SzX+Wwj+axh+axh0nlj7fmnLouanNvbg==?=");
jakarta.mail-api:2.1.3