JSON字符串带BOM头"ufeff"

调用三方接口返回值JSON字符串带BOM头"\ufeff",JSON解析死活报错。

我是用SpringBoot的RestTemplate调用三方接口的,一开始返回值我是用对象接收返回值,发现一直报错,我以为是RestTemplate的接收转换有问题,就将返回值换成了String类型去接收。接收到字符串后再转JSON、JSON字符串解析死活报错。

接口返回值日志如下:

2020-03-25 13:18:55.687 DEBUG 8595 --- [           main] o.s.web.client.RestTemplate              : Response 200 OK
2020-03-25 13:18:55.688 DEBUG 8595 --- [           main] o.s.web.client.RestTemplate              : Reading to [java.lang.String] as "application/json;charset=UTF-8"
2020-03-25 13:19:57.370 DEBUG 8595 --- [           main] com.hopefun.scm.open.api.EyuanApi        : 返回值:?{"message":"成功","code":"1"}

在IDEA开发过程中,一开始光看返回值打印的日志是看不出来任何毛病的,并且我将这个返回值的JSON字符串复制到Sublime编辑器中也看不出问题所在。

一开始很自信没有Debug查看返回值,后来当我开启了Debug模式后终于发现了问题所在。原来在JSON字符串前面还带着"\ufeff",导致JSON字符串解析报错,原来罪魁祸首是这个玩意"\ufeff"。Debug还是个好玩意啊。

终于发现问题所在解决就轻松多了。

public static final String BOM = "\ufeff";
/**
 * 去除BOM
 *
 * @param bomStr JSON字符串
 * @return 去除BOM后的JSON字符串
 */
private String recursiveBom(String bomStr) {
    String str = "";
    if (bomStr.startsWith(BOM)) {
        str = bomStr.substring(1);
        if (str.startsWith(BOM)) {
            recursiveBom(str);
        }
    }
    return str;
}

//使用,如此得出来的字符串就是纯正的JSON字符串啦。妈妈再也不怕解析报错啦。。。
recursiveBom(bomStr.trim());

赵小胖个人博客

原文地址:https://www.cnblogs.com/Sky0914/p/12608969.html

时间: 2024-10-07 16:02:46

JSON字符串带BOM头"ufeff"的相关文章

生成不带BOM头的UTF-8文件

UTF-8(带BOM):writer = New StreamWriter(FilePathName, True, System.Text.UTF8Encoding.UTF8) UTF-8(不带BOM):writer =New StreamWriter(FilePathName, True, New UTF8Encoding(False)) 生成不带BOM头的UTF-8文件,布布扣,bubuko.com

json_decode 解析带BOM头文件错误

1 //取前三个字符 并转化为ASCII 判断是否为BOM文件 2 3 $charset[1] = substr($result, 0, 1); 4 $charset[2] = substr($result, 1, 1); 5 $charset[3] = substr($result, 2, 1); 6 if (ord($charset[1]) == 239 && ord($charset[2]) == 187 && 7 ord($charset[3]) == 191) {

关于JSON解析的深坑之BOM头

    前言:在我们对Json字符串进行处理时,往往会碰到这个问题org.json.JSONException: Value of type java.lang.String cannot be converted to JSONObject,解析服务器返回的Json串时,JSONObject对象抛出了这个异常.其实这是返回的Json字符串含有BOM头导致的. 本人手拙,写的不好.望各位大虾见谅!!! 什么是JSON?  JSON(JavaScript Object Notation) 是一种轻

python 带BOM utf-8的响应解码

接口响应编码格式为带BOM头utf-8.直接获取响应的text出现乱码. '''dinghanhua2018-11requests text与content,指定响应的encoding''' api = 'http://testapi'response = requests.get(api) print(response.text)  乱码 解决方式: 1 获取content再用utf-8-sig decode. 2  指定响应的编码格式为utf-8-sig.再获取text. 1 指定respo

UTF8带BOM和不带BOM(转载)

UTF-8 不需要 BOM,尽管 Unicode 标准允许在 UTF-8 中使用 BOM.所以不含 BOM 的 UTF-8 才是标准形式,在 UTF-8 文件中放置 BOM 主要是微软的习惯(顺便提一下:把带有 BOM 的小端序 UTF-16 称作「Unicode」而又不详细说明,这也是微软的习惯).BOM(byte order mark)是为 UTF-16 和 UTF-32 准备的,用于标记字节序(byte order).微软在 UTF-8 中使用 BOM 是因为这样可以把 UTF-8 和 A

bom头的问题

JAXB将xml文件转化为java对象时出现了问题,用ue编写修改的xml文件加入了bom头,导致解析出现问题.但log4j解析带bom头的xml文件就不会有问题. 什么是bom头?在utf-8编码文件中BOM在文件头部,占用三个字节,用来标示该文件属于utf-8编码.现在已经有很多软件识别bom头,但是还有些不能识别bom头,比如PHP就不能识别bom头,这也是用记事本编辑utf-8编码后执行就会出错的原因了. 去掉bom头的办法,简单的是下面两种:1.editplus去BOM头的方法编辑器调

Namespace declaration statement has to be the very first statement in the script-去除bom头

今天准备测试小程序的签名加密,但是刚引入官方的"加密数据解密算法"文件到项目里,然后为每个文件添加命名空间的时候,不管怎么加都报"Namespace declaration statement has to be the very first statement in the script" 苦恼了10分钟才发现原来是bom头导致的. BOM头是放在UTF-8编码的文件的头部的,占用三个字节(0xEF 0xBB 0xBF,即BOM),用来标识该文件属于UTF-8编码

UTF8文件带BOM引起的问题

起因是公司iOS端竟然加载除了HTML代码,百思不得其解,查文献,原来如此... UTF-8 不需要 BOM,尽管 Unicode 标准允许在 UTF-8 中使用 BOM.所以不含 BOM 的 UTF-8 才是标准形式,在 UTF-8 文件中放置 BOM 主要是微软的习惯(顺便提一下:把带有 BOM 的小端序 UTF-16 称作「Unicode」而又不详细说明,这也是微软的习惯).BOM(byte order mark)是为 UTF-16 和 UTF-32 准备的,用于标记字节序(byte or

由于BOM头导致的Json解析出错

上周五改完一些BUG后,测试通过就安心在家过了个周末.结果周一回来一看,整个安卓APP所有的接口都挂掉了1.查找bug 首先想到的是客户端代码有问题,然后想起来上周五还能运行得好好的手机也是同样的错误,看日志是JSON解析错误. 细看也没看出来什么问题来,后来把服务器返回的JSON串在BeJson上做校验也是未通过. 后来群里的朋友说让我把字符串转成16进制应该能看出问题来,转换后果然在第一个大括号的前边多了一个16进数,搜索发现那个16进制数是BOM头 2.解决bug 去掉json串中的BOM