[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Looking for best option
Hi Bruce,
Apparently your XML document containing the <BASE64DATA> tag (as well as
other tags) is encoded? i.e. if you look at the data in your
httpapi_debug.txt log, you'll see <BASE64DATA> instead of
<BASE64DATA>? Is that right? (I guess I should've known this from your
earlier discussion... I didn't put 2+2 together)
If so, I would suggest that you extract the whole GetDataImageResult tag
to a temporary file, and then parse that temporary file with
http_parse_xml_string() (or XML-INTO or XML-SAX) to get the BASE64DATA
element. Not sure if that'd make a difference or not, but it's the more
"correct" way to do it.
Other possible problems:
a) I see you're not using HTTP_XmlReturnPtr() as I suggested. This
means your entire XML document (the one encoded in the
GetDataImageResult tag) is limited to 64k, including the whole image. I
don't know if that's a problem or not, but personally, I'd be reluctant
to trust that my image would always be that small.
b) You need to make sure that any non-base64 characters (including
spaces, CR, LF, etc) are removed from the string before feeding it into
base64_decode().
c) Your logic for 'val2' is wrong. Since VAL2 is VARYING, you can't
simply pass %addr(VAL2) to base64_decode. Instead, you'll need to do
%len(VAL2) = %size(VAL2) - 2 to set VAL2 to it's maximum length, then
%addr(VAL2)+2 in the 3rd parameter, and %size(VAL2)-2 in the 4th
parameter of base64_decode(). After base64_decode() is complete, the
%len() of VAL2 should be set to the value returned by base64_decode.
d) When you call the write() API, you can't legally use %trim() on VAL2.
Remember, VAL2 is a binary string. It may contain a x'40' (blank)
that's a completely legitimate part of the image. Don't strip that
blank off! It's not text where x'40' means a blank space -- it's an
image, where it could mean something else!
That's what I see wrong off the top of my head...
Bruce Reynolds wrote:
> Hi Scott,
>
> Attached is the source from a test program that makes the image request and
> decodes it using base64_decode. I've also attached a savf containing the
> output of the same image from Tomkat. Could you take a look and see what I
> am doing wrong as they are not the same.
>
> The reason I can view tiff images in my browser is because of the
> Alternatiff plugin.
>
> Thanks,
> Bruce
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
> Sent: Monday, January 05, 2009 3:19 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: Looking for best option
>
> Bruce Reynolds wrote:
>> From previous email postings I understand that base64 data should not be
>> converted to EBCDIC
>
> Why not? base64_decode() (from BASE64R4) won't understand the data
> unless it's EBCDIC, so I don't understand why you'd say this.
>
> The whole point behind base64 is that you can translate the encoded data
> any way you like. That's the POINT of base64. Feel free to translate
> the encoded data to EBCDIC -- it's the DECODED data that you have to be
> careful with.
>
> Therefore I'd do this:
>
> a) Call http_XmlReturnPtr(*ON)
> b) Call http_url_post_xml().
> c) in your end element handler, check for the BASE64DATA tag.
> d) if BASE64DATA, allocate temporary memory for the output from
> base64_decode().
> e) if BASE64DATA, call base64_decode()
> f) if BASE64DATA, open an IFS file.
> e) if BASE64DATA, write decoded data to IFS.
> f) if BASE64DATA, close file.
> g) if BASE64DATA, deallocate temporary memory.
>
> The result should be your TIFF file.
>
> The other flaw in your logic is that browsers don't usually understand
> TIFF files. You may need to convert them to PNG or JPG first, then send
> THAT to a browser. If that turns out to be an issue, you might look
> into imagemagick to see if it can convert your TIFF to another format.
>
> Make sense? Let me know if you need more info on any of these steps.
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> 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
> -----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------