http接口返回乱码

这几天对接接口出现一个问题，嬿这个中文乱码。

 

小编本身因为这件事浪费了不少时间，所以自然是带有一点情绪，但描述中并没有夸大，也希望各位不管是对接或者是被对接的人能够互相体谅，不要总是踢皮球

 

事情是这样的。

 

接口调用出现了问题，因为中文“嬿”会乱码。

 

接口方一句话：那要看你们往接口传的是什么

 

小编本着心虚的态度赶紧看一下自己的代码（其实心中早已无语，因所有的中文都是按照文档指定的方式传的，且我们系统中文字根本没有出现乱码的现象）

结果一看，对方接口文档里面的gb2312编码的码表里面根本没这个字。

好吧，截图给对方看。

 

接口方：给你个网站，你先看上面能不能解码。

 

小编再次被套路，点进去网站，哎，还真可以解码。神奇了，难道是我学艺不精？？?，而且这个网站上面还真的写着gb2312编解码（后来事实证明，这个网站实际用的是gbk解码！！！！）

此时同事刚好提到gbk可以兼容gb2312的事，小编脑袋一抽，想说那就试试看吧！

结果还真行，此时才发现，真的是套路满满。此时对接口方已是鄙夷满满。

 

接口方：那你就用gbk吧

 

小编好意给的文档里面要改一下的建议完全被无视

这还没完，因为这只是传数据的时候编码错误，还有返回数据时候的数据也不对！！

 

大家请注意，jdk中的httpclient的核心工具包中对于返回数据内容的解码，并不能强制指定编码，而是优先以返回的字符集编码进行解码，没有的时候才是以我们指定的编码进行解码

所以其实接口方根本不需要在文档中告知返回的数据用什么编码，因为这都是在协议头中返回的，就是那个charset=utf-8

而如果接口方硬是传回一个错误的编码，将会导致我们解码失败，一堆乱码。

 

这里小编再次受到接口方的暴击：客户端都可以设置编码的啊！

 

大哥、大叔、大爷！我知道浏览器即使选择了gb2312编码，仍然可以自动兼容到gbk，但是那是客户端，我们是服务端，我们只认协议

最终无奈妥协，在自己代码中做了，如果返回gb2312编码的时候，改用gbk，因为gbk兼容gb2312的