java number 可以用string接收吗

很神奇的，明明就是数字啊，为什么就是要要报错呢

Exception in thread "main" java.lang.NumberFormatException: For input string: "12"
	at java.lang.NumberFormatException.forInputString(Unknown Source)
	at java.lang.Integer.parseInt(Unknown Source)
	at java.lang.Integer.parseInt(Unknown Source)
	at com.simple.Test.main(Test.java:18)

我也是找了研究了两个多小时，各种方法测试，在出错代码的上一行加一个写死的数字字符并转换，不报错

然后突然灵光一闪，为什么不把它转换程字符数组看一下呢

然后就转换成字符数组，断点看了一下，很神奇，第一个字符什么鬼，换行？空的？空格？好像都不是

怀疑是空格，用trim()方法去空格，不行，然后想怎么样子能知道它是个什么字符呢

然后想到Unicode编码，把它弄成Unicode编码瞅瞅，然后就尝试写一下

结果是这样的

feff  ？？？这是啥？为什么会有这个，为了知道它具体值啥，就搜索了Unicode在线转换网站http://www.jsons.cn/unicode/转换了，可是啥也没有，不开心，什么鬼，啥也没有，replace方法也用不了，怎么才能去掉呢，难道这个就没有任何办法了

然后想了一下，正则表达式是不是可以匹配Unicode编码，然后尝试了一下replaceAll("\ufeff")，竟然可以，真的是把我给高兴的啊，难以用语言形容。

然后下班回家之后想在现问题，按照公司的操作步骤一步一步来，什么鬼，怎么可能，为啥重现不了，这bug还认电脑？？？这么神奇？？？

直到我找到了这篇博客，utf-8 bom编码是什么鬼？？？

然后我就在电脑上把新建的那个txt文件用记事本打开，然后另存为，改编码格式

还真有一个编码  带有BOM的UTF-8  的编码？？？（自带黑人问号）

好吧，然后改了一下编码格式，重新运行了一下，嗯，完美的重现了那个bug，还是印证那句话 “没有概率出现的bug，只要条件满足，所有概率出现的bug都是必然出现的” 

嗯？结束了？？？

重要的是解决方法，有时候看起来一样的可能还真的不一样，要想办法把不一样的地方找出来（找不同？）
比如看起来一样的字符串运行起来结果就是不同，就可以把两个看起来一样的字符串转换为字符数组，也许真的不一样呢