案情背景

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

肇事方法

　　回头整理下，整个过程中，排除了业务方法后，最终最只有这个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 framework下面的结果

寻找真相

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

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

第一步，看下.net core下面 Encoding.Default 这个对象的源码

　　可以看到，.net core下面 Encoding.Default 默认就是获取了UTF8Encoding这个编码的

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

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

第三步，看下他们的默认CodePage

.net framework 的

.net core 的

soga~~~果然不一样，于是查了下963和65001对应的编码类型

　　这下就清晰了，虽然同样都是用 Encoding.Default 的方法，但是由于.net framework 下面默认的是963（GB2312）的，.net core 下面是65001（UTF-8）的，所以才会导致相当的方法，跑出了不同的结果。

解决问题　　

　　知道原因了就好办了，由于旧系统的接口之前也会其他系统在对接，所以旧系统那边的签名是改不了的，只能改新的这边，于是只要在.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 core ，在生产环境中已经稳稳的跑过.net core了，而且是在docker里面，而且是在k8s里面（当然linux和window上的就更不用说了）