lz-string
lz-string copied to clipboard
pieroxy
Somehow compressToBase64() returns string end with 3 equal sign "==="
Somehow compressToBase64() returns string end with 3 equal sign "===", which is not a valid format by base64 definition. Does this behavior meet your expectation? Thank you.
Example source: abcdef
Result: IYIwxgJgpgZkA===
The faulty code is
switch (res.length % 4) { // To produce valid Base64
and the following switch statement. It should be a mod 3 with cases for 0, 1 and 2.
and thanks for the library; spent a while looking and testing libs for compressing local storage, and yours was by far the best overall that I found.
Yes @pieroxy we love this lib too — will likely implement it when this Base64 bug is squashed. Use the Base64 in testing alot, thanks @linkenmin for the catch and @nickion for the fix!
import lzstring
x = "N4IgLgngDgpiBcIBGAnAhgOwCYgDQgBs0EQYM8QBHASxIAYBaGAOSwAUAOAMzAHY0AYgHcAWtQCuADQD2WNAQBeADyRIhCgIIBFLABlpANQIARAEIBNABIQAVlwCi0gKoBZALwVK4mN4QBGfAB9Ej8/Og46EABfIAAA="
z = lzstring.LZString().decompressFromBase64(x)
y = lzstring.LZString().compressToBase64(z)
print(y)
print(x == y)
The padding is incorrect!
LZString works the other way: For any string, if you compress it and then decompress it, the original and resulting strings will be equal.
The padding changed in a version (I don't remember which one to be honest). What are you trying to achieve here ?
@pieroxy Thanks for your response. Actually, am trying to decompress and compress the value to be equal together. as am trying to call an API with those value which require lzstring compress
Great. There's probably a tiny bit of loss in performance, but this should be nothing to worry about.
Discussion - https://github.com/pieroxy/lz-string/commit/64f2f29cf88aed1c61a11be5e5dc7fca26ed1b33#commitcomment-119254610
Will create a second endpoint that has the correct base64 encoding, and mark the old one as deprecated (in Typescript typing, and a one-time console warning about the old one) - will be released as part of v2, and the other implementations will be poked to support the correct encoding, followed by the old endpoint being removed in v3 and correct encoding being the way forward (no idea of that release date, but not any time soon!)