加号与空格的故事

    近期给客户发了一些调研的邮件，但愿能借由邮件了解用户对于网站一些重要功能的需求，后续还会对部分用户进行进一步的调研，纠结的是该调研系统是外部系统，若是咱们须要将调研结果精确到人的话就须要向它传递一个相似id的惟一标识，若是传递email或者用户id会涉及到数据泄露和法律问题，若是传递一串数字id，就须要对每封邮件生成id并记录下来，成本有点高，因此最终决定将用户标识加密传递给外部系统，第一次调研后我根据调研结果文件解密一切正常，只有一个数据没有解密成功，我也没太在乎。第二次调研后，我被告知，该结果须要当天完成好向高层汇报让我赶忙弄出来，因而会没开完我就离席了，本想应该很轻松，但此次竟然只解析出40％左右的数据，其余数据都不太正常，具体表现就是部分数据虽然解析出来，可是头尾会带乱码，或者就是彻底乱码。

    理论上来讲，若是在加密解密过程当中出现问题，绝大多数的结果应该都是乱码，问题出现，首先回顾一下整个数据流转的过程

     1. 数据被edm系统加密，而后对url encoding（utf-8），最终邮件经过发送系统推送到用户邮箱

     2. 用户在客户端打开邮件，看到调研连接，点击连接，在客户机浏览器打开连接，访问到调研系统

     3. 调研系统解析到传递过来的惟一标识，保存并记录当前用户调研结果

     4. 调研结果导出到excel文件

     5. 将excel文件中加密的惟一标识写入txt文件，并读取，解密

先考虑最简单的状况，也就是第五步将excel中的惟一标识copy到txt文件的过程是否有额外字符的拷贝，或excel自己就加入了额外字符，通过排查，不是该缘由，期间想通一件事，就是解析结果有40％的正确率是因为加密过程当中撒了盐，因此间接证实了秘文并未彻底失真，可能只有不多的部分信息是错误的致使有部分数据可以被解析出来，顺着这个思路继续想，把问题定位到第一步，url encoding部分，因为咱们采用了utf-8做为encoding参数，而调研系统的decoding charset未知，因此是否因为两个字符集对于密文中部分字符的编码结果不一致致使呢，结果发现除了utf16会致使结果不一致之外（ascii不兼容字符集），其余字符集decode都没问题（都是ascii兼容字符集），因而我回过头仔细分析了第一次的调研结果和第二次的调研结果，悲情的发现，第二次的调研结果里惟一标识符竟然出现了空格，并且第一次调研结果失败的那条记录里也有空格，考虑到加密结果是base64编码的基本模式，因此猜想应该将空格替换为那个该死的加号，解密终于成功了。。。。问题是，为啥会出现空格，对加密结果是作过url encoding的，加号会被替换为％2B，根据相关的协议，是不会反解析为空格的(http://www.w3.org/TR/html5/association-of-controls-and-forms.html#url-encoded-form-data)，若是没有url encoding ，base64编码后可能会在url里出现加号，最后decoding的时候变成空格。。

    为啥正确的作法仍是会有问题呢，问题出如今邮件客户端的可能性很小，由于客户的邮箱各式各样，更有可能的一种问题是double decoding形成，加号encoding一次，decoding两次变成了空格，杯具～查了好久都没注意到空格，要不该该能够很快恢复数据，现阶段很难猜想对方服务器为何在近期出现double decoding问题，若是后续继续出现问题只能去联系对方问问看了。