I am using the 2025-11 version or Aspose Java Email.
I am using it to convert an MSG message to an EML.
The conversion works but it has a problem with the header “Sender”.
The sender in this case contains the character “š” and in the EML, opened as a plain-text file, I see that the character “š” is not encoded. I would expect it to be encoded with a “?UTF-8?Q?”, like it is for the “From:” header, while for the “Sender:” header it is not.
I am wondering if it is correct or if it needs to be encoded also there.
The code for the conversion is:
MailMessage message = MailMessage.load(new ByteArrayInputStream(msg), new MsgLoadOptions());
ByteArrayOutputStream out = new ByteArrayOutputStream();
EmlSaveOptions saveOptions = SaveOptions.getDefaultEml();
saveOptions.setPreserveSignedContent(true);
message.save(out, saveOptions);
return out.toByteArray();
I did not upload the MSG file for privacy reasons, it should be relatively easy to reproduce the issue, though
Is the “Sender” header containing the special character “š” set directly in the original MSG file, or is it added/modified programmatically during the conversion process?
Does the same issue occur with other special Unicode characters, or is it specific to “š”?
Have you compared the original MSG file’s Sender header encoding with the resulting EML file to confirm the character is unencoded in the output?
Can you confirm whether the From header and Sender header in the original MSG both contain non-ASCII characters, and only the Sender fails to encode?
Thank you for the detailed description and the code snippet.
We would be able to investigate this behavior much faster and more accurately if you could provide the original MSG file.
This would allow us to verify the original encoding used in the message, check what data is stored in the MAPI property PR_TRANSPORT_MESSAGE_HEADERS and understand whether the Sender header is already present in an unencoded form in the source message or if the issue is introduced during the conversion to EML.
Please don’t worry about data confidentiality: all files uploaded to the forum are accessible only to you and Aspose staff involved in investigating the issue. Other forum users don’t have access to uploaded files.
If sharing the original file isn’t possible, you may also consider providing a modified MSG file (with sensitive data removed or replaced) that still allows us to reproduce the issue with the š character.
The š character is already correctly encoded in both From and Sender.
=?iso-8859-2?Q?Pippo_Te=B9ic?=
This is RFC 2047 Q-encoding (quoted-printable).
In ISO-8859-2, byte =B9 represents the character š, so:
Te=B9ic → Tešic
So both headers are already properly encoded.
Сould you please double-check the EML sample? In the snippet you posted, the From and Sender headers are identical and both are encoded the same way, so there doesn’t seem to be any difference between them in this example.
The headers I sent you are the headers read from the original MSG file.
After conversion to EML, the Sender is not UTF8 encoded (-> the š character is exactly as it is, no ?UTF-8?Q)
Based on the information provided so far, we are unable to reproduce the reported issue. In order to proceed with the analysis, we need additional technical details.
We understand that, due to confidentiality reasons, you may not be able to share the complete MSG file. In this case, please run the code below. It will output all MAPI properties of the message in a textual form:
string values will be printed as text
binary values will be shown in hexadecimal format
This will allow us to analyze the headers and encoding without accessing the original message content.
MapiMessage msg = MapiMessage.load("issued.msg");
for (KeyValuePair<Long, MapiProperty> p : msg.getProperties()) {
System.out.println(p.getValue().getDescriptor() + " Value:" + p.getValue().toString());
}
Please review the output carefully and remove or mask any confidential information before sharing it with us.
Once you provide this output, we will be able to continue investigating the issue.
Please review the output carefully and remove or mask any confidential information before sharing it with us.