记一次排查:接口返回值写入excel后,从单元格copy出来的数据会带有多重引号的问题

在项目里刚好有3个服务,同一个网关内层的3个服务,两个php的,一个golang的,为了提高负载以及进行分流,部分客户的接口调用会被网关自动分配到go服务。

恰好为了测试,我写了一个全量用户的生产、测试环境调用接口返回结果进行对比的脚本,于是发现了题中的问题:两个php服务里的接口返回值写入xlsx后,直接copy出来是正常的json串,golang的接口返回值copy出来变成双重引号如图

 

排查过程:

1、先通过python的requests请求接口直接打印出返回值,看看是否是两个双引号,结果发现php跟go服务都是正常的json串。

 

2、继续排查,猜想问题会不会出现编码传输格式上,于是对比php跟go接口响应标头。

  php服务响应头如下:

  

  go服务应头如下

  

  go跟php响应头的差别只在于两点:php多了TimeStamp,Content-Type里面多了charset=utf-8。

  首先排除TimeStamp,从名称上就可以看出来不会对返回值格式或内容有任何影响;

  然后尝试用flask编写两个接口,Content-Type里面分别为application/json、application/json; charset=utf-8,写入excel后发现并没有任何不同。

 

3、响应头也没问题,继续猜想会不会是go服务代码缺陷,接口在return response之前并没有序列化,而是直接返回了object对象

  我们先了解一个概念:序列化与反序列化

  序列化是把程序对象转换为字节序列的过程,反序列化就是把字节序列恢复为程序对象的过程。

  因为不同的客户端、服务端可能使用的语言不同,为了兼容都是用序列化之后的数据进行传输,比如前端js将页面参数序列化之后传递给后端java服务。

  开始实验,本地flask直接返回字典{"username": username, "password": password},写入excel的居然真的出现了两个双引号。

  

 

4、于是让开发排查代码里是不是没有作序列化,但是出人意料的是,go代码里是做了序列化才返回的。

  所以上面的猜想都不成立,研究一度陷入僵局,直到...

 

5、偶然注意到copy出来的返回值尾巴上有个莫名其妙的换行。

  

  根据以前经常写json数据入csv、xlsx文件的经验,就算是格式化后加了多个引号的json数据(例如pandas的to_csv方法里的quoting参数即可控制是否加引号),也不可能加换行符。

  所以猜想会不会是返回值多了个隐形的换行符,然后在pacharm的cmd里调一下接口看看,果然go服务返回体尾巴上换行了,而php则不会

  

 

6、于是在写入excel之前把返回值rstrip()一下做最后的确认,结果从excel复制出来的数据真的没有多重引号了

 

至此,揪出来这个go服务的bug!

 

热门相关:超武穿梭   最强反套路系统   夫人,你马甲又掉了!   战神   最强反套路系统