Re: base64 Encode a tiff image.

On 12-Apr-2012 08:19 , Jorge Merino wrote:

I had some images on the IBM i server, when transferred to a Windows
or Linux machine using FTP/ascii were downloaded properly.

Again... "images"; i.e. with FTP using TYPE IMAGE for "images; and other non-text data", not TYPE ASCII for "text data\documents", would be the appropriate choice for transport. Allowing for the FTP to possibly modify some various "text" control-characters would not be ideal; e.g. possibly having converted [what could be interpreted as a] LF character, into a CRLF sequence, would add bytes to the stream.

My goal was to embed those images into a XML as part of a Web Service
Response, so I 1) streamed those images 2) and base64_encode them as
I would regularly would do it with PHP or any other language, but it
didn't work. The image was not properly being shown up.

By what means are those images being /streamed/ and from where? Were they streamed via FTP from the Win or *nix system to the IBM i using ASCII to EBCDIC or as ASCII text [instead of IMAGE] transport?

After looking in the several references on the web, I found out that
the way to do it is to 1) stream it, 2) convert to ASCII, 3)
base64_encode; now I have on the IBM i a REST web service returning a
XML with an image on it.

Perhaps I am being /thick/ in addition to some level of ignorance. But I still do not understand where an /image/ would ever need to have performed, any /convert to ASCII/ processing.? If passing a binary stream [an image] through an EBCDIC to ASCII conversion makes an image processing feature become functional, then the original data was almost surely not a binary stream [i.e. not an "image"], but instead almost surely was EBCDIC text data. If the "stream it" step had caused the binary stream to be converted as though from ASCII into EBCDIC character data, then instead of inserting some "convert to ASCII" step as a corrective action [to reverse the conversion], what seems more appropriate would be to avoid having corrupted the stream originally; i.e. "stream it" in binary\image mode, so as to obtain the data without any conversions.?

A binary stream as source\input for base64 encoding would ideally generate ASCII character stream output, directly, if that is what [most of] the consumers desire. However even if EBCDIC character data was used for the base64 encoded output, that is of little concern, because then the now base64-encoded data can be converted safely [e.g. during transport] between the EBCDIC and the ASCII character encoding. Just seems wasteful however, to require any conversions in a scenario, when doing no conversions should be possible.

Or perhaps the above sequence of operations intends to suggest that the binary stream [the image] is being base64 encoded and the output would then be used in an ASCII XML [i.e. reversing steps two and three], but the output from base64 encoding of the image was EBCDIC characters, so that output had to be converted to ASCII? Having been base64 encoded directly into ASCII characters instead, then the data could be included in the ASCII XML without any text conversion.?

Regards, Chuck

CRPence on Wednesday, April 11, 2012 5:33 PM wrote:

Perhaps just my ignorance, but where is there a need for dealing
with character conversions when the original data is "image"?