看完这篇文章，自己又收获了很多，最后附上自己的一点感想（红字部分），这点感想解决了我在另一篇文章中的疑惑。
utf-8使用三个字节来表示一个汉字（更准确的说，是使用三个字节来表示unicode内码为2048至65535的文字）。
那么，这带来了一个问题。当utf-8使用三个字节来表示一个汉字时，它要求这三个字节的格式为：
1110yyyy 10yyyyxx 10xxxxxx
如果某个字节的前四位满足1110，那么utf-8的解码器，就要求其后的两个字节的前两位都必须是10。若不满足此格式，就会产生解码失败，utf-8解码器使用：0xEF 0xBF 0xBD（这三个字符表示一个“�”）来代替第一个字节，并对第二个字节进行解码，以此类推。
正是因为存在解码失败的可能性，所以当我们误把一个gbk编码的汉字，以utf-8来解码时，就有可能得到“�”字符，即乱码。而且，一旦把gbk误当成utf-8来解码，就有可能把一个汉字的gbk码变成：0xEF 0xBF 0xBD，造成信息的丢失，无法逆向恢复！
在使用java的String类时，这个问题，非常明显：
String org_str = "我"; //假设java环境的内部编码，已经设置为utf-8
byte[] gbk_byte1 = org.getBytes("gbk");
String err_str = new String(gbk_byte, "utf-8"); //把一个gbk的byte组数，当成utf-8来解码，将造成信息丢失
byte[] gbk_byte2 = err_str.getBytes("gbk"); //比较后，会发现gbk_byte1与gbk_byte2已经不一致。把org_str与err_str这两个字符串打印出来，结果如下：
org_str: 我
err_str: ��
因为“我”字的gbk编码里，有两个字节：
0xCE 0xD2 => 11001110 11010010
而utf-8在解码时，遇到11001110时，因为前缀为110，它期望下一个字节的格式为：10xxxxxx，显然不满足所以使用“�”来代替，然后继续解码下一个字节；解码第二字节时，也是同样的错误，所以产生了两个了“�”。
看完这篇文章，有点明白了在http参数传递过程中的问题（在我的另一篇文章中疑惑的问题）。
就是说如果get参数按照gbk编码，如果在tomcat中设置了URIEncoding=“utf-8”,那么就会产生中文数据的不可恢复性。所以在controller类中，如何转换都会是乱码。
为什么说iso-8859-1是无损的数据呢。iso-8859-1是单字节编码，所以在iso-8859-1传输过程中，即便是按照iso-8859-1进行了解码，虽然出现乱码，也可以进行数据的恢复。原因是单字节的编码没有引起字节的变化，我们还可以通过iso-8859-1来解码得到字节数字，再按照相应的编码解码，就得到了原始的中文数据。
