ʲô是URL转码
不管是以何种方式传递url时，如果要传递的url中包含特殊字符，如想要传递一个+，但是这个+会被url会被编码成空格，想要传递&，被url处理成分隔符。
尤其是当传递的url是经过Base64加密或者RSA加密后的，存在特殊字符时，这里的特殊字符一旦被url处理，就不是原先你加密的结果了。
如图所示，访问接口参数我传递参数为 1+1 结果浏览器显示结果为 1 1 很明显 '+' 被转化成了空格。
转码之前访问：
如果别人调用你接口传递的参数如果有特殊字符，那么你就需要进行转码进行处理，不然就会导致参数错误，如上图所示。
解决方案：
public static void main(String[] args) { //转码方法 String encode = URLEncoder.encode("1+1"); System.out.println("转码：" + encode); //解码方法 String decode = URLDecoder.decode(encode); System.out.println("解码:" + decode);} 控制台输出结果：转码：1%2B1 解码：1+1转码之后访问：
url特殊符号及对应的编码:
| 符号 | url中的含义 | 编码 |
| + | URL 中+号表示空格 | %2B |
| 空格 | URL中的空格可以用+号或者编码 | %20 |
| / | 分隔目录和子目录 | %2F |
| ? | 分隔实际的URL和参数 | %3F |
| % | 指定特殊字符 | %25 |
| # | 表示书签 | %23 |
| & | URL中指定的参数间的分隔符 | %26 |
| = | URL中指定参数的值 | %3D |
对称加密与非对称加密
对称机密和解密都使用同一个密钥。在加密解密过程中，使用同一个密钥进行加解密。
防止别人抓包分析Http请求，获取明文数据并进行篡改。可以使用 postman 发送请求，使用 fidder 进行抓包分析数据并篡改。
由上面的结果可以知道，我发送的请求 的参数为 xiaoming，经过抓包之后我篡改了数据 将参数修改为了 大白，数据就这样被篡改了，所以我们在调用接口的时候应该避免出现这样的请求。
加密后流程图：
常见的对称加密技术
DES（数据加密标准）：分组式加密，算法源于Lucifer，作为NIST对称式加密标准；64位（有效位56位、校验8位），分组算法
AES（高级加密标准）：DES升级版，算法出自Rinjindael
3DES：128位，分组算法
IDEA（国际数据加密算法）：128位，比DES快，分组算法
Blowfish：32-448位，算法公开，分组算法
RC4：流密码，密钥长度可变
RC5：分组密码，密钥长度可变，最大2048位
Rijndael：128位/196位/256位
对称密码的优点
对称密码的缺点
如果密钥交换不安全，密钥的安全性就会丧失。特别是在电子商务环境下，当客户是未知的、不可信的实体时，如何使客户安全地获得密钥就成为一大难题。
如果用户较多情况下的密钥管理问题。N*(N-1)/2
如果密钥多个用户被共享，不能提供抗抵赖性
对称加密使用场景：速度非常快。服务器与服务器端之间进行通讯。后台与后台进行通讯。
对称密码案例
预先约定了一个密码，用来加密在他们之间传送的消息，这样即使有人截取了消息没有密码也无法知道消息的内容。由此便实现了机密性。
1、密码是不能够使用对称加密的，如果使用对称加密会被反向破解出来的，按照互联网隐私的情况下是不能够反向解密的。
2、密码使用单向加密的，单项加密特征：是不可以被逆向破解的。MD5 单向加密一般都会进行加盐处理。
加盐的目的：防止别人破解的，如果拿不到盐值是无法破解的。
如何保证APP接口安全
使用Https传输、使用令牌、使用非对称加密。Http+Json 方式进行数据传输。
移动App接口是不能使用对称加密的。
因为对称加密，密钥都是相同的，如果黑客反编译破解移动打包apk，就可以得到密钥，然后拿到我们对应的参数，所以移动App不能使用对称加密。
非对称加密(公钥与私钥)
使用一对密钥：一个用于加密信息，另一个则用于解密信息。可以使用第三方工具生成非对称密钥对。
机密性、完整性、抗抵赖性
公钥加密，私密解密(安全)。目前来说是最安全的加密手段，
缺点：效率低。
应用场景：第三方支付对接、核心的金融机构。
使用令牌方式实现参数传递安全方法
