Hi,
Aspose.Email.Pop3.Pop3Client does not work correctly with the name of attached files in alternative codepage.
For example, if the email contains the attached file with the name (with russian letters) “прекрасный документ с русскими буквами (2).txt” after processing by Pop3Client client, the extracted name will be: “„Ѓ„‚„u„{„‚„p„ѓ„~„Ќ��z „t„Ђ„{„…„}„u„~„„ „�� „‚„…„ѓ„ѓ„{„y„}„y „q„…„{„r„p„}„y (2).txt"
for that case the propery of the Aspose.Email.Mail.Attachment.ContentType:
application/octet-stream; name=”
=?utf-8?B?4oCe0IPigJ7igJrigJ514oCee+KAnuKAmuKAnnDigJ7Rk+KAnn7igJ7QjOKA?=
=?utf-8?B?nnog4oCedOKAntCC4oCee+KAnuKApuKAnn3igJ514oCefuKAnuKAniDigJ7R?=
=?utf-8?B?kyDigJ7igJrigJ7igKbigJ7Rk+KAntGT4oCee+KAnnnigJ594oCeeSDigJ5x?=
=?utf-8?B?4oCe4oCm4oCee+KAnnLigJ5w4oCefeKAnnkgKDIpLnR4dA==?="
But in case the attached file will have the name with english chars only, it will be processed correctly:
for the name of file - “Log.cs” the propery of Aspose.Email.Mail.Attachment.ContentType:
application/octet-stream; name=Log.cs
Could you fix the issue?
PS
It appears in all versions of Aspose.Email.dll (1.0.0 - 1.5.0)
Hi,
Hi,
no problem with simple mail but now, at first step, i would like just describe the situation in which the issue appears.
1) set the setting of POP3 server to TNEF format.
2) create the email with international letters + embedded picture + 3 attachents (2 with international letters and 1 with english letters only(!)) + use in the subject the international letters.
3) using outlook send the email as "Rich text"
4) read the email using Pop3Client client.
As result, after calling the method FetchMessage(xxxxxx) you will have broken name of attachments.
Next, after saving the MailMessage object into msg format, you will have the broken subject, the names of attachmets (for the one which had international letters in its name).
More other…
after the saving email into msg format, the place of the attachments will be wrong!
I would like to add one important info:
in case of creating the email as described above but with 2 attached files with internatinal files only!!! the processing was changed: the pop3 client read the emails from the server with correct name of attachments!!! but store it into the msg format with big count of errors (unread international letters in subject and the names of attachments).
Hi,
I have tested your latest version of Aspose.Email.dll v1.6.0
No progress with that issue at all. Big problems with international letters are still presented.
Please, see the example of emails with issue in the attachment.
Two messages: original and processed by pop3 client class.
the second one contains a dozen issues which was described above.
Please, fix it +)
Thank you in advance!
Hi,
Hi,
message.Save(str_filename, MailMessageSaveType.OutlookMessageFormatUnicode);
Hi!
After saving the message using your code (message.Save(str_filename, MailMessageSaveType.OutlookMessageFormatUnicode))
the subject appears in correct codepage. Thank you.
But the names of the attachments still have the issues.
See the picture for the details
Please, take your look on the picture.
I am trying to decode ContentType of the attachment using standard approach:
Encoding.GetEncoding(932).GetString(Convert.FromBase64String(“4oCe0IPigJ7igJrigJ514oCee+KAnuKAmuKAnnDigJ7Rk+KAnn7igJ7QjOKAnnog4oCedOKAntCC4oCee+KAnuKApuKAnn3igJ514oCefuKAnuKAniDigJ7RkyDigJ7igJrigJ7igKbigJ7Rk+KAntGT4oCee+KAnnnigJ594oCeeSDigJ5x4oCe4oCm4oCee+KAnnLigJ5w4oCefeKAnnkgKDIpLnR4dA==”))
Encoding.GetEncoding(“Shift-JIS”).GetString(Convert.FromBase64String(“4oCe0IPigJ7igJrigJ514oCee+KAnuKAmuKAnnDigJ7Rk+KAnn7igJ7QjOKAnnog4oCedOKAntCC4oCee+KAnuKApuKAnn3igJ514oCefuKAnuKAniDigJ7RkyDigJ7igJrigJ7igKbigJ7Rk+KAntGT4oCee+KAnnnigJ594oCeeSDigJ5x4oCe4oCm4oCee+KAnnLigJ5w4oCefeKAnnkgKDIpLnR4dA==”))
Encoding.GetEncoding(“windows-1251”).GetString(Convert.FromBase64String(“4oCe0IPigJ7igJrigJ514oCee+KAnuKAmuKAnnDigJ7Rk+KAnn7igJ7QjOKAnnog4oCedOKAntCC4oCee+KAnuKApuKAnn3igJ514oCefuKAnuKAniDigJ7RkyDigJ7igJrigJ7igKbigJ7Rk+KAntGT4oCee+KAnnnigJ594oCeeSDigJ5x4oCe4oCm4oCee+KAnnLigJ5w4oCefeKAnnkgKDIpLnR4dA==”))
Encoding.GetEncoding(“iso-2022-jp”).GetString(Convert.FromBase64String(“4oCe0IPigJ7igJrigJ514oCee+KAnuKAmuKAnnDigJ7Rk+KAnn7igJ7QjOKAnnog4oCedOKAntCC4oCee+KAnuKApuKAnn3igJ514oCefuKAnuKAniDigJ7RkyDigJ7igJrigJ7igKbigJ7Rk+KAntGT4oCee+KAnnnigJ594oCeeSDigJ5x4oCe4oCm4oCee+KAnnLigJ5w4oCefeKAnnkgKDIpLnR4dA==”))
as you may see, I didn’t get correct decoding…
You are using the utf-8 for decoding the string, but it is not correct in our case…
Hi,
- OS version
- OS Architecture (32/64 bit)
- OS Service Pack version/language
- Visual Studio version and Service Pack
- .NET Framework version
- Outlook version
Hi!
On the client side we are using:
- WinXP32 + SP3
- VS2010 Ultimate Edition + SP1
- NET2.0
- Outlook 2003 (11.8330.8333)
the pop3 server have the mail-related setting to TNEF.
I am trying to organize the test access to our mail server but I can’t promise you on 100% that it will possible…
sorry… +(
In case of set the pop3 server mail-related setting to nHTML, the behavior of the work is changed.
The attached picture shows the result:
- no problem with international chars in sublect [+]
- no problem with international chars in the names of attached files [++]
- problem with drawing the embedded picture… [–]
(instead of the picture we see the red cross)
Hi Raza,
The situation with the international chars are more complex as I thought before…
In case of reading the rich formatted message on 32bit winxp using pop3client we get the issues in international names of the attachments.
But(!) in case of doing the same on the 64bit WinServer2008 we don’t have any issues!!! And all(!) works fine (for TNEF setting)!
But the embedded pictures doesn’t appear for both architecture of OS… (with the nHTML setting on the pop3 server).
In other words, the international chars decoding without any problems on 64bit OS but have (sometimes) the issues on 32bit OS.
It is the fact (for TNEF).
If you will take the look on the length of the encoded string (base64) from my previose email, you will see that it is strange…
If I encode the international string on 32bit OS from utf-8 + base64 manually, I get shorter length then i see in the attach.ContentType.Name property…
May be the сapacity of the OS has the influence on the behavior of decoding algorithm into your classes?
Hi,
Hi Raza!
Please see the snippet code below:
using( Pop3Client client = new Pop3Client(FEmailServer, FEmailPort, FEmailUserName, FEmailUserPassword) ) {
client.Connect();
try {
Pop3MessageInfoCollection msgCollection = null;
client.Timeout = FEmailTimeout;
try {
msgCollection = client.ListMessages();
}
catch( Exception ex ) {
throw new Exception(string.Format(“err [{0}] reading from: {1}”, ex.Message, FEmailServer));
}
foreach( Pop3MessageInfo msgInfo in msgCollection ) {
int UniqueID = msgInfo.SequenceNumber;
MailMessage msg = client.FetchMessage(UniqueID);
[//msg.PreferredTextEncoding](https://msg.preferredtextencoding/) = System.Text.UTF8Encoding.Default; // <-- koi8-r???
msg.PreferredTextEncoding = Encoding.UTF8;
if( msg.To.Count == 0 ) continue;
//fixing the issue with russian chars in the names of the attachment
//fixed in v1.6.0!!!
foreach( var attach in msg.Attachments ) {
attach.NameEncoding = System.Text.UTF8Encoding.Default;
attach.PreferredTextEncoding = System.Text.UTF8Encoding.Unicode;
//due to issue with international chart just translit the string from russian into english
//fixed in v1.6.0!!!
[//attach.Name](https://attach.name/) = translitString(attach.Name);
[//System.Console.WriteLine](https://system.console.writeline/)("-[ {0} ]-------------------------", attach.Name);
}
try {
try {
[//msg.Save](https://msg.save/)(workingFolder + @"" + emailName + “.msg”, MessageFormat.Msg);
[//msg.Save](https://msg.save/)(LocalPath33, MessageFormat.Msg);
msg.Save(LocalPath33, MailMessageSaveType.OutlookMessageFormatUnicode); //OK!!!
}
finally {
//…
}
}
finally {
// delete the read message
[//client.DeleteMessage](https://client.deletemessage/)(strMessageURI);
client.DeleteMessage(UniqueID);
}
}
}
finally {
if( client.ConnectionState == Pop3ConnectionState.Authentication ) {
[//client.CommitDeletes](https://client.commitdeletes/)();
[//client.Quit](https://client.quit/)();
client.Disconnect();
}
}
}
Hi,