How to build PDF file from binary string returned from a SOAP web-service? RRS feed

  • Question

  • Hi everyone!

    A simple question.
    How to build PDF file from binary string returned from a SOAP web-service?
    They gave me a txt file example (many parts are omitted for privacy -- sensitive data).

    An example:

    Content-Type: text/xml; charset=utf-8

    <SOAP_ENV:Envelope xmlns:SOAP_ENV="">[...]<SOAP_ENV:Header></SOAP_ENV:Body></SOAP_ENV:Envelope>
    Content-Type: application/pdf
    Content-Transfer-Encoding: binary
    Content-ID: <2584312939175.1462467288555.IBM.WEBSERVICES@uhewbswas02>


    Any suggestion is welcome.
    Sunday, May 22, 2016 9:51 PM

All replies

  • Seems the payload itself is already a valid PDF file.

    How about doing repetitive read to buffer with a loop and seeking for "%PDF" pattern in the network stream, then write the data from the point the pattern is found to a MemorySteam (if you'll relay the payload to, say, the Response.OutputSteam immediately) or a FileSteam (if you need to save it) until "%%EOF" pattern is detected?

    Monday, May 23, 2016 2:28 AM
  • Sorry for my late reply...

    I've tried to do this:

    //Here I've got %PDF...%%EOF pattern
    byte[] bytes = File.ReadAllBytes(inputFilename);
    Stream stream = new MemoryStream(bytes);
    byte[] decompressedBytes = Decompress(bytes);
    File.WriteAllBytes(outputFilename, decompressedBytes);
     public static Byte[] Decompress(Byte[] bytes) {
                using (var memoryStream = new MemoryStream()) {
                    using (var deflateStream = new DeflateStream(memoryStream, CompressionMode.Decompress, false))
                        deflateStream.Read(bytes, 0, bytes.Length);
                    return memoryStream.ToArray();

    Not work... :(

    • Edited by cosmopsis Wednesday, May 25, 2016 11:51 AM
    Wednesday, May 25, 2016 11:51 AM
  • Humm... You've got the "%PDF" to "%%EOF" content, why would you want to run decompress on it again?

    Btw, please clearify what do you mean by "won't work". Is there exception being thrown? What are the error messages?

    Thursday, May 26, 2016 1:31 AM
  • I think that the "%PDF" to "%%EOF" content is codified in binary encoding (not in base64-encoding), and I've read that "WebSphere® Message Broker" supports compression and decompression with the HTTP and SOAP.


    Content-Type: application/pdf
    Content-Transfer-Encoding: binary
    Content-ID: <2584312939175.1462467288555.IBM.WEBSERVICES@uhewbswas02>


    That is where I've used DeflateStream class, but the output seems to be corrupted.

    I hope I have been clearer now. :)

    Thursday, May 26, 2016 12:09 PM
  • No. You should just dump the content to a file "as is".

    The "binary" here just mean this is not text, much like in FTP you have "ascii mode" and "binary mode" (See RFC2045, forth paragraph of Section 6.2). You should only process it with DeflateStream when the content-transfer-encoding is "deflate".

    For more information, see the SOAP specification from W3C.
    Thursday, May 26, 2016 1:28 PM
  • Just dump the content to a file "as is", doesn't work.

    Opening pdf file shows only blank white pages.

    Monday, May 30, 2016 8:14 PM
  • Have you checked the dumped content using a binary editor (using Notepad++ with HEX-Editor plugin is good enough if you don't have one) that the file start with "%PDF" and end with "%%EOF"? Or did they just sent you a blank file for testing?

    You can try to open a PDF file you have to see what a PDF file should look like to get the idea.
    Tuesday, May 31, 2016 1:12 AM
  • The dumped content at the file start with "%PDF" and end with "%%EOF" and the original pdf is completely different...

    Sorry for my late reply...

    Wednesday, June 22, 2016 11:59 AM
  • In that case, I advise you to tell them to dump the generated PDF file somewhere so you can compare what is the difference between their generated file and the file you extracted from the webservice call.

    Using what I told you to do, the file should be extracted correctly.

    Somehow I think they may have try to dump the file to Response.Write() that tries to write things as string instead of Response.BinaryWrite() that writes the bytes as is. But hey, just compare both files with a Hex editor.

    Wednesday, June 22, 2016 12:25 PM
  • Response.Write()?

    That's one thing. I'll try to make that clear -- partially clear.

    I keep you informed.


    Wednesday, June 22, 2016 8:31 PM