[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Base64 Decoding

   Hi Scott -
   Thanks for the info. I'm able to decode the MIME-64 attachment, but
   I'm running into another (bigger?) problem. I'm using your port of
   eXPat to parse through the XML document. However, the element value
   that will contain the PDF document can easily be over 100K in size! I
   received a test document that was 150K, with the PDF document
   comprising 120K of the total. Will eXpat handle elements this size?
   Will the parser provide multiple iterations of the same element data
   which I could then write to a file for later retrieval using a Base64
   decoding scheme? Any ideas on how I can process this big element?
   Thanks...
   - Michael

   On Mon, Jul 12, 2010 at 4:05 PM, Scott Klement
   <[1]sk@xxxxxxxxxxxxxxxx> wrote:

     Hi Michael,
     You need to *include* the == at the end.  And make sure any other
     whitespace in the XML tag has been removed (blanks, CRLF, tabs,
     etc)
     The = or == is needed (if it was provided.)  Don't strip it.

   On 7/12/2010 1:07 PM, Michael Ryan wrote:
   >
   >     Hi Scott -
   >     Thanks for the quick reply. I'm indeed using your base64
   decoding
   >     routine. So if I have the following in an XML element that I've
   >     translated to EBCDIC:
   >     MYCOMPANY_ENCODING="MIME-64">JVBERi0xLjeLjz9MNCjkg...==
   >     I want to grab everything from ">JVBER..." up to (but not
   including)
   >     the ending "==", right? Then I would use base64_decode to decode
   the
   >     contents back into binary. It's supposed to be a PDF file, but
   it
   >     doesn't look like enough data to me. Anyway, I would then have
   to get
   >     that PDF data to a printer. But first I need to decode it...:)
   Thanks!
   >
   >     On Mon, Jul 12, 2010 at 1:28 PM, Scott Klement

   >     <[1][2]sk@xxxxxxxxxxxxxxxx>  wrote:
   >
   >       Hi Michael,
   >       If you're using _my_ base64 decoding routine, then the input
   needs
   >       to be
   >       in EBCDIC.  It's written in RPG, and will see ASCII as nothing
   but
   >       gibberish.
   >       Also, the decoder only understands base64 encoded data.  It
   doesn't
   >       understand XML, CRLF, blanks, or anything else besides base64
   >       encoded
   >       data.  It's up to you to extract the base64 encoded data and
   pass
   >       it to
   >       the decoder.
   >       Good luck
   >
   >     On 7/12/2010 12:01 PM, Michael Ryan wrote:
   >     >
   >     >      Here's my scenario. I'm getting a PDF file in an XML
   stream. The
   >     PDF
   >     >      file is an an element, and starts with
   blah_ENCODING="MIME-64".
   >     I'm
   >     >      attempting to use Base64 decoding, but I'm running into
   >     problems. I've
   >     >      d/l'ed the Base64 code, created the service program, all
   looks
   >     well
   >     >      there. I've searched the archives for an example, and am
   using a
   >     >      simple one. The decode fails on a "can't convert the
   first
   >     character"
   >     >      error. I'm flailing a bit, so I thought I'd ask for a
   hand.
   >     Should I
   >     >      be using the ASCII (UTF-8?) value of the element? Any way
   I can
   >     debug
   >     >      this further (ala httpapi debug file)? Thanks!
   >     >
   >     >
   >     >
   >     >
   >
   >       >
   >
   -------------------------------------------------------------------
   >       ----
   >       >  This is the FTPAPI mailing list.  To unsubscribe, please go
   to:

     >       >
     [2][3]http://www.scottklement.com/mailman/listinfo/ftpapi

   >       >
   >
   -------------------------------------------------------------------
   >       ----
   >
   -------------------------------------------------------------------
   >       ----
   >       This is the FTPAPI mailing list.  To unsubscribe, please go
   to:

     >       [3][4]http://www.scottklement.com/mailman/listinfo/ftpapi
     >
     -------------------------------------------------------------------
     >       ----
     >
     > References
     >
     >     1. mailto:[5]sk@xxxxxxxxxxxxxxxx
     >     2. [6]http://www.scottklement.com/mailman/listinfo/ftpapi
     >     3. [7]http://www.scottklement.com/mailman/listinfo/ftpapi

   >
   >
   >
   >
   >
   ----------------------------------------------------------------------
   -
   > This is the FTPAPI mailing list.  To unsubscribe, please go to:
   > [8]http://www.scottklement.com/mailman/listinfo/ftpapi
   >
   ----------------------------------------------------------------------
   -
   ----------------------------------------------------------------------
   -
   This is the FTPAPI mailing list.  To unsubscribe, please go to:
   [9]http://www.scottklement.com/mailman/listinfo/ftpapi
   ----------------------------------------------------------------------
   -

References

   1. mailto:sk@xxxxxxxxxxxxxxxx
   2. mailto:sk@xxxxxxxxxxxxxxxx
   3. http://www.scottklement.com/mailman/listinfo/ftpapi
   4. http://www.scottklement.com/mailman/listinfo/ftpapi
   5. mailto:sk@xxxxxxxxxxxxxxxx
   6. http://www.scottklement.com/mailman/listinfo/ftpapi
   7. http://www.scottklement.com/mailman/listinfo/ftpapi
   8. http://www.scottklement.com/mailman/listinfo/ftpapi
   9. http://www.scottklement.com/mailman/listinfo/ftpapi

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------