sm2.Decompress方法的入残，该是什么格式的公钥？

[duxin40]

我发现在java sm2中生成的公钥，在sm2.Decompress方法解析时，会报panic：
goroutine 81 [running]:
testing.tRunner.func1.2(0x564ba20, 0x69fa320)
/usr/local/opt/go/libexec/src/testing/testing.go:1143 +0x332
testing.tRunner.func1(0xc000603b00)
/usr/local/opt/go/libexec/src/testing/testing.go:1146 +0x4b6
panic(0x564ba20, 0x69fa320)
/usr/local/opt/go/libexec/src/runtime/panic.go:965 +0x1b9
math/big.(*Int).Bit(0x0, 0x0, 0xc0001f0160)
/usr/local/opt/go/libexec/src/math/big/int.go:1035 +0x30
github.com/tjfoc/gmsm/sm2.getLastBit(...)
/Users/duxin/go/src/api-gateway/vendor/github.com/tjfoc/gmsm/sm2/sm2.go:668
github.com/tjfoc/gmsm/sm2.Decompress(0xc00071ae80, 0x40, 0x40, 0xc00071ae80)
/Users/duxin/go/src/api-gateway/vendor/github.com/tjfoc/gmsm/sm2/utils.go:23 +0x299

[deatil]

传的是压缩的公钥明文，java生成的压缩明文前缀需要格式化为这个库能使用的前缀

[emmansun]

这应该是ModSqrt返回nil导致panic吧，不过这个方法实现本身就不健壮：

• 没有检查输入数据长度。
• 没有检查输入数据首字节，确认是否是压缩标识字节。当然，本库的标识字节本来就是错误的。
• 没有检查ModSqrt的返回是否是nil。

其实可以参考Go语言的elliptic.UnmarshalCompressed实现。