MailMessage getPreferredTextEncoding does not take the java file.encoding value

[Shyama]

There are 2 issues on which I need more clarity.

1. When trying to load a .msg file (Unicode) in a simplified Chinese windows OS I get a error message saying

java.lang.IllegalArgumentException: ‘GBK’ is not a supported encoding

at com.aspose.email.private.e.d.b(Unknown Source)

at com.aspose.email.private.e.d.(Unknown Source)

2. Even on changing the java’s default file encoding by setting -Dfile.encoding to something other than GBK, say “GB18030”, on saving to mht format I see the mail headers show ‘?’ instead of chinese characters.

Attaching the code and the message file with which I tried. Please note this issue is reproducible when the OS locale is simplified Chinese.

[SHMalik]

Hi Shyama,

First of all my sincere apologies for late reply.

Shyama:

There are 2 issues on which I need more clarity.
1. When trying to load a .msg file (Unicode) in a simplified Chinese windows OS I get a error message saying
java.lang.IllegalArgumentException: 'GBK' is not a supported encoding
at com.aspose.email.private.e.d.b(Unknown Source)
at com.aspose.email.private.e.d.(Unknown Source)

I have tried to re-produce this error here by installing Chinese language pack and then switched my OS to use the Chinese Language. I tried your code, but no error was produced and complete code was executed successfully.

I will further discuss this issue with experts and try to re-produce the issue here. Whatever the outcome will be, I will share with you.

Shyama:

2. Even on changing the java's default file encoding by setting -Dfile.encoding to something other than GBK, say "GB18030", on saving to mht format I see the mail headers show '?' instead of chinese characters.

Attaching the code and the message file with which I tried. Please note this issue is reproducible when the OS locale is simplified Chinese.

This issue was re-generated successfully and I have logged a ticket NETWRKJAVA-33153 in our bug tracking system. As soon some feedback is received from development team, it will be notified to you immediately.

Best Regards

[SHMalik]

Hi Shyama,

Thank you very much for your patience.

Shyama:

1. When trying to load a .msg file (Unicode) in a simplified Chinese windows OS I get a error message saying
java.lang.IllegalArgumentException: ‘GBK’ is not a supported encoding
at com.aspose.email.private.e.d.b(Unknown Source)
at com.aspose.email.private.e.d.(Unknown Source)

I have tried to re-produce this exception but still not able to re-produce it while running the code. However I get exception on command window when I give the following command:

> java -Dfile.encoding = GBK

Error occurred during initialization of VM
java.nio.charset.IllegalCharsetNameException:
at java.nio.charset.Charset.checkName(Unknown Source)
at java.nio.charset.Charset.lookup2(Unknown Source)
at java.nio.charset.Charset.lookup(Unknown Source)
at java.nio.charset.Charset.defaultCharset(Unknown Source)
at sun.nio.cs.StreamEncoder.forOutputStreamWriter(Unknown Source)
at java.io.OutputStreamWriter.(Unknown Source)
at java.io.PrintStream.(Unknown Source)
at java.io.PrintStream.(Unknown Source)
at java.lang.System.initializeSystemClass(Unknown Source)

However this exception is different from that pointed out by you.

In addition to above commands at command prompt, I also added following lines of code at the start of sample code sent by you.

System.setProperty("file.encoding", "GBK");
Locale aLocale = Locale.SIMPLIFIED_CHINESE;

And finally I installed Chinese (Simplified, PRC) language pack and converted my system to this.

None of the above efforts caused the exception to raise in the code. I request you to help by reviewing above comments and provide me steps to re-produce this issue at my end.

Just for your information that re-producing the issue is must required for raising ticket in our bug tracking system.

Thanks in advance.

Best Regards

[Shyama]

Hi Malik,

Thank you for the response. With respect to the error,

java.lang.IllegalArgumentException: ‘GBK’ is not a supported encoding
at com.aspose.email.private.e.d.b(Unknown Source)
at com.aspose.email.private.e.d.(Unknown Source)

We see that only in Chinese windows OS. The java version used is “1.6.0_31” . Hope this helps. Please let me know what other information would help you.

One other question is does Aspose.Email require specific fonts to be installed to render Japanese or Chinese chracters when converting email to pdf?

[babar.raza]

Hi Shyama,

Thank you for sharing more information. I have recorded your comments to the ticket (NETWRKJAVA-33164) associated with your request. If the development team require more information, I will let you know.

Regarding your other inquiry, I do not think some specific font is required to convert email messages having Japanese or Chinese characters to Mhtml. To produce the final Pdf file, Aspose.Words load the Mhtml and converts it to Pdf format. You may require to contact Aspose.Words forum in order to get their opinion in this regard.

Anyhow, I will confirm this from Aspose.Email development team too and will update you with my findings.

Regards,

[Shyama]

Hi Babar,

I see if unicode font like ‘Arial Unicode’ is not installed in the machine the mhtml does not render multibyte characters in the body of the mail. The problem seems to be in Aspose.email itself.

[babar.raza]

Hi Shyama,

Thank you for bringing this to our knowledge.

We are currently looking into this matter. If found to be valid, we will log an appropriate ticket to handle the said problem in Aspose.Email for Java component. We will keep you posted with updates on this.

Regards,

[babar.raza]

Hi,

Thank you for your patience.

I have logged an investigative ticket in our bug tracking system to look further in your recently posted issue. The ticket Id for your reference is NETWRKJAVA-33169. As soon as we have completed the analysis, we will report back with results.

Regards,

[aspose.notifier]

The issues you have found earlier (filed as NETWRKJAVA-33153;NETWRKJAVA-33164) have been fixed in this update.

---

This message was posted using Notification2Forum from Downloads module by aspose.notifier.

[Shyama]

Hi ,

I see that NETWRKJAVA-33169 is marked as not a bug. Can you please let us know the reason?

Would this mean that “Arial Unicode MS” has to be installed ? I see that installing other unicode fonts like code2000 or gnu unifont did not help.Can you please throw some light on usage of fonts in aspose?

[babar.raza]

Hi Shyama,

We have closed the ticket logged earlier as NETWRKJAVA-33169, because the said behavior is not a bug of Aspose.Email for Java component. Please note, Aspose.Email for Java can render multibyte characters regardless of any font.

Below is the sample code and attached is the output for your reference,

Java

@Test(description = "Multibyte character problem ")
public void NETWRKJAVA_33169() {
String fileName = Path.combine(Path.getTempPath(), “NETWRKJAVA_33169_output.mhtml”);
String body = “コンピュータ”;

MailMessage message = new MailMessage();
message.setHtmlBody(body);
Assert.assertTrue(message.getHtmlBody().contains(body));
message.save(fileName, MailMessageSaveType.getMHtmlFromat());
MailMessage loadedMessage = MailMessage.load(fileName);
Assert.assertTrue(loadedMessage.getHtmlBody().contains(body));
}

In very rare cases, such as of Appointment.getAppointmentHtml() method, some specified fonts are required and their references are added to the resultant Html. Below is an example of font reference in output,

Regards,

[Shyama]

I would want to reopen NETWRKJAVA-33153 as the header content has one character which is still corrupted.

Attaching the input mail and screenshot.

[kashif.iqbal]

Hi Shyama,

Thank you for using Aspose.Email and we are sorry for the inconvenience you have faced.

I tested your provided new sample file with Aspose.Email for Java v2.0.0 and could observe the issue as you have mentioned. I have reopened the ticket with ID: NETWRKJAVA-33153 for our development team to look into this new sample file and provide further assistance. We will update you here once we have any information from our development team in this regard.

Your patience towards the resolution of this issue is highly appreciated.