您所在位置：主题：[原创]j2me与.net WebService传输中文乱码解决方法
lostsky22
[专家分：30] 发布于 2008-12-05 10:44:00
[size=3]自己站里一篇旧文[/size]
[size=4][color=FF0000][url]http://www.591pic.com[/url][/color][/size]
[size=3]左脚耐克，右脚阿迪达，记得在哪听过这句话。
现在是左手N70，右手N95。
三月份做的那个移动物流项目进入收尾，突然要增加终端定位功能，在专用GPS设备上开发已经来不及了，公司决
定在手机终端上开发。就这样，带GPS模块的机皇N95就屈尊到了我手里，小爽了一把。
正事归正事，在原有模块上做了一周多，碰到一个奇怪的问题。终端获取GPS定位信息后，需要周期性上传至服务
器，终端是通过JSR172来调用服务端的WEBSERVICE，当传入的参数为中文时，服务器数据库中记录的数据就为
乱码，当参数为英文或阿拉伯数字时，就正常(废话：英文都成乱码，那计算机不是疯了？！呵呵)
初步判断是由于终端和服务端码制不同造成的。
比如：public String sendMessage(String message) 有一个这样的方法。
当传入参数message为中文时，服务器端接收到的就是乱码，但该方法却能正常返回中文
查询到的手机系统编码是：iso-8859-1，服务器端的编码方式为UTF-8。
尝试过在手机端将字符串用iso-8859-1打成字节数组，然后用UTF-8组成新字符串，
如： message=new String(message.getBytes("iso-8859-1"),"UTF-8"); 服务器端收到的也一样是乱码。
在将iso8859-1,utf-8,gbk这三种编解码排列组合的试过一次后，仍然还是乱码。
一天过去了，
google之，文档查询之，“牛人”咨询之，求神拜佛之，头撞南墙之， 啥没解决之。
翌日上班，看了一会前一天的代码，做了结论：今天估计要接着撞墙，于是继续。
接近中午，正撞得过瘾，突然，一同事失手掉落茶杯，清脆的声音和散落的碎片一下转移了我的注意力。对，就是
打碎！脑子里的灯泡一亮（呵呵，此处纯属蒙太奇效果）。打碎不就行了吗？
在手机端将一个字符串按UTF-8打成字节数组，传到服务器端，然后在服务器端将同样的字符串按UTF-8打成字节数
组，两者比较找差别。
比如：在手机端将“中文测试”按UTF-8打成字节数组，在服务器上也将“中文测试”按UTF-8打成字节数组，两者
肯定不同，因为一样的话就不存在乱码问题了。
经过在多种情况下(中文，英文，数字，特殊符号)对比两个字节数组，发现如下不同：
中文或特殊字符(不在ASCII范围内): j2me端的字节数组与服务器端.net环境下的字节数组，每一个字节都相差25
6。 英文或数字(在ASCII范围内): 一个字符就是一个字节, j2me端与.net服务器端值一样。
规律出来了，剩下的事情就是砍瓜切菜，想怎么来就怎么来：
终端在发送前，将待发送字符串中的字符挨个取出，按UTF-8打成字节数组，当字节数组的长度大于一时，当前字
符即为汉字或特殊字符,则每个字节的值不变；如果字符被打成字节数组的长度等于一，则为ASCII范围内字符，字
节值减去256。
.netWEB服务端：将接收到的字节数组，挨个增加256，然后按“UTF-8”组成字符串即可。
奋战到12点半，终于完成了编写，测试：我在终端传进“帅哥”，服务端数据库里新增记录显示“lostsky_11”，BINGAL
O！乱码问题解决！（呵呵 别倒！其实是传入“我爱北京天安门”，数据库里也如实记录，没有乱码）
解决了问题，回头就该追究原因了，分析如下：
1，java里的byte范围为-128~127, .net中byte的范围为0~255;
2，utf-8处理ASCII范围内字符用一个字节表示,中文等时用大于一个字节表示，造成“字符不等长”。
在习惯了调用现成方法编码解码之后，面对突然变化的情况，人很容易被惯性推进迷茫。只有 退，思，辨才能洞见本质，细微处入手，所谓“以无间入有间”。
群木难舟 一苇渡江 善哉[/size]
[size=4][color=FF0000][url]http://www.591pic.com[/url][/color][/size]
[size=3]左脚耐克，右脚阿迪达，记得在哪听过这句话。
现在是左手N70，右手N95。
三月份做的那个移动物流项目进入收尾，突然要增加终端定位功能，在专用GPS设备上开发已经来不及了，公司决
定在手机终端上开发。就这样，带GPS模块的机皇N95就屈尊到了我手里，小爽了一把。
正事归正事，在原有模块上做了一周多，碰到一个奇怪的问题。终端获取GPS定位信息后，需要周期性上传至服务
器，终端是通过JSR172来调用服务端的WEBSERVICE，当传入的参数为中文时，服务器数据库中记录的数据就为
乱码，当参数为英文或阿拉伯数字时，就正常(废话：英文都成乱码，那计算机不是疯了？！呵呵)
初步判断是由于终端和服务端码制不同造成的。
比如：public String sendMessage(String message) 有一个这样的方法。
当传入参数message为中文时，服务器端接收到的就是乱码，但该方法却能正常返回中文
查询到的手机系统编码是：iso-8859-1，服务器端的编码方式为UTF-8。
尝试过在手机端将字符串用iso-8859-1打成字节数组，然后用UTF-8组成新字符串，
如： message=new String(message.getBytes("iso-8859-1"),"UTF-8"); 服务器端收到的也一样是乱码。
在将iso8859-1,utf-8,gbk这三种编解码排列组合的试过一次后，仍然还是乱码。
一天过去了，
google之，文档查询之，“牛人”咨询之，求神拜佛之，头撞南墙之， 啥没解决之。
翌日上班，看了一会前一天的代码，做了结论：今天估计要接着撞墙，于是继续。
接近中午，正撞得过瘾，突然，一同事失手掉落茶杯，清脆的声音和散落的碎片一下转移了我的注意力。对，就是
打碎！脑子里的灯泡一亮（呵呵，此处纯属蒙太奇效果）。打碎不就行了吗？
在手机端将一个字符串按UTF-8打成字节数组，传到服务器端，然后在服务器端将同样的字符串按UTF-8打成字节数
组，两者比较找差别。
比如：在手机端将“中文测试”按UTF-8打成字节数组，在服务器上也将“中文测试”按UTF-8打成字节数组，两者
肯定不同，因为一样的话就不存在乱码问题了。
经过在多种情况下(中文，英文，数字，特殊符号)对比两个字节数组，发现如下不同：
中文或特殊字符(不在ASCII范围内): j2me端的字节数组与服务器端.net环境下的字节数组，每一个字节都相差25
6。 英文或数字(在ASCII范围内): 一个字符就是一个字节, j2me端与.net服务器端值一样。
规律出来了，剩下的事情就是砍瓜切菜，想怎么来就怎么来：
终端在发送前，将待发送字符串中的字符挨个取出，按UTF-8打成字节数组，当字节数组的长度大于一时，当前字
符即为汉字或特殊字符,则每个字节的值不变；如果字符被打成字节数组的长度等于一，则为ASCII范围内字符，字
节值减去256。
.netWEB服务端：将接收到的字节数组，挨个增加256，然后按“UTF-8”组成字符串即可。
奋战到12点半，终于完成了编写，测试：我在终端传进“帅哥”，服务端数据库里新增记录显示“lostsky_11”，BINGAL
O！乱码问题解决！（呵呵 别倒！其实是传入“我爱北京天安门”，数据库里也如实记录，没有乱码）
解决了问题，回头就该追究原因了，分析如下：
1，java里的byte范围为-128~127, .net中byte的范围为0~255;
2，utf-8处理ASCII范围内字符用一个字节表示,中文等时用大于一个字节表示，造成“字符不等长”。
在习惯了调用现成方法编码解码之后，面对突然变化的情况，人很容易被惯性推进迷茫。只有 退，思，辨才能洞见本质，细微处入手，所谓“以无间入有间”。
群木难舟 一苇渡江 善哉[/size]