网络请求中的多种编码乱码问题

Java中涉及编解码操作的4个主要场景：内存，I/O操作、Java Web、数据库。

> HTTP请求头编码和压缩
HTTP Header中Accept-Encoding 是浏览器发给服务器,声明浏览器支持的编码类型的，常见的有：
       Accept-Encoding: compress, gzip　　　　　　　　　　　//支持compress 和gzip类型 
       Accept-Encoding:　　　　　　　　　　　　　　　　　　 //默认是identity 
       Accept-Encoding: *　　　　　　　　　　　　　　　　　 //支持所有类型 
       Accept-Encoding: compress;q=0.5, gzip;q=1.0　　　　　//按顺序支持 gzip , compress 
       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0  // 按顺序支持 gzip , identity 
服务器返回的对应的类型编码header是 content-encoding 

-- gzip是一种数据格式，默认且目前仅使用deflate算法压缩data部分；deflate是一种压缩算法,是huffman编码的一种加强。deflate与gzip解压的代码几乎相同，可以合成一块代码。
 deflate与gzip的区别仅有：
 deflate使用inflateInit()，而gzip使用inflateInit2()进行初始化，比 inflateInit()多一个参数: -MAX_WBITS，表示处理raw deflate数据。因为gzip数据中的zlib压缩数据块没有zlib header的两个字节。使用inflateInit2时要求zlib库忽略zlib header。在zlib手册中要求windowBits为8..15，但是实际上其它范围的数据有特殊作用，见zlib.h中的注释，如负数表示raw deflate。
 Apache的deflate变种可能也没有zlib header，需要添加假头后处理。即MS的错误deflate (raw deflate).zlib头第1字节一般是0x78, 第2字节与第一字节合起来的双字节应能被31整除，详见rfc1950。例如Firefox的zlib假头为0x7801，python zlib.compress()结果头部为0x789c。
 deflate 是最基础的算法，gzip 在 deflate 的 raw data 前增加了 10 个字节的 gzheader，尾部添加了 8 个字节的校验字节（可选 crc32 和 adler32） 和长度标识字节。

  因为设置了Accept-Encoding: gzip,deflate，所以服务器返回的是压缩后的数据，而本地客户端却没有对这些数据进行解压缩因此得到的便是一堆乱码了。
  解决方案就是去掉Accept-Encoding: gzip,deflate 直接让服务器返回文本。

> 浏览器打开HTML页面(UTF-8编码)是总是乱码，在网页中加入 <meta chartset=UTF-8 > 
记事本的话，默认保存的文件格式是ANSI。所以在保存的时候要修改为UTF-8。

> 发起请求时设置：httpURLConnection.setRequestProperty("Charset", "utf-8");
拼接参数时：转一下格式：URLEncoder.encode(String.valueOf(value), "utf-8")