搏一搏单车变摩托

今天晚上遇到了一个问题，后台给我返回状态码，我转成int来根据状态提示对应的内容，但是神奇的事情发生了，抛了NumberFormatException异常，那么NumberFormatException是什么呢，来回顾下，类型转换异常，那么什么情况下会触发他呢

既然分析完原因我检查了一下我遇到的情况，首先我需要转换的数字是151，所以第一条和第三条不成立，至于第二条
去除字符串中的空格

可以看到在53和54行的时候我已经做了剔除空格以及换行的处理

可是为什么不行呢，我尝试了自己手打一个字符串15然后尝试转换，what? 居然成功了？什么鬼，我赶紧换成服务器返回的数据又试了一次，结果还是一样，
既然手打的可以那么问题肯定是出在字符串上了，为了对比两个字符串有什么不同，我把两个字符串转成了byte数组，果然发现了问题

可以看到第一条日志是服务器返给我的状态码，第二条是我自己手打的状态码
重点在转成数组之后，服务器返给我的状态码转成数组居然多了三个字节？？？什么情况！

到了这一步，基本可以确定后台返回的状态码有问题，虽然看起来都一样，但是却比正常的字符串多了三个字节，那到底是怎么回事呢，

到了这一步如果后台是其他人写的你就可以和他说返回的字符带65279隐形字符，基本他就明白咋回事了

但是很不巧，后台也是本渣渣写的我们来看一下后台代码
这里写图片描述

可以看得到后台并没有做什么只是按条件查询根据情况返回相应的状态码，也是一个‘普普通通的字符串’，那么为什么到了APP哪里就会多出来三个字节呢？

经过查阅大量资料终于发现问题，那就是原来后台接口编码格式为utf-8且带有BOM

何谓BOM？
“EF BB BF” 这三个字节就叫BOM，全称是”Byte Order
Mard”。在utf8文件中常用BOM来表明这个文件是UTF-8文件，而BOM的本意是在utf16中用。

　　utf-8文件在php中输出的时候bom是会被输出的，所以要在php中使用utf-8，必须要是使用不带bom头的utf-8文件。

又称65279字符，这个65279字符是php用来标记文件是utf-8编码的，输出的时候会一起输出到客户端，导致客户端如果使用客户端得到返回值时，无法匹配字符串，解决方法如下

解决方法

1、使用ultraedit时，另存时会有“UTF-8”和“UTF-8 - 无BOM”两种选择。
2、 window的记事本保存的是带bom的。
3、EditPlus软件不同版本对utf-8的保存支持不一样，例如：2.31版本保存的是不带bom的，2.11版本保存的是带bom的。

附上一篇不错的分析链接
文章地址传送门