与 .NET 联调的那些事

浏览数：49 / 时间：2015年06月09日

序

这篇文章本来是想要写写最近用到的技术，但是回想起来，这几天主要的工作还是与 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 编码，而我在服务端只是进行了一次解码，那么可想而知，解出来的数据肯定是乱码啊。通过协商，统一采用一次编码，一次解码。再次测试之后，才没有了问题。