title: LZString compressed data between PHP and Java
body: <p>An Android app that I am writing acquires data compressed using LZString and sent out as base 64.  I am using <a href="https://github.com/diogoduailibe/lzstring4j/blob/master/src/com/diogoduailibe/lzstring4j/LZString.java" rel="nofollow noreferrer">this implementation</a> for LZString in Java along with <a href="https://github.com/nullpunkt/lz-string-php" rel="nofollow noreferrer">this one</a> in PHP. Both of these implementations are the top recomendations <a href="http://pieroxy.net/blog/pages/lz-string/index.html#inline_menu_7" rel="nofollow noreferrer">listed here</a> by the author of the original JavaScript port of LZW.</p>
  
  <p>I have had a really tough time understanding why the LZString data sent out by PHP throw up exceptions in Java.  After much experiment and frayed nerves I have eventually worked out that the issue is down to apparent padding that is expected in Java and is missing in the data sent out from PHP.  Take the following as examples</p>
  
  <pre><code>Original String being compressed
  </code></pre>
  
  <blockquote>
    <p>Betty bought a bit of butter but it was bitter so she bought some better butter to make the bitter butter better</p>
  </blockquote>
  
  <p>a sentence I use for testing since with it multiple repetitions it is likely to compress well.  </p>
  
  <p>The PHP implementation of LZString spits out the following byte array</p>
  
  <pre><code>69 73 85 119 76 109 67 101 65 69 66 71 68 50 66 88 65 53 103 67 122 78 65 
  104 110 65 108 104 43 65 90 110 73 104 67 65 69 55 69 90 55 81 68 117 109 65 
  122 114 113 82 102 102 78 80 97 105 72 69 109 104 113 119 76 90 100 89 52 77 
  79 85 113 105 75 89 78 118 48 119 66 114 76 109 69 53 77 74 52 115 99 79 90 
  65
  </code></pre>
  
  <p>while the Java implementation generates the following byte array</p>
  
  <pre><code>69 73 85 119 76 109 67 101 65 69 66 71 68 50 66 88 65 53 103 67 122 78 65 
  104 110 65 108 104 43 65 90 110 73 104 67 65 69 55 69 90 55 81 68 117 109 65 
  122 114 113 82 102 102 78 80 97 105 72 69 109 104 113 119 76 90 100 89 52 77 
  79 85 113 105 75 89 78 118 48 119 66 114 76 109 69 53 77 74 52 115 99 79 90 
  65 **65 65 61 61**
  </code></pre>
  
  <p>You will note that the Java implementation tags on extra <code>**AA==**</code>.  </p>
  
  <p>I can at a pinch understand why there is an <code>==</code> - padding to get to the desired length multiple.  However, I cannot understand why or where the AA are coming from.  </p>
  
  <p>I tested <code>LZString.decompressFromBase64</code> in Java after tagging on an additional <code>AA==</code> and found that it works.  On the other hand simply tagging on an <code>==</code> threw an exception.  Further experiment revealed that tagging on <code>====</code> worked and so too did <code>BB==</code> indicating that these four bytes are simply used for padding and not put to any other use.</p>
  
  <p>At this point I could quite simply append padding as appropriate in Java prior to doing <code>LZString.decompressFromBase64</code>.  However, that I fear that would be a "solution" implemented without a full understanding of what is happening here.  Perhaps someone here can shed some light?</p>