我正在编写的一个Android应用程序获取使用LZString压缩的数据并以base 64发送。我在Java中将this implementation用于LZString，而在PHP中则使用this one。这两种实现都是LZW原始JavaScript端口作者的最高推荐listed here。
我很难理解为什么PHP发送的LZString数据会抛出Java中的异常。经过大量的试验和紧张的紧张，我最终得出结论，这个问题归结为Java预期的明显填充，而PHP发送的数据中却缺少该填充。以以下为例
Original String being compressed
贝蒂买了一点黄油，但是很苦，所以她买了一些更好的黄油，使苦黄油变得更好
我用来测试的句子，因为它带有多次重复，很可能压缩得很好。
LZString的PHP实现吐出以下字节数组
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
而Java实现生成以下字节数组
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**
您会注意到Java实现标记在附加的**AA==**上。
我可以紧要理解为什么会有==-填充以达到所需的长度倍数。但是，我不明白AA的原因或来源。
我在Java LZString.decompressFromBase64上做了一个附加AA==标记后，发现它可以工作。另一方面，仅标记==会引发异常。进一步的实验表明，====上的标记起作用了，BB==也是如此，表明这四个字节只是用于填充而没有其他用途。
在这一点上，我可以很简单地在执行LZString.decompressFromBase64之前在Java中适当地添加填充。但是，我担心这将是在不完全了解此处发生情况的情况下实施的“解决方案”。也许这里有人可以照亮？