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的业务上要做好判断处理,若是纯数字运单号入库就应该是纯数字而不是科学计数法的形式。
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.14go-micro-codegjj>go run main.go &{1.1572417766286e+18 LM358} 1157241776628600000