文本处理中unicode字符65279(ZERO WIDTH NO-BREAK SPACE)遇到的有关问题

文本处理中unicode字符65279(ZERO WIDTH NO-BREAK SPACE)遇到的问题
        代码中有一个功能需要将从其他模块返回值中读取的字符串转化为int值（例如：字符串"12345"转化为int值12345，试用java Integer.parseInt()函数即可），但是在程序测试中出现异常

java.lang.NumberFormatException: For input string: "?118158"at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)

将获得字符串输出出来发现是"118158"，但是程序就是输出异常。于是分析了下可能出现的问题。1.字符串两端有空格。2.字符串编码问题。针对问题1在转换前进行trim操作，测试后问题依旧。针对问题2用utf-8编码重新编码字符串，测试后问题依旧。奇怪之余最后想见识见识这个传入的字符串到底是何方神圣！！用"118158"同得到的字符串用equals()做了下对比发现结果为false，但是输出的结果在肉眼看来是一模一样的。将String转换为char[]，然后输出unicode编码后发现其中有一个字符的编码为65279，于是定位问题就是编码为65279的问题了。Google过65279后发现这个字符是Byte order mark。
        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，如果是则处理完再转换为int，否则直接转换。

查看更多 下一篇