浅谈开发中对数据的编码和封装

前言

前几天写了一篇对跨端通讯的思考，当时顺便想到了数据这一块，所以也可以整理一下，单独拿出来说说平时开发中涉及到哪些对数据的处理方式。

Base64

之前详细写过一篇关于Base64的文章

juejin.cn/post/715584…

简单来说，Base64就是把你的数据转成只有64个无特殊符号的字符，主要常用于加密后之类的生成的字节数组，转成Base64方便进行数据传输，如果不转的话就会是乱码，会看得很难受，这些乱码在某些编码下展示出来的是豆腐块，有点扯远了。

还有就是比如中文啊，emoji啊这类的字符，在某些情况下也需要转成Base64进行传输。

缺点就是只用64个字符表示，还有我之前分析过base64的转换原理，通过其原理能很容易看出，最终的转换结果相比转换前的数据更加长。

JSON/XML

这些就比较常见了，对数据按照一定的格式进行封装。为什么要说这个呢？因为他这些封装是约定熟成的方式，和上面的Base64的转换方式就不同，相当于是大家约定好按照这个格式包装数据，然后传输，自己再按照这个格式去解开拿到数据。

多数用于跨端传输，像客户端请求服务端拿数据，那不也就是跨端嘛，其实这个所有人都用到，但为什么说这个呢？还是那个跨端通信的问题，跨端通信没办法直接传对象，实际传对象的效果是转json传的String，然后另外一端再创建一个自己端的对象，解析json，把json数据填充进去。

还有，既然是约定的，那其实我们自己也可以按照我们自己的约定去做跨端的数据传送，只不过json这种格式，是已经设计得很好了，你很难再去约定一种比这个格式更好的封装。

PS：不要觉得json大家都在用，都形成肌肉记忆了，没有什么难的。其实比如像gson\fastjson这些，人家去研究解析json的算法，也是一个技术点。你觉得简单，那是因为你在使用，但让你从0去做，你不一定能做出来。

URL编码

又叫做urlencode，顾名思义用于url连接中的一种对数据的操作。

它将特殊字符转成16进制并且在前面加%，那同理解析拿数据的时候也是根据%去做判断。

为什么会出现这种编码呢？主要是为了防止冲突，我们都知道比如get请求都会在url链接后面拼参数，防止在传输中出现问题，所以把特殊字符都进行编码。

比如http://www.baidu.com/?aaaaaaa 会编码成https%3A%2F%2Fwww.baidu.com%2F%3Faaaaaaa

该编码主要用于对url的处理。

驼峰和下划线

这其实是一个命名方式，不同的端有不同的命名习惯，比如java习惯就是用驼峰，但是还是跨端问题，有些时候存在写死的情况，当然这个代码不是你写的，也可能是前人留下的（我没有暗示什么）。但如果你的代码中出现两种命名方式会让代码看着比较乱。没关系我们可以做个转换，我这里以下划线转驼峰为例

private String lineToHump(String str) {

    if (TextUtils.isEmpty(str)) {

        return str;

    }


    String[] strs = str.split("_");

    if (strs.length < 2) {

        return str;

    }


    StringBuilder result = new StringBuilder(strs[0]);

    for (int i = 1; i < strs.length; i++) {

        String upper = (strs[i].charAt(0) + "").toUpperCase();

        if (strs[i].length() > 1) {

            result.append(upper).append(strs[i].substring(1));

        } else {

            result.append(upper);

        }

    }

    return result.toString();

}

可以写个转换方法，我这里只是随便写个Demo，这段代码是还能进行优化的，主要大概就是这个意思。

上面说的json主要是为了说数据的封装和解封，这里主要是说数据的转换，我的意思是在开发中，我们也会出现不同端的数据形式不同，我们不需要在代码中向其它端进行妥协，只用写个方法去做数据的转换，在本端还是正常写本端的代码就行。

摘要

摘要算法，简单来说就是将原数据以一种算法生成一段很小的新数据，这段新数据主要是用来标识这段原数据。怎么还有点绕，总之就是生成一个字符串来标识原数据 。对任意一组输入数据进行计算，得到一个固定长度的输出。

也可称之为哈希算法，最重要的是它取决于它的这个设计思想，它是一个不可能逆的过程，一般不能根据摘要拿到原数据，注意我用了一般，因为这个世界上存在很多老六。

摘要算法中当前最经典的是SHA算法和MD算法，SHA-1、SHA-256和MD5。其中他们加密过程可以单独写一篇文章来说，这里就不过多解释。

摘要算法最主要的运用场景是校验数据的完整性和是否有被篡改。比如CA证书的校验，android签名的校验，会拿原数据做摘要和传过来的摘要相对比，是否一样，如果不一样说明数据有被篡改过。再比如我本地有个视频，我怎么判断后台这个视频是不是更新了，要不要下载，可以对视频文件做MD5，然后和后台文件的MD5进行对比，如果一样说明视频没有更新，如果不一样说明视频有更新或者本地的视频不完整（PS：对文件做摘要可是一个耗时的过程。）

加密

讲完摘要可以趁热打铁说说加密，加密顾名思义就是把明文数据转成密文，然后另一方拿到密文之后再转成明文。

加密和摘要不同在于，它们的本质都不同，摘要是为了验证数据，加密是为了安全传输数据。它们在表现上的不同体现在，摘要是不可逆，加密是可逆的。

加密在当前的设计上又分为对称加密和非对称加密，主流的对称加密是AES算法，主流的非对称加密是RSA算法。对称加密的加密和解密使用的密钥是相同的，非对称是不同的 ，所以非对称加密更为安全，但是也会更耗时。

当然你也可以不用这些算法，如果你是直接接触这些算法，好像是要付专利费的，每年给多少钱别人才给你用这个算法，资本家不就喜欢搞这种东西吗？扯远了。你也可以使用自己约定的算法，只不过在高手面前可能你的算法相当于裸奔，要是你真能设计出和这些算法旗鼓相当的算法，你也不会来看我这么捞的文章。

所以加密，是为了保证数据的安全，如果你传输的数据觉得被看了也无所谓，那就不用加密，因为它耗时。如果你只是为了防止数据被改，也不用加密，用摘要就行。如果你是为了传输seed，那我建议你加密[狗头]

通信协议

json那里我们有说，它就是双方约定好的数据格式。以小见大，通信协议也是双方约定的一种数据传输的过程。通信协议会更为严谨，而且会很多不同，各家有各家的通信协议，不是像json这种就是大家都用一样的。

比如我们的网络传输，就有很多协议，http协议、tcpip协议等，这些在网络中是规定好的，大家都用这一套。再比如蓝牙协议，也是要按照同一个规范去使用。但是硬件的协议就多种多样了，不同的硬件厂商会定义不同的通信协议。

二维码

二维码也是对数据封装的一种形式，可以通过把数据变成图像，然后是扫码后再获取到数据，这么一种模式我感觉能想出这个法子的人挺牛逼的。

它所涉及的内容很多，具体可以参考这篇文章，我觉得这个大佬写得挺好的 二维码生成原理 - 知乎 (zhihu.com)

我之前自己去用java实现，最终没画出来，感觉原理是没问题的，应该是我哪里细节没处理好，这里就简单介绍一下就行。其实简单来说，它就是有一个模板的情况下，把数据填充到模板里面。

这里借大佬的图，模板就是这样的

然后按照规则去填充数据

这样去填充，其实会让黑点分布不均匀，填充之后还会做一个转换。

但是二维码也有缺点，缺点就是数据量大的时候，你的二维码很难被识别出，但是不得不说能想出这个方法，能设计出这个东西的人，确实牛逼。