欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

一场关于 .net core 和 .net framework 编码的案情分析

程序员文章站 2022-06-28 20:42:36
案情背景 目前公司做新项目,基本所有新项目都是用.net core来做,旧项目一半还是基于 .net framework下面,一半已经迁移到了core平台。在做新项目的时候,有个功能需要对接到旧项目那边的接口,功能也不复杂,就是对接接口的参数需要通过签名,然后进行MD5加密传输过去,旧项目那边也有相 ......

案情背景

  目前公司做新项目,基本所有新项目都是用.net core来做,旧项目一半还是基于 .net framework下面,一半已经迁移到了core平台。在做新项目的时候,有个功能需要对接到旧项目那边的接口,功能也不复杂,就是对接接口的参数需要通过签名,然后进行md5加密传输过去,旧项目那边也有相同的签名和加密方式,用来检验参数的正确性,听起来其实就是一种很简单传统的签名验证方式,却因为 “.net core 和 .net framework 下面编码不同” 导致走了很多弯路
在传参过程中,一直收到旧项目接口返回的“签名错误”的提示,刚开始以为是两者对应的签名方法不一致,但经过同事确认,签名方法是直接复制过来的,绝对没错(虽然我还是不信ㄟ( ▔, ▔ )ㄏ),为了证明他的结论是错的,我毅然在 .net framework下面建了个项目,然后同样的代码copy过去,当我run起来后,心里本来想可以美滋滋的过去扇他一嘴巴子。结果签名通过了,接口调用成功,这让我很是惆怅啊.........

一场关于 .net core 和 .net framework  编码的案情分析

肇事方法

  回头整理下,整个过程中,排除了业务方法后,最终最只有这个md5加密的方法

     /// <summary>
     /// md5加密
     /// </summary>
     /// <param name="password"></param>
     /// <returns></returns>
     public static string md5encrypt(string context)
     {
         var bytes = encoding.default.getbytes(context);
         var md5str = md5.create().computehash(bytes);
         return bitconverter.tostring(md5str).replace("-", "");
     }

然后我把这个方法单独拿出来在两个平台上测试,发现结果确实不一样,心里莫名有种兴奋感,接下来定位到 encoding.default.getbytes 这个方法,于是再测试了一次

这是.net core下面的结果

一场关于 .net core 和 .net framework  编码的案情分析

这是.net framework下面的结果

一场关于 .net core 和 .net framework  编码的案情分析

一场关于 .net core 和 .net framework  编码的案情分析

寻找真相

  发现到这里,我的第一反应其实是这样的

一场关于 .net core 和 .net framework  编码的案情分析

  接下来,百度和*查一下,找不到答案,问了几个群,也没人遇到过。然后拿出了杀手锏,我亲爱的谷歌,可能提问方式不对,愣是找不到答案。最后,没办法了,是时候发挥一个程序员的精神了,咱自己看下源码吧,方正.net都是开源的。

第一步,看下.net core下面 encoding.default 这个对象的源码

一场关于 .net core 和 .net framework  编码的案情分析

  可以看到,.net core下面 encoding.default 默认就是获取了utf8encoding这个编码的

第二步,看下.net core下面 .net framework这个对象的源码

一场关于 .net core 和 .net framework  编码的案情分析

  可以看到,.net framework 是也有utf8encoding这个编码的,但是确是需要当  代码页标识符 为65001的时候才会命中(65001具体表示什么,等下再说到),这样看,难道是他们两个默认的 代码页标识符 不一样,瞬间感觉离真相越来越近了

第三步,看下他们的默认codepage

.net framework

一场关于 .net core 和 .net framework  编码的案情分析

.net core

一场关于 .net core 和 .net framework  编码的案情分析

soga~~~果然不一样,于是查了下96365001对应的编码类型

一场关于 .net core 和 .net framework  编码的案情分析

  这下就清晰了,虽然同样都是用 encoding.default 的方法,但是由于.net framework 下面默认的是963(gb2312)的,.net core 下面是65001(utf-8)的,所以才会导致相当的方法,跑出了不同的结果。

一场关于 .net core 和 .net framework  编码的案情分析

解决问题  

  知道原因了就好办了,由于旧系统的接口之前也会其他系统在对接,所以旧系统那边的签名是改不了的,只能改新的这边,于是只要在.net core 把 encoding.default 改作 encoding.getencoding(“gb2312”),统一编码就可以了,然后兴高采烈的run起来,结果居然报错了,又一次被尴尬到,原来是.net core默认不支持gb2312了,所以需要在starup.cs的configure方法中加入encoding.registerprovider(codepagesencodingprovider.instance),就这样妥妥的跑稳了。

 

一场关于 .net core 和 .net framework  编码的案情分析

  

 

  好了,感觉是不是有点标题党,哈哈,其实就是想和大家分享下,也希望大家在.net core 上面遇到的问题也能分享下,可能只是个细节的问题,同样能帮助别人少才坑。

  然后顺便跟还在用.net framework的朋友说下,可以 稳稳地转.net core 了,我已经两年没写过文章了,这两年来一直在学,在用.net core ,在生产环境中已经稳稳的跑过.net core了,而且是在docker里面,而且是在k8s里面(当然linux和window上的就更不用说了)