在專案里剛好有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！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/552831.html
標籤：其他
上一篇：HTB ACADEMY-Stack-Based Buffer Overflows on Linux x86 WRITE UP
下一篇：返回列表