然后按照算法实现压缩代码，调用接口就可以
常见的 可以使用哈夫曼编码压缩，或者使用开源的压缩代码，比如lzo, gzip, lzma等等。
听他瞎吹，关于Java方面我不了解，但是对于.net方面，使用GZip进行压缩的并没有在前边多出4个字节！我也很奇怪，所以进行了测试，（我测试了4.0和4.52两个版本）至于为什么是四个字节，非固定块加密时（固定块表示每块长度固定），一般要说明其块长度，而这个一般使用的是4个字节的整数（.net中的Int32/int)，不同语言的可能定义也不同，但这个4个字符来源于GZip的规定用四个字节来说明长度（低位在前，高位在后）。所以不管是哪个语言，不管4个字节是叫int(.net）还是叫long(C++）都必须使用4个字节的。
但从头到尾均没有出现在前边有四个字节的说法！且我也没有听说过，因为GZip是一种压缩算法，这种算法是否在前边存在有字节长度的说明，是算法规定好的！所以我的第一反应就是不可能的——GZip有自己的标准，难道某个语言实现时不按标准来吗？
那么是不是有可能出现两种语言无法解压的情况呢？标准之所以称之为标准，两种语言实现时必须按相同的标准，换句话来说标准本身就必须在不同的语言实现达到一个统一转换的过程。不可能用.net的MD5到Java中验证不了，也不可能.net的GZip压缩到Java中解压不了！
那么为什么会出现某些人说的无法解压的情况呢？因为死读书的程序员导致的！标准是标准，但标准中也往往有不同的选择！比如在GZip压缩中就有快速/优化两种压缩方式，当然这两处方式。而不在同语言中所使用的默认压缩方式不同，另一种语言中的默认解压方式不同，就会出现无法匹配的情况。
我举个例子吧，好多人在问DES加解密Java与.net不对称，我觉得不可能，后来才知道，一边默认压缩，另一连默认解压，问题在于.net默认是CBC格式，而Java中恰恰不是！这就导致加解密错误的原因。事实上我即使在不跨语言时也会经常指明格式，所以我倒是没有遇到这种情况。
比如 GZipStream stream = new GZipStream(baseStream, CompressLevel.Faster,true)试试这个，但不管怎么说，你若去掉四个字节，在Android中的出错就表示，其实你去错了！
