上次寫了關於客戶端與服務端傳輸資料的加密，但對大量資料加密操作要花費大量的時間，所以對於大量資料最好進行壓縮後再加密，同時我們平時傳輸的資料如果太多也可以壓縮後再傳輸，我們對zip加密方法對資料加密，先寫**:
public
class
ziputils
/** * 使用zip進行壓縮
* *@param str
* 壓縮前的文字
*@return 返回壓縮後的文字
*/public
static
final string zip(string str) catch (ioexception e) finally catch (ioexception e)
}if (out != null) catch (ioexception e) }}
return compressedstr;
}/**
* 使用zip進行解壓縮
* *@param compressedstr
* 壓縮後的文字
*@return 解壓後的字串
*/public
static
final string unzip(string compressedstr)
bytearrayoutputstream out = null;
bytearrayinputstream in = null;
zipinputstream zin = null;
string decompressed = null;
try
decompressed = out.tostring();
} catch (ioexception e) finally catch (ioexception e)
}if (in != null) catch (ioexception e)
}if (out != null) catch (ioexception e) }}
return decompressed;
}}
我們來分析一下壓縮的效率如果我們的字串很短，我們壓縮的字串會比原來的大
string s = 「,,]}」;
我們的到的結果：
128
163128
但是如果我們的資料很多結果就不一樣了，我們構造乙個字串
public
static
void
main(string args),";
}s4 = s4.substring(0, s4.length()-1);
s4 = "";
system.out.println(s4.length());
string s1 = zip(s4);
system.out.println(s1.length());
string s2 = unzip(s1);
system.out.println(s2.length());
}
結果:
7926
4770
7926
我們可以看到當我們的資料很多時我們的壓縮方法可以很大程度的減小字元的長度，但當我們的資訊量不大時，壓縮演算法所構建的對映表的長度佔的比重很大，壓縮的字串就比原來的字串的長度長，所以我們在使用壓縮演算法時一定要判斷資料的長度，要不然就不一定能夠減小我們要傳輸的資訊量。
串列埠通訊資料位長度對傳輸資料的影響
針對串列埠通訊，關於設定資料位長度對通訊的影響，如圖 在串列埠資料通訊中，會看到串列埠引數設定。其中 資料位 設定，共有四檔選項，分別是8 7 6 5。那麼改變這個引數會對資料的傳輸有什麼影響呢？我來做個試驗，通過示波器觀察通訊過程，能夠分析結果如下 例如資料位設定為5。那麼就相當於規定了每個傳輸位...
串列埠通訊資料位長度對傳輸資料的影響
針對串列埠通訊，關於設定資料位長度對通訊的影響，如圖 在串列埠資料通訊中，會看到串列埠引數設定。其中 資料位 設定，共有四檔選項，分別是8 7 6 5。那麼改變這個引數會對資料的傳輸有什麼影響呢？我來做個試驗，通過示波器觀察通訊過程，能夠分析結果如下 例如資料位設定為5。那麼就相當於規定了每個傳輸位...
string 壓縮 c string 壓縮傳輸
需求 將記憶體中的string壓縮後再通過網路傳輸 測試方法有 c 自帶gzip壓縮演算法 使用7z的開源演算法 參考 c 壓縮 解壓字串 吃辣椒的小毛驢 www.cnblogs.comcompressing using the 7zip lzma algorithm in c beats gzip...