在.NET服务器上压缩/解压字符串，该字符串在客户端使用lz-string.js进行编码

Question

我正在使用lz-string.js的LZString.compressToBase64函数，需要在服务器端进行数据的解压缩/压缩。

显然的解决方案似乎是lz_string_csharp，但我对于以下声明感到担忧：

如果您只使用常规的 JavaScript 'compress'函数，则根据字符串中的数据，它将无法在 C#端正确地解压缩。 但是，如果您使用内置在此C＃版本中的'compress'函数，则应该可以使用包含的常规'decompress'函数。

并且关心这个问题：可能存在压缩ToBase64的C#版本的错误报告。

- CodeToad

Answer 1

你提供的链接中的完整描述说，你应该能够使用'compressToUTF16'并且它总是有效的，而不仅仅是'compress'，后者并不总是可用。

我亲自测试过，并且发现它可以正常工作。

（不过我已经在C#文件中将Context_Compress_Data.str字段从字符串更改为StringBuilder，因为运行速度太慢了。这之后，一个8MB的JSON文件只需要8秒钟就压缩到原始大小的7%。）

- Richard

---

我也将str更改为了StringBuilder，但是对于1MB的JSON仍然需要几分钟。 - jsan

如果您想尝试，请在此处查看我的代码：https://github.com/jawa-the-hutt/lz-string-csharp/issues/7 - Richard

谢谢。我将所有字符串连接更改为使用 StringBuilder，我能够看到性能显著提高。为什么这不是答案？ - jsan

我在答案中看到了完整的描述，但我特别需要base64版本。我的团队中的某个人最终通过在原始文件中的第580行（在字符串构建器之前）添加一行代码来修复导致此问题的错误，请参见新答案以获取详细信息。 - CodeToad

Answer 2

我们通过在下面两行之间添加 enc1 = enc2 = enc3 = enc4 = 0; （原始文件的580行，在stringbuilder版本之前）来解决这个问题。

据我记得，这个bug是由于enc1、enc2等的值没有在每次循环开始时重置，因此有时循环的新迭代会从上一轮中获得错误的值造成的。

  i += 3;

                    enc1 = enc2 = enc3 = enc4 = 0;

                    enc1 = (int)(Math.Round(chr1)) >> 2;

- CodeToad