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
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.?
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"?