系统编码

http://www.591pic.com


左脚耐克，右脚阿迪达，记得在哪听过这句话。 

现在是左手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范围内字符用一个字节表示,中文等时用大于一个字节表示，造成“字符不等长”。 



在习惯了调用现成方法编码解码之后，面对突然变化的情况，人很容易被惯性推进迷茫。只有 退，思，辨才能洞见本质，细微处入手，所谓“以无间入有间”。 


群木难舟 一苇渡江 善哉

  最后修改于2008-12-5 10:49:00

 

技术交流论坛      http://www.591pic.com