Since version 1.4.0-alpha, for some inputs, the output of compressToUTF16 ends with an extra space character compared to what versions 1.3.3 to 1.3.9 do.
For example, for 5-character input "rstuv" the output of compressToUTF16, expressed in big-endian hex, is
in version 1.3.9: 09e3 1c2b 417c 0704 0020
in version 1.4.1: 09e3 1c2b 417c 0704 0020 0020
This does not break interoperability, but is unfortunate, and goes in the direction opposite to what the release notes state:
Binary compatibility for compression is not guaranteed, meaning the output from this version may be different than the output produced by an older version. This is trailing characters that are useless that are now omitted.
That clearly has to do with the code there:
compressToUTF16 : function (input) {
if (input == null) return "";
return LZString._compress(input, 15, function(a){return f(a+32);}) + " ";
},
But a fix is NOT as simple as removing + " " which would loose binary compatibility for decompression with versions 1.3.9 and earlier (e.g. "r" would compress to 09e8 which fails to decompress on 1.3.9).
François Grieu
Since version 1.4.0-alpha, for some inputs, the output of compressToUTF16 ends with an extra space character compared to what versions 1.3.3 to 1.3.9 do.
For example, for 5-character input "rstuv" the output of compressToUTF16, expressed in big-endian hex, is
in version 1.3.9: 09e3 1c2b 417c 0704 0020
in version 1.4.1: 09e3 1c2b 417c 0704 0020 0020
This does not break interoperability, but is unfortunate, and goes in the direction opposite to what the release notes state:
That clearly has to do with the code there:
But a fix is NOT as simple as removing
+ " "which would loose binary compatibility for decompression with versions 1.3.9 and earlier (e.g. "r" would compress to 09e8 which fails to decompress on 1.3.9).François Grieu