1、问题
最近接手一个商城运单号模块,接手后发现有部分运单号返回给前端是按照科学计数法的方式返回,如:8.0497183772403904E+17,后查库发现这些运单号在excel导入的时候就是按照科学计数法导入,没做任何处理。
按照科学计数法的形式返回给用户运单号,这样太不友好了,简直就是bug,所以需要进行转换处理后再返回给用户。
2、问题修复
面向谷歌编程,找到了以下方法进行转换:
- 第一种:
oldNum := float64(8.0497183772403904E+17)
newNum := big.NewRat(1, 1)
newNum.SetFloat64(oldNum)
fmt.Println(newNum.FloatString(0))
结果:
804758523075821952
- 第二种:
var newNum float64
numStr := "8.04758523075822e+17"
_, err := fmt.Sscanf(numStr, "%e", &newNum)
if err != nil {
log.Errorf("fmt.Sscanf error, numStr:%s, err:%v", numStr, err)
return
}
num := fmt.Sprintf("%.f", newNum)
fmt.Println(num)
结果:
804758523075821952
以上两种转出来的都会精度有所丢失,具体原因未知,现在还未去深究,有知道的朋友希望可以评论回复解答一下,谢谢。
- 第三种:
以上两种都存在丢失的问题,起初是不知道的,后面通过java进行转换了才发现真的丢失了java代码如下:
BigDecimal bd = new BigDecimal("8.04758523075822e+17");
System.out.println(bd.toPlainString());
结果:
804758523075822000
java既然可以通过BigDecimal进行转换,那golang肯定也可以(很不幸我使用的是go1.11.2没找到decimal的相关包支持,只能面向github编程了),在github中找到了一个较多人使用的包 github.com/shopspring/decimal
使用代码如下:
//先安装包 go get github.com/shopspring/decimal
numStr := "8.04758523075822e+17"
decimalNum, err := decimal.NewFromString(numStr)
if err != nil {
log.Errorf("decimal.NewFromString error, numStr:%s, err:%v", numStr, err)
return
}
fmt.Println(decimalNum.String())
结果:
804758523075822000
3、总结
在进行科学计数法的数字转string数字的时候,最好还是使用第三种方法,这样不会精度丢失的情况。当然导入excel的业务上要做好判断处理,若是纯数字运单号入库就应该是纯数字而不是科学计数法的形式。