2014-07-01 57 views
4

我正在使用LZString.compressToBase64函數lz-string.js,需要解壓縮/壓縮服務器端的數據。在客戶端上用lz-string.js編碼的.NET服務器上壓縮/解壓縮字符串

明顯的解決方案似乎是lz_string_csharp但我擔心

這樣的說法:

如果你只使用常規的JavaScript「壓縮」功能,然後根據數據字符串中,它將不會在C#端正確解壓縮。但是,如果您使用的是C#版本中內置的「壓縮」功能,那麼您應該可以使用常規的「解壓縮」功能。

和關於這個報告的問題:possible bug in c# version of compressToBase64

回答

1

在你給的鏈接的完整描述說,你應該能夠使用「compressToUTF16」,它會一直工作,而不是隻是「壓縮」,這將不會一直工作。

我已經親自測試過,看到它有效。 (儘管我將C#文件中的Context_Compress_Data.str字段從一個字符串更改爲StringBuilder,因爲它運行速度太慢,之後只需8秒鐘即可處理8 MB JSON文件並將其壓縮到7%原始大小。)

+0

我改變了對海峽StringBuilder的太多,但還是走了幾分鐘,1MB JSON – jsicary

+1

我的代碼是在這裏,如果你想嘗試一下:https://github.com/jawa-the-hutt/lz-string-csharp/issues/7 – Richard

+0

謝謝。我改變了所有字符串連接以使用StringBuilder,並且我能夠看到性能的急劇增加。爲什麼不是這個答案? – jsicary

0

我們通過以下(StringBuilder的版本之前original file線580)

從我記得,這個bug被ENC1的價值觀造成的,ENC2加入兩行之間enc1 = enc2 = enc3 = enc4 = 0;固定這等等......在每個循環開始時不會被重置,所以有時候循環的新迭代在前一輪中有錯誤的值。

i += 3; 

        enc1 = enc2 = enc3 = enc4 = 0; 

        enc1 = (int)(Math.Round(chr1)) >> 2; 
相關問題