时间：2021-08-31 10:00:23 | 栏目：Golang | 点击：次
最近接手一个商城运单号模块，接手后发现有部分运单号返回给前端是按照科学计数法的方式返回，如：8.0497183772403904E+17，后查库发现这些运单号在excel导入的时候就是按照科学计数法导入，没做任何处理。
按照科学计数法的形式返回给用户运单号，这样太不友好了，简直就是bug，所以需要进行转换处理后再返回给用户。
面向谷歌编程，找到了以下方法进行转换：
第一种：
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
在进行科学计数法的数字转string数字的时候，最好还是使用第三种方法，这样不会精度丢失的情况。当然导入excel的业务上要做好判断处理，若是纯数字运单号入库就应该是纯数字而不是科学计数法的形式。
package main
import (
"encoding/json"
"fmt"
"github.com/shopspring/decimal"
"strconv"
//"github.com/shopspring/decimal"
)
type abc struct {
Goods_id float64 `json:"goods_id"`
Goods_name string `json:"goods_name"`
}
func main(){
a := `{"goods_id":1.1572417766286e+18,"goods_name":"LM358"}`
aaa := &abc{}
err := json.Unmarshal([]byte(a),aaa)
if err !=nil{
fmt.Println(err)
}
fmt.Println(aaa)
decimalNum, err :=decimal.NewFromString(strconv.FormatFloat(aaa.Goods_id, 'e', -1, 64))
if err != nil {
return
}
fmt.Println(decimalNum.String())
}
D:\gocode1.14\go-micro-code\gjj>go run main.go
&{1.1572417766286e+18 LM358}
1157241776628600000