Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: MIME::Parser parse_data

by Corion (Pope)
on Jan 17, 2013 at 17:20 UTC ( #1013825=note: print w/replies, xml ) Need Help??

in reply to MIME::Parser parse_data

I think the content encoding after base64 decoding is in the Content-Encoding header. Or at least, it should be, if the sending MUA adds it. Otherwise, you have to ass-u-me some default encoding.

Replies are listed 'Best First'.
Re^2: MIME::Parser parse_data
by boosth (Initiate) on Jan 17, 2013 at 18:19 UTC
    An example that I have that is working with option A. Even though the raw data is clearly base64 encoded it is being parsed as a human readable string
    There is no "Content-Encoding" header in the raw mail.

    Here's the relevant part of the header:
    X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:cont +ent-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=NextPart001_01CDF2E2.B6A090C6" This is a multi-part message in MIME format. ------_=NextPart001_01CDF2E2.B6A090C6 Content-Type: multipart/alternat +ive; boundary="----_=NextPart002_01CDF2E2.B6A090C6" ------_=NextPart002_01CDF2E2.B6A090C6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlICwKCldpbGwgYmUgaW4gdG91Y2ggaSBhbSB0aGlua2luZyBvZiBkb2luZyBhIH +RyaXAg dG8gSXRhbH ...
      Content-Type: text/plain; charset="utf-8"

      That's a good hint for that part...

        The problem is that I have other emails where it has the same format but I have to use this instead:
        $MessageBody = " ". decode('UTF-8',decode_base64($tmp_part->bodyh +andle->as_string));
        ------_=NextPart002_01CDF2E2.B6A090C6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlICwKCldpbGwgYmUgaW4gdG91Y2ggaSBhbSB0aGlua2luZyBvZiBkb2luZyBhIH +RyaXAg dG8gSXRhbH
        The issue appears to be that this call:
        my $tmpMessage = $parser->parse_data($body);
        Is returning decoded strings for some emails but not for others. Some of the emails require the output of this call:
        to be decoded manually and others do not. I don't understand why sometimes this call
        Returns a human readable decoded string on some emails with base64 encoding but not on all emails with base64 encoding. This is a headache for me because if I change the code to just output the string it breaks on emails that need the string manually decoded. All I am doing is calling "parse_data" and then "bodyhandle->as_string". I'm not sure where the decoding process happens. The original data is definitely base64 encoded which I can see by looking at the raw email data.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1013825]
[marto]: erix unlikely, we've had posts within the last few minutes ;)
[ambrus]: nysus: make sure you enter at least two lines for the title and then preview, and read warnings the preview form prints
[davies]: There is an option (I have it set) to force preview before submission. Perhaps your option has been set (accidentally?) and you are not expecting it.
[ambrus]: sorry, I mean at least two words for the title and then preview
[ambrus]: davies: that option is the default. and it's not really "force", it just hides the button.
[marto]: yes, not reading the errors displayed has been a cause of this type of report in the past
[nysus]: Ambrus, ah. I think that was the problem. I'll try. Thanks!
[davies]: Ambrus: you've missed it by a couple of weeks, but consider next year's London Perl Workshop.

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (7)
As of 2017-12-15 11:35 GMT
Find Nodes?
    Voting Booth?
    What programming language do you hate the most?

    Results (431 votes). Check out past polls.