首页 > 代码库 > 与 .NET 联调的那些事

与 .NET 联调的那些事




这篇文章本来是想要写写最近用到的技术,但是回想起来,这几天主要的工作还是与 PC 端的联调,已经修改项目中的 bug。因此,就决定先不写技术方面的东西了。把我这几天与 .NET 联调的那些事说说吧,感觉也挺有意思的。


背景


在问题讨论之前,首先要把背景介绍清楚,这才是最重要的。PC 端的登录、验证都是走的服务器的 WebService,当然这个是很常见的,一般的也都是这么做的。只要是 PC 端涉及到读数据、写数据的都是需要通过 WebService 调服务器的。而 PC 端的操作有很多,也包括前一段时间写过的证书,PC 端需要获取证书也是需要请求服务器的。所以,在给 PC 端提供接口之后,就需要服务端与 PC 端一同进行联调。


正文


之所以要单独提出来写联调的事,是因为在联调过程中,Java 与 .NET 的交互出了些许问题,起初的问题让人感觉很扯,各自都有自己的一套实现,对接起来似乎并不怎么容易。不过后来我才发现,其实只要找对了方法,选择统一的标准,就算是各自的实现不同也没有关系,照样可以“沟通”。

就拿证书来说吧,前一段时间刚做了一个服务器生成 CA 证书的功能,然后这个证书是给 PC 端提供了,PC 端在注册用户时请求生成证书,成功之后,会把包含有公钥的证书传送给 PC 端进行保存。当然,这之间还有一些认证的机制,确保 PC 端访问的是真正的服务器。之后,PC 端的操作都会依据证书,通过使用证书中的公钥,对数据进行公钥加密,在传输过程中,就算是数据被截获之后,没有服务器发布的证书的私钥是无法解开数据的,这就保证了数据的安全传输。

上面说的只是一个大体的流程,下面说一下问题出在哪里,这会涉及到一些加密算法的使用,当然,这里就不讨论算法了。只是说一点,Java 服务端在对字符串进行加密的时候,发现加密的长度是有限制的,只能采用分片加密,这一点在前边也提过了。考虑到统一的标准,于是 Java 与 .NET 一同进行分片加解密,而不是只有一段进行分片。

由于在传输过程中,采用的是 Base64 的编码方式,在转换编码的时候,Java 服务端把 Base64 编码的数据传给 .NET 之后(这里是 C#),C# 采用同样的解码方式得到的数据竟然是乱码。这在试了很多次之后都是同样的结果。按说标准是统一的,虽然各自的实现方式不同,但是在交互上应该是相同的啊,同样的标准编码之后,采用一样的标准应该是可以解码的。想到可能是在之前的编码有问题,于是就把之前的编码都统一为 UTF-8 了,可恨的是,竟然还是乱码,这真的很没道理。在检查了我的代码之后,我并没有发现什么问题,后来通过查资料,也得知 Base64 编码在 Java 与 .NET 之间是可以互通的。那么问题肯定就出在了代码上。

由于之前我也学过 .NET,于是我开始过去跟 PC 端的人员沟通,了解他那边的实现流程,忽然我注意到,他在发送数据的时候,做了两次 Base64 编码,而我在服务端只是进行了一次解码,那么可想而知,解出来的数据肯定是乱码啊。通过协商,统一采用一次编码,一次解码。再次测试之后,才没有了问题。


结束语


这仅仅是其中的一个小问题,也是一个比较典型的问题。不仅仅是 Java 与 .NET,两种语言在交互的同时,一定要选择好适合的标准,选择两种语言之间共有的,在交互上才不会出什么问题。否则,标准不统一,实现不统一,那么交互起来有你头疼的。



与 .NET 联调的那些事