DECODING MAIL FROM WEB SERVER IN PLAIN TEXT FORMAT(THE MAIL BEING SENT BY LABVIEW APPLICATION)

[user_1]

Hi All

I have a labview application that send mail every hour automatically.

But actually the mail has to be decoded from the web server(by another application).But now when that application decode the data in the mail(that is send by labview application)its getting some funny characters inside that can not be detected by the decoding application

(When open the mail no problem.)But actually our goal is to decode the mail from the web server.

Why the extra characters are appearing when decoding from the server?Is it because of the HTML format?

Is there option to send the mail in plain text format(not like attachment)?

In outlook we can change the setting (tools->options->send->mail sending format->....here we can set as HTML format/Plain Text format)

Like that at the sending time can i chenge the sending option as plain text format in my labview application?

Thanks...

[PJS]

I have a send mail example on my samples page.  You can specify plain text or html.  The example is more geared towards gmail, but easily adaptable.  AND does not use outlook.  It does use the .net api however, so windows only, and the example is in 8.5.

[smercurio_fc]

What are you using the send the email? Is it the SMTP functions that ship with LabVIEW? Those are supposed to send text messages. Can you provide an example of what you're seeing?

[user_1]

Hi All,

Sorry for the big delay in reply.

I was working with another project so have to hold the email application for long time.

Now i changed my application so that the message is being sent as an attachment.But still getting extra characters.But now no unrecognised characters.

In my application i was sending message by using SMTP Email Send Message .

When we open the attachment its perfectly alright.But when it is decoded by another application its getting some extra characters.Furnished below is the original message send and the message that is stiffed with extra characters.

Hope somebody can help me.  

                                                            ORIGINAL MESSAGE

DATASTART
StnNo=P300004,StnName=TamanHijau,Date=20080116,Time=201014,Rvr=02820|02600|00000,Flow=0000|0000|0003,Pump=OFF|OFF|OFF,Pressure=0016
StnNo=P300007,StnName=WangsaMas,Setapak,Date=20080116,Time=202720,Rvr=02200|01240,Flow=0000|0003,Pump=OFF|OFF,Pressure=0243
StnNo=P300052,StnName=TamanIxora,Date=20080116,Time=204416,Rvr=03830|00000,Flow=0067|0000,Pump=OFF|OFF,Pressure=0575
StnNo=P300031,StnName=R/PTmnLagendaMas,Date=20080116,Time=205616,Rvr=-99.99|03550,Flow=0000,Pump=OFF|OFF,Pressure=0119
DATAEND

                                                               Messge with extra characters.

DATASTART

StnNo=3DP300004,StnName=3DTamanHijau,Date=3D20080116,Time=3D201014,Rvr=3D0= 2820|02600|00000,Flow=3D0000|0000|0003,Pump=3DOFF|OFF|OFF,Pressure=3D0016 StnNo=3DP300007,StnName=3DWangsaMas,Setapak,Date=3D20080116,Time=3D202720,= Rvr=3D02200|01240,Flow=3D0000|0003,Pump=3DOFF|OFF,Pressure=3D0243 StnNo=3DP300052,StnName=3DTamanIxora,Date=3D20080116,Time=3D204416,Rvr=3D0= 3830|00000,Flow=3D0067|0000,Pump=3DOFF|OFF,Pressure=3D0575 StnNo=3DP300031,StnName=3DR/PTmnLagendaMas,Date=3D20080116,Time=3D205616,R= vr=3D-99.99|03550,Flow=3D0000,Pump=3DOFF|OFF,Pressure=3D0119

DATAEND

[RavensFan]

Definitely odd.

I do see one pattern for most of the extra characters.  Wherever there is an equal sign = ,  it gets replaced by =3D.  While this all looks like individual characters, 3D appears to be a hex value string.  3D in hex is 61 decimal, an the ASCII character for 61 decimal is an equal sign.  Now there are some other odd substitutions going on, but this is the one that seems to be consistent.  Hopefully this observation will give someone some ideas as to what is causing this.

The only other questions I can think of is whether there is something odd about the character sets being used.  Is there something multinational, multilingual about one of the e-mail servers, some thing like a UNICODE language base????

[user_1]

Hi Ravens Fan,

Thank you so much for the reply.

In the application i am using the characters like =,|, -

The whole message is manipulated as string in the block diagram.So the special charactes also manipulated as string or part of string.

Yes ...all equal to symbols are converted as =3D.And i noticed that the negative symbol also getting some deformations.But to surprise the symbol '|' (pipeline symbol)is not getting deformad.

Is there any solution for my problem?

Thanks again

[smercurio_fc]

You said

"When we open the attachment its perfectly alright.But when it is decoded by another application its getting some extra characters"

This seems contraditory. How are you opening the attachment to say it's "perfectly alright", and what other application are you using to say it's getting some extra characters.

I don't have access to a server that doesn't need authentication, so I couldn't use the built-in SMTP functions. I used the OGIC_SMTP library to send your test message with the text as the body of the message as well as with the test message as an attachement, and both times it came through all right, as far as I could tell. I even opened the received attachment in a hex editor and saw no extra characters.

[user_1]

Hi,

Thank u 4 the reply.

I said like that because...

I am sending the mail to a mail id.When i login and after opening the mail its same as the one which is being sent by Labview application.

But actually another application is decoding the mail for the purpose of keeping the values to the database.

But when that application tries to decode the attachment ,the contents of the attachment is getting deformed.

Thanks

[smercurio_fc]

Then it sounds to me like this other application is not decoding the attachment correctly, especially if you looked at the attachment yourself after you received it and verified it's correct.

[rolfk]

---

@smercurio_fc wrote:
Then it sounds to me like this other application is not decoding the attachment correctly, especially if you looked at the attachment yourself after you received it and verified it's correct.

---

No, no, smercurio. This is charcter encoding here. In older versions of LabVIEW you could specify what character encoding to use when sending an email through the SMTP VIs. But that gave problems since people in certain locales used certain characters that where not transfered right when the wrong encoding was specified, and that encoding stuff is not understood by most people at all, so the wrong selected encoding was rather the rule than the exception. In newer versions of LabVIEW do the SMTP VIs handle the encoding automatically based on the currently used locale on the system.

This change is documented in the Upgrade Notes of LabVIEW and probably happened around LabVIEW 7.1 or 8.0.

A decent mail client will recognize the encoding and convert it back to whatever is necessary before presenting it to the user. The OPs posters server application obviously isn't a smart mail client but probably just some crude text file parser that has no notion of proper mail character encoding and how to deal with it.

I would suppose that there is a chance to dig into the SMTP VIs itself and try to manipulate or disable that encoding altogether in there but that may open a whole can of worms somewhere else. The proper way would be to process the incoming mail by a character encoding aware mail client before passing it to the text parser. On Unix setting up something like this would be fairly trivial.

Rolf Kalbermatter

Message Edited by rolfk on 01-23-2008 10:21 AM