| Author |
|
Guests
Guest Group
Joined: 10 November 2003
Online Status: Online
Posts: 262
|
| Posted: 18 May 2005 at 5:09pm | IP Logged
|
|
|
Hi,
I have been trying to use MailBee product to get emails from different people using different codepage and i am encountering the following problem.
If the email was sent in UTF8, i will get the body of the email correctly (in this case, japanese character), but the subject will look bad.
If i send the the email in iso-2022-jp, none of the subject or body will look correct.
Also, even if i specify in my mail client, message.Charset is never set even if Content Type has the correct charset in it.
I would like to find out about how to get both subject and body in those two cases functionning.
Thank you
|
| Back to Top |
|
| |
Alex
AfterLogic Support
Joined: 19 November 2003
Online Status: Offline
Posts: 2206
|
| Posted: 18 May 2005 at 11:05pm | IP Logged
|
|
|
As a first aid, I would recommend you to try out these properties: POP3.CodepageMode (for solving problems with incoming mail), SMTP.EncodeHeaderText (for solving problems when UTF8 headers being sent).
Also, you can read the below for better understanding of things related to international support in email and COM/VB/ASP.
International support in email is rather complex thing because MIME format was not originally developed with internationalization kept in mind. Thus, many tricks and custom extensions have been made later and this prevent email from automatically support internationalization in correct way. Also, ASP/VB themselves impose several limitations on international functionality. MailBee supports international email extensions and has features for avoiding problems with ASP/VB limitations but you have to manually specify when and how to use these extensions and features.
1. Message.Charset (also available as SMTP.Charset). Specifies charset of mail being sent. This is just a string. All it does is specifying charset in Content-Type. This means content you put in body must be already in this codepage.
When message is being received (or loaded from file or any other source, doesn't matter), Charset property is empty because MailBee automatically converts body content from Charset to Windows codepage. Thus, Charset no longer represents current codepage of the message and that's why it's set empty.
2. Setting UTF8 subject. UTF8 content is not allowed in message headers. To put UTF8 in message header, you have to use Message.EncodeHeaderText which will produce specially encoded string you can then put into Message.Subject.
3. Reading international message. There are several reading modes exist (depending on which target container is). Why this is needed:
Consider two scenarios (a and b).
a) MailBee used on web server (US codepage is default)
b) MailBee used on Japan workstation
Now, Japan message arrives. In "a" case, MailBee should produce body text as US chars (with charset codes larger 127) because web server does not support Japan codepage and cannot print Japan content directly to the response. Web server will print the string of these chars (which looks like garbage in English) to Japan browser (installed on Japan workstation). Japan browser has different codepage and will treat the same string differently, and this string will read ok in Japan. Thus, it becomes possible to transfer text in Japan codepage through web server which cannot output data in Japan codepage (because server thinks it prints data in US codepage).
However, in "b" case MailBee should convert text directly to Japan chars becuase it already operates on Japan workstation.
To control this, MailBee.Message supports CodepageMode property (thoroughly described in docs). It has several values you can experiment with. Also, this property can be used in conjunction with Codepage property (when you need to convert data to specific codepage).
When Message object was returned by POP3 object, it's already parsed so you can't set CodepageMode property. For this, POP3.CodepageMode exists. It's just passed to all Message objects POP3 object creates so Message.CodepageMode would be set before POP3 object will parse them. POP3.Codepage is also available.
In general, international support in email requires good understanding of codepages/strings/etc from the programmer. MailBee provides tools for this, but you have to understand why to use them.
Finally, just another couple of things which are worth mention (they are not MailBee issues but you have to take them into account when programming).
In ASP, you cannot convert to UTF8 the content you're sending to the client. ASP itself has serious problems with this. If the content is already UTF8, all's fine but if it's not and you're converting it to UTF8, ASP page may crash. You can use MailBee.Message.ToUTF8 method to safely convert your data to UTF8.
In VB6, strings are stored as unicode but are treated as 8bit strings. Thus, with VB it's recommended to use strings which entirely consist of chars belonging to native codepage of the machine. For example, it's better to use UFT8 string (which itself consists of 8bit chars only) than real unicode string.
Regards,
Alex
|
| Back to Top |
|
| |
Guests
Guest Group
Joined: 10 November 2003
Online Status: Online
Posts: 262
|
| Posted: 19 May 2005 at 9:47am | IP Logged
|
|
|
Thank you for quick answer.
Regarding 1) and 2), it is already why i am doing and so far had no problem sending UTF-8 encoded emails.
3) is the issue. We are using ASP, and the page by default is set to utf-8. However, the page can receive a lot of information from different codepage. If i have read correctly your documentation, using Pop3.codepage is only meaningful if you know that you are expecting that particular codepage. Now, if i understand right, using a system that will look at the codepage of the email, then closing connection and then specifying the codepage found might do the trick. But it is quite long and a better alternative is hopefully possible
|
| Back to Top |
|
| |
Alex
AfterLogic Support
Joined: 19 November 2003
Online Status: Offline
Posts: 2206
|
| Posted: 19 May 2005 at 11:01am | IP Logged
|
|
|
I think there is an easier way.
If you want to display everything as UTF-8, you can specify POP3.CodepageMode=0, POP3.Codepage=65001, and ASP's Response.Charset="utf-8". In this case, MailBee will convert all mails into UTF-8.
However, do not touch Session.Codepage property (or any other codepage-related property of ASP). If you specify Codepage=65001 in both MailBee and ASP, conversion to UTF8 will be performed twice, which is an error.
Last thing is HTML mails. They often contain charset META tag which is no longer valid once message's content has been converted to another codepage. You should remove this tag from your HTML mails (either using RegExp or using free MessageCensor component as it done in our WebMail Lite app):
Code:
Set Censor = Server.CreateObject("MC.MessageCensor")
Censor.AddUnsafeTag "META", 0
message_text = Msg.GetCensoredBody(Censor)
|
|
|
This will remove META tags from HTML message (assuming Msg.BodyFormat=1, i.e. HTML).
Regards,
Alex
|
| Back to Top |
|
| |
Jane
Guest Group
Joined: 10 November 2003
Online Status: Online
Posts: 262
|
| Posted: 01 January 2006 at 4:47am | IP Logged
|
|
|
i have been on epals this thing sent a message and want it back how do you do it   plz reply fast
|
| Back to Top |
|
| |
Alex
AfterLogic Support
Joined: 19 November 2003
Online Status: Offline
Posts: 2206
|
| Posted: 01 January 2006 at 8:14am | IP Logged
|
|
|
I'm sorry but I didn't understand your request. Could you please provide some more details? Thanks in advance.
Regards,
Alex
|
| Back to Top |
|
| |
MailBee.NET Objects 
MailBee.NET Queue 
MailBee Objects 
WebMail Pro PHP 
AfterLogic Aurora 
MailSuite Pro for Linux 
Unified Messaging Solution 
Search
Register
Login
Topic: Problem with characters
Privacy policy |
Refund policy