4

I am using the LZString.compressToBase64 function of lz-string.js and need to decompress/compress the data on the server side.

The obvious solution seems to be lz_string_csharp but I am concerned about

this statement:

If you use just the regular Javascript 'compress' function then depending on the data in the string, it will not decompress correctly on the C# side.

However, if you are using the 'compress' function built into this C# version, then you should be ok to use the regular 'decompress' function included.

and about this reported issue: possible bug in c# version of compressToBase64

Community
  • 1
  • 1
CodeToad
  • 4,656
  • 6
  • 41
  • 53

2 Answers2

1

The full description in the link you give says that you should be able to use 'compressToUTF16' and it will always work, rather than just 'compress', which won't always work.

I've tested it personally and seen that it works.

(Though I changed the Context_Compress_Data.str field from a string to a StringBuilder in the C# file, because it was too slow to run. After that it took only 8 seconds for an 8 MB JSON file and compressed to 7% of the original size.)

Richard
  • 14,798
  • 21
  • 70
  • 103
  • I changed the str to a StringBuilder too, but still is taking several minutes for a 1MB JSON – jsan Jul 17 '15 at 16:18
  • 1
    My code is here if you want to try it: https://github.com/jawa-the-hutt/lz-string-csharp/issues/7 – Richard Jul 17 '15 at 19:32
  • Thank you. I changed all string concatenations to use StringBuilder and I was able to see a dramatic increase in performance. Why isn't this the answer? – jsan Jul 17 '15 at 20:27
  • I see the full description in the answer, but I specifically need the base64 version. Someone on me team eventually fixed the bug that was causing this, by adding one line code at line 580 in the original file (before string builder) see new answer for details – CodeToad Mar 15 '17 at 10:06
0

We fixed this by adding enc1 = enc2 = enc3 = enc4 = 0; between the two rows below (line 580 in original file before stringbuilder version)

From what I remember, the bug was caused by the values of enc1, enc2, etc... not being reset at the start of each loop, so sometimes a new iteration of the loop had wrong values from the previous round.

  i += 3;

                    enc1 = enc2 = enc3 = enc4 = 0;

                    enc1 = (int)(Math.Round(chr1)) >> 2;
CodeToad
  • 4,656
  • 6
  • 41
  • 53