背景:
php发送的json格式字符串,送到前台的flex项目后,解析出错。花了2天时间搞定。特此备忘
仔细跟踪后,发现是json包里面的charat函数出错。再仔细反过来跟踪。发现问题出在这里:
flex项目定义的字符串,比如:var ss:* = “head”,然后他的ss.length = 5。 是的,没错,长度不是4,偏偏变成5了。
这个根本性的问题,导致json包decode时直接出错返回了。
ss.charat(0) = "",而不是正常的ss.charat(0)=“h”;
这个是怎么一回事呢?网上反复搜索不得结果。后来用如下函数ss.charCodeAt(0)后,发现返回值是65279.
这个在ascii码里是找不到的。没办法,再搜索65279.幸运的找到相关资料了:
unicode编码为65279的字符叫“ZERO WIDTH NO-BREAK SPACE”即没有宽度的空格符,本质上也是null值,
但是不同于null。byte-order mark(BOM)是位于码点U+FEFF的统一码字符的名称。
当以UTF-16或UTF-32来将UCS/统一码字符所组成的字符串编码时,这个字符被用来标示其字节序。
它常被用来当做标示文件是以UTF-8、UTF-16或UTF-32编码的记号。
说白了就是位于文本最前面用来标识该unicode编码的文本内容是以UTF-8、UTF-16或UTF-32编码的。
通过查询发现windows的记事本程序在打开文本内容后会自动添加BOM,
我怀疑是那个模块在编码的时候用记事本编辑过代码,然后在模板或其他可能的文件中添加了BOM。
解决方法:判断字符串第一位的unicode编码值是否是65279,如果是则处理完再转换。
据此,我把自己改下的json包里面的方法抄写如下:
private function nextChar():String {
if(loc == 0)
{
var unicode:* = jsonString.charCodeAt(0);
if(unicode == 65279)
{
loc ++;
}
return ch = jsonString.charAt( loc++ );
}
else
return ch = jsonString.charAt( loc++ );
}