在此记录一个在开发自测环节中遇到的问题:
先上代码(已脱敏)
type TestData struct {
Data []byte `json:"data"`
}
func TestTryEncryptoClient(t *testing.T) {
jsonStr := "{\"Data\":\"4GFwsR9XFRkyb/9Hn14zNpQRFE4V/f1hLIDlnff6LLPR/EvRmSW6ma6PHZiamB4mDeynjRYfVsfipg==\"}"
message := &TestData{}
err := json.Unmarshal([]byte(jsonStr), message)
if err != nil {
panic(err)
}
result := message.Data
t.Logf("%v", result)
t.Log(string(result))
sprintf := fmt.Sprintf("%s", result)
t.Log(sprintf)
t.Logf("bad base64: %s", result)
t.Log("test done")
}
输出内容(goland)控制台
[224 97 112 177 31 87 21 25 50 111 255 71 159 94 51 54 148 17 20 78 21 253 253 97 44 128 229 157 247 250 44 179 209 252 75 209 153 37 186 153 174 143 29 152 154 152 30 38 13 236 167 141 22 31 86 199 226 166]
짍V���
짍V���
짍V���
xxx_test.go:193: test done
现象描述:
此段代码会造成如下代码片段未能输出 t.Logf("bad base64: %s", result) ，并且如果是多协程测试条件下，很可能会造成控制台卡住(无法输出后续内容)
原因分析:
在此过程中，我们错误使用了%s来匹配[]byte类型的数据，虽然golang在编译或者goland在运行前检查中不会报错/warning，但是在最终输出的时候，由于byte[]中包含了不能被控制台解析的控制字符，所以会造成最终输出内容的错误(也可以叫做编码不匹配)，并且由于大部分编码都会兼容ASCII编码，在上述输出中会有byte为22的控制字符-> ASCII中描述为暂停等待同步字符，所以在多线程/协程测试中会导致控制台卡住等待同步完成
解决方案:
使用string现式包裹[]byte即可
sprintf := fmt.Sprintf("%s", string(result))
总结:
下次当遇到控制台卡住无输出的时候，记得检查是不是%s遇上了
[]byte类型的数据(常见某些加密流中的测试，用于观察加密后的字符输出)
1 个帖子 - 1 位参与者
来源: linux.do查看原文