Lately there was a thread of converting BASE 64 TO PDF .

I was intrigued so I decided to do some tests (We might get any kind of data this way) .

Using Java I generated a Base64 text file (this will be used as input ) .


This is how the output file looks like (1,060,588 byte long string)


Time for some abap code:

Program steps ( Y_R_EITAN_TEST_31_10 ) :


– Using cl_gui_frontend_services=>gui_upload to upload the text file (C:\temp\An Easy Reference for ALV Grid Control.pdf.txt).

– Using cl_http_utility=>if_http_utility~decode_x_base64 to decode the data the output from this method is xstring .

– CALL METHOD cl_gui_frontend_services=>gui_download to write the xstring as PDF (C:\temp\An Easy Reference for ALV Grid Control.lcl.pdf) .

– Use OPEN DATASET BINARY MODE to write the xstring as PDF to a shared folder (\\server\<some shared folder>\An Easy Reference for ALV Grid Control.shr.pdf)

The new PDF files can be opened with no problems using adobe reader

Comparing the files using MD5 tell me that the file downloaded using cl_gui_frontend_services=>gui_download is not identical to the original !!!!


So I used a binary editor to compare:


There is some extra bytes in the new file .

This does not interfere in this case but might cause a problem with other file formats and it is annoying…(Any idea ???? )

This all for now.


Thanks to the sharp eyes of Tomas Buryanek the problem with cl_gui_frontend_services=>gui_download was solved (My bug…)

We need to send to cl_gui_frontend_services=>gui_download the original file size (p_filsiz).


To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Eitan Rosenberg Post author


      I have done a test using “OPEN DATASET BINARY MODE” and this produce an identical twin to the original .

      This leaves cl_gui_frontend_services=>gui_download or ME 😛 (I hope that this is the case) as main suspects…..

      Program Y_R_EITAN_TEST_31_10 was updated to include the whole show…



Leave a Reply