Closed FerrielMelarpis closed 9 years ago
Is this the same issue as https://github.com/pieroxy/lz-string/issues/26 ?
I think so thanks for the info so there really is as bug in some cases ? but the javascript port author said that it happens for long string but it my case it happens often even if the string length is short like : '{a : "abcdef", b : "123213"}' Well if I have free time I could go look into this issue.
but the issue i mentioned should not result in gabage string or null. the string after compress differ with one character and it can be suceessfully decompress is something happened in the newer version of LZ-string?
can u give your using version of LZ-string and the test string?
//java code
public class Test { public static void main(String[] args) { String compressed = LZString.compress("abcdef123456"); System.out.println(compressed); // produces "ↂテɠꘆ悌ɠ㌀堊쀶" String decompressed = LZString.decompress("ↂテɠꘆ悌ɠ㌀堊쀶"); System.out.println(decompressed); // produces "abcdef123456" } }
//javascript LZString.decompress('ↂテɠꘆ悌ɠ㌀堊쀶'); // produces empty string //another weird thing js compress method adds extra space character at the end LZString.compress('abcdef123456'); // produces "ↂテɠꘆ悌ɠ㌀堊쀶 " but if decompressed in java still returns 'abcdef123456'
Is the fact that javascript uses UTF-16 char encoding and java uses UTF-8 relevant to this issue ?
All right, i wrote a test. And find that:
The newest master branch of javascript lz-string The 1.3.3 version(the version i port) The 1.0.2 version(the version pieroxy suggested to port)
All the 3 versions can successfully decompress the encoded "abcdef123456" in my rhino testing case(you can test it again yourself to prove this)
The encoded string somehow differs from yours, there is a NON-PRINTABLE character after ↂテɠꘆ悌ɠ㌀堊쀶 , which has an hexcode as 0x80 or something like that Are you just missed or ignored the NON-PRINTABLE character? Or some of your source control does not allow NON-PRINTABLE character? If your project need all character printable to transfer, maybe you should use the [Base64] form of api, both at javascript side and java side.
i think i can close this issue now.
I used javascript for the frontend and java for backend with my project. The scenario is that when I compress a string in javascript using LZString.compress() method and send it to the server, the server decompresses it successfully, but when the decompressed string is compressed using LZString.compress() in the server (w/c is java), it produces a different string compared to the string produced in the compress method of javascript implementation (somehow it looks like it's missing one byte or so). So when I tried to decompress the compressed string I received from the server, the result is null or sometimes garbage characters. The compress() method is the only one that does this, the other methods returns the same string as the counterpart compress() method in javascript : compressToUTF16, compressToBase64