Base64编码，小东西有大智慧

最近为客户写了一个Base64编码的实例代码，主要业务如下：

 
       首先是A和B两个项目，在B调用A项目的一些服务过程中，A项目也需要在特定的时刻调用B项目的信息，
所谓回调。当A回调B的时候，B需要准备一些数据，以xml格式封装，并经过Base64编码后传递给A，A接受到会Base64解码，
然后分析xml数据最终给出提示。

 
        实例代码很快就完成了，并跟同事联调通过，在这之中我们考虑了Base64码表的统一中文编码和传输可能会出现乱码的问题。
但是当客户真正使用的时候却没有走通。总是在A回调完解析的时候报错，错误信息为：无法将Utf-8转换为Ansi。于是我们协助客户去定位问题，首先考虑到的是，是不是编码考虑不完整导致传输过来的内容有问题，于是做验证，将客户的实际内容拿过来再本机上跑，跟同事联调下居然一次性通过。于是分析了代码，发现该考虑的地方都有了，比如dom构造的编码，dom转换为字符串的编码。虽然在最后获取字符串的byte数组内容时，没有指定编码，但是不应该会有影响，因为Base64的码表中就不存在中文，所以无论哪种编码都应该没有问题。此时百思不得其解，于是考虑了客户的环境，考虑了客户的容器，考虑了客户使用struts是否正确指定了编码，但最终都没有解决问题。

 

        静下心来思考，为什么我们这没有问题，客户那就有问题呢？于是将客户的代码要了过来自己的看完，原来本质点在于使用方式不同，客户使用的struts我们使用的servlet，要命的是客户在struts中采用了我写的servlet的方式，通过response的outputstream将内容输出，但最中还定位到了一个页面。那么此时问题的症结就找到了，我们拿到的不是真正的内容，而是客户重新定位的页面或者是页面内容和base64编码后实际内容的组合。于是告诉用户将struts中的定位去掉，测试后通过。

 

      在解决这个问题中，思维还是不系统，纠结到编码上而没有去发散的寻找不同点，总是将知识点一个个的列出来而没有串起来。考虑了环境，考虑了容器，考虑了传输方式，但都是从编码角度来分析，没有将他们整合和分析，类似这样问题的发生往往都是一些小小的不同，但正是这些不同能找出来也是一种智慧。