Java中byte[]转换成String有数据丢失现象，原byte[]长度为6714转换成String被截断成6400，请教各位高手

该问题是在HTTP通信过程中发现的，本地接收到的字符数没问题，但是在转换成String过程中出问题了。字符串发送时采用UTF-8的格式，客户端默认也是采用UTF-8，以下方法试过，不管加不加字符集限制都是一样String bString = new String(byets);

举报该问题

其他回答

第1个回答 2011-10-14

转换时要指定bytes的实际汉字编码，
比如 String s=new String(bytes, "GBK");
应该就能无误解决
如果还有问题，请给出数据样本，乱码请以十六进制或Base64提供出来，可以帮你分析追问

问题依旧，文件长度增长了91位应该是编码改变造成的。主要代码
BufferedHttpEntity bhe = new BufferedHttpEntity(httpResponse.getEntity());
BufferedInputStream bufferedInputStream = new BufferedInputStream(
bhe.getContent());
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
bhe.writeTo(byteArrayOutputStream);
String bString = byteArrayOutputStream.toString();

追答

包括上面的代码样本，还要数据样本

追问

全长是：6714差不多都是重复的数据（数据为JSON格式）
{"ComTicketList":[{"createTime":"2011-10-14 09:39:46","logo":"icp/upload/images/comticket/ZH6_093946.png","oldPrice":109.8,"status":1,"combinationPublish":"发行商家","rebateCouponList":[],"show":1,"number":"ZH6","voucherList":[],"endTime":"2011-11-05 00:00:00","exchangeTicketList":[{"createTime":"2011-10-08 11:59:47","logo":"icp/upload/images/

追答

给出:出现差异的最小数据。。
这种纯文本的数据看，出现数据变异的情况不多。
注意编码的匹配和对换行的正确处理。

“不管加不加字符集限制都是一样”
============
这种认识是荒谬的，不加字符集的方法就是错误的写法，已经被java标准淘汰了。
不注意细节才会有差异，错误的思想惯性导致问题发生而又不能解决。我个人是不会被任何有规范编码的情况所阻碍。

追问

截断位置数据："oldPrice":36.9,"usePlace":"用?
正常数据是："oldPrice":36.9,"usePlace":"用地点","status":1,。。。。。。。。。。。
百度就是有文件长度限制，要不然可以将两个文件上传。
字符集我已经试过"GBK"，"UTF-8"都不行。该字符串是程序自动写入的，没有回车换行符。
imkow ：可以在QQ上面聊吗？可以提供更多数据

追答

看这个断法，像是你“分多次”读取或写入bytes，比如固定读取缓冲为6400，读半截转换半截，导致在汉字中间截断了，没法转码。应该以某个整体单位(比如一个文件，一个json对象)读入后再一起转String。

我这台只装有百度hi，可以加imkow。

第2个回答 2011-10-14

额你也不想想String长度6400是什么概念
建议用StringBuffer追问

改用StringBuffer结果还是不行

追答

有没有想过是该问题是在HTTP通信过程中发现的，通信过程中管道中的数据最大长度是6400 也就是向管道写数据，没有达到6400之前流一直没有刷新，6400长度时流里边满了自动涮新了，后面的数据被丢弃了？
试着通信时先传整个字节长度（可用前四个字节），传递一定长度刷新一下，在接收方接收时，根据前四个字节读取指定长度的信息

追问

刚刚问题解决了，如你所说是编码的问题，服务器采用的数据编码是：“ISO-8859-1”所以解析出错。现在发现一个问题是在客户端接收的时候有乱码。在刚刚接收数据时如何转码成“UTF-8”，很感谢写你的回答。分应该给你。

本回答被提问者采纳

相似回答

大家正在搜