1.0.2 and 1.33 NOT completely binary-compatible in 'compress' method

[rufushuang]

when the encoding string is long enough, there will be ONE Character size difference.

for the following file:
“hello1hello2hello3hello4hello5hello6hello7hello8hello9helloAhelloBhelloChelloDhelloEhelloF”

compress("hello1hello2hello3hello4hello5hello6hello7hello8hello9helloAhelloBhelloChelloDhelloEhelloF").length()

1.3.3 ver result length is 23.
1.0.2 ver result length is 22.

1.3.3 ver add a ZERO character at the end of the string.

This issue makes the "Porting to other languages" on blog cannot be achieved.
AS:
"
Port the compress and/or decompress methods from the version 1.0.1. All versions are binary-compatible and further versions just incorporate ugly optimizations for JavaScript, so you shouldn't bother.
Port the (de)compressToBase64 and/or (de)compressToBaseUTF16 from the latest version depending on your needs.
"

[rufushuang]

should I just port with the 1.3.3 ver instead?
But the code in 1.3.3 is full of replication.

anyway, done porting to java, at https://github.com/rufushuang/lz-string4java
compress method in 1.3.3 and uncompress method in 1.0.2. All others in 1.3.3.

[pieroxy]

I'll need to have a look at this. Thanks for reporting it.

[pieroxy]

This seems to happen on some corner case of the algorithm. Probably some padding when the last byte is full of bits.

The good news it that both versions are able to successfully decompress the compressed version of both versions. No issue apart from an extra character. Compression and decompression work across versions.

The bad news is that I'm too lazy to investigate this, so I'll just close the issue ;-(