title: Decompressing/inflating zlib-compressed data without adler32 checksum
body: <h3>Update 2 (newest)</h3>
  <p>Here's the situation:</p>
  <p>A foreign application is storing zlib deflated (compressed) data in this format:</p>
  <p><code>78 9C BC (...data...) 00 00 FF FF</code> - let's call it DATA1</p>
  <p>If I take original XML file and deflate it in Java or Tcl, I get:</p>
  <p><code>78 9C BD (...data...) D8 9F 29 BB</code> - let's call it DATA2</p>
  <ol>
  <li>Definitely the last 4 bytes in DATA2 is the Adler-32 checksum, which in DATA1 is replaced with the zlib FULL-SYNC marker (why? I have no idea).</li>
  <li>3rd byte is different by value of 1.</li>
  <li>The <code>(...data...)</code> is equal between DATA1 and DATA2.</li>
  <li><strong>Now the most interesting part</strong>: if I update the DATA1 changing the 3rd byte from <code>BC</code> to <code>BD</code>, leave last 8 bytes untouched (so <code>0000FFFF</code>) and inflating this data with <code>new Inflater(true)</code> (<a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/Inflater.html#%3Cinit%3E(boolean)" rel="nofollow noreferrer">https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/Inflater.html#%3Cinit%3E(boolean)</a>), I am able to decode it correctly! (because the Inflater in this mode does not require zlib Adler-32 checksum and zlib header)</li>
  </ol>
  <h5>Questions:</h5>
  <ol>
  <li>Why does changing <code>BC</code> to <code>BD</code> work? Is it safe to do in all cases? I checked with few cases and worked each time.</li>
  <li>Why would any application output an incorrect (?) deflate value of <code>BC</code> at all?</li>
  <li>Why would the application start with a zlib header (<code>78 9C</code>), but not produce compliant zlib structure (FLUSH-SYNC instead of Adler-32)? It's not a small hobby application, but a widely used business app (I would say dozens of thousands of business users).</li>
  </ol>
  <s>
  ### Update 1 (old)
  <p>After further analysis it seems that I have a zlib-compressed byte array that misses the final checksum (adler32).</p>
  <p>According to RFC 1950, the correct zlib format must end with the adler32 checksum, but for some reason a dataset that I work with has zlib bytes, that miss that checksum. It always ends with <code>00 00 FF FF</code>, which in zlib format is a marker of SYNC FLUSH. For a complete zlib object, there should be adler32 afterwards, but there is none.</p>
  <p>Still it should be possible to inflate such data, right?</p>
  <p>As mentioned earlier (in original question below), I've tried to pass this byte array to Java inflater (I've tried with one from Tcl too), with no luck. Somehow the application that produces these bytes is able to read it correctly (as also mentioned below).</p>
  <p>How can I decompress it?</p>
  <h3>Original question, before update:</h3>
  <h5>Context</h5>
  <p>There is an application (closed source code), that connects to MS SQL Server and stores compressed XML document there in a column of <code>image</code> type. This application - when requested - can export the document into a regular XML file on the local disk, so I have access to both plain text XML data, as well as the compressed one, directly in the database.</p>
  <h5>The problem</h5>
  <p>I'd like to be able to decompress any value from this column using my own code connecting to the SQL Server.</p>
  <p>The problem is that it is some kind of weird zlib format. It does start with typical for zlib header bytes (<code>78</code> <code>9C</code>), but I'm unable to decompress it (I used method described at <a href="https://stackoverflow.com/questions/33020765/java-decompress-a-string-compressed-with-zlib-deflate">Java Decompress a string compressed with zlib deflate</a>).</p>
  <p>The whole data looks like <code>789CBC58DB72E238...7E526E7EFEA5E3D5FF0CFE030000FFFF</code> (of course dots mean more bytes inside - total of 1195).</p>
  <h5>What I've tried already</h5>
  <p>What caught my attention was the ending <code>0000FFFF</code>, but even if I truncate it, the decompression still fails. I actually tried to decompress it truncating all amounts of bytes from the end (in the loop, chopping last byte per iteration) - none of iterations worked either.</p>
  <p>I also compressed the original XML file into zlib bytes to see how it looks like then and apart from the 2 zlib header bytes and then maybe 5-6 more bytes afterwards, the rest of data was different. Number of output bytes was also different (smaller), but not much (it was like ~1180 vs 1195 bytes).</s></p>