BASE64与UNICODE

为什么80%的码农都做不了架构师？>>>   

在公司跟别人做了一个项目，基于规则引擎Drools开发的一个相当于编写Drools脚本的工具项目。为了简化Drools自带工具的繁琐操作和概念上的理解困难，从应用的角度出发，站在业务角度维护规则。利用模型+参数+属性建立模型，再组织成规则表达式，其中有个关键点是，业务人员对于一些模型、参数、属性的命名上不太好把握。所以采用中文的方式命名更容易被业务人员接受，那问题就来了。Drools文件里和Java一样不支持中文命名变量。所以就有了项目中目前采用的转换中文为UNICODE码的方式作为变量名称。本来也没有的多想这件事情就很顺其自然的被接受了，但今天看生成的规则文件时（以前都是其他同事搞这个文件生成），发现生成的文件中变量命名过于冗长。例如：中华人民共和国 转换UNICODE码后，替换掉\u后是：354c69743559324f354c71363572435235595778355a4b4d355a7539

实现程序如下：

/**
      * 字符串转换unicode
      */
     public static String string2Unicode(String string) {
            StringBuffer unicode = new StringBuffer();
            for (int i = 0; i < string.length(); i++) {
            // 取出每一个字符
            char c = string.charAt(i);
            // 转换为unicode
             unicode.append("\\u" + Integer.toHexString(c));
         }
           return unicode.toString();
     }
     
     /**
      * unicode 转字符串
     */
    public static String unicode2String(String unicode) {
               StringBuffer string = new StringBuffer();
               String[] hex = unicode.split("\\\\u");
               for (int i = 1; i < hex.length; i++) {
                   // 转换出每一个代码点
            int data = Integer.parseInt(hex[i], 16);
                   // 追加成string
             string.append((char) data);
         }
               return string.toString();
     }

于是我就想如果通过BASE64转换呢，发现同样的转换后为：5Lit5Y2O5Lq65rCR5YWx5ZKM5Zu9但是会出现数字开头的内容，需要处理加前缀。但总的看起来变量的长度明显有所减少。

BASE64采用JAVA自带进行处理：

BASE64Decoder decoder = new BASE64Decoder();
BASE64Encoder encoder = new BASE64Encoder();

做个对比和总结，单从这点上感觉BASE64更合适些，但项目采用了unicode也许有其他的考虑。

 

 

转载于:https://my.oschina.net/dolor/blog/742641