kapok

垃圾桶,嘿嘿,我藏的这么深你们还能找到啊,真牛!

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  455 随笔 :: 0 文章 :: 76 评论 :: 0 Trackbacks
http://rabbit8.blogchina.com/blog/article_144619.859489.html
再谈URLEncoder
2005年 02月16日
有个朋友说在百度上提交的数据进行编码后不是我说的那样,我试了一下,找到原因如下

关于URLEncoder的解析问题     

      http://rabbit8.blogchina.com/blog/article_144619.789425.html后,有个朋友留言,说在百度试验的结果和我文章中说的不一致,我做了个实验,证实JDK的帮助没错,原因如下:


我的试验代码如下:
public static void main(String[] args) {
        URLEncoder urle = null;
       
        //得到默认:%A8%B9
        System.out.println("默认:" +   urle.encode("ü")); 
        try {
            //得到GBK:%A8%B9
            System.out.println("GBK:" +  urle.encode("ü", "GBK"));
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
        }
        try {
            //得到UTF-8:%C3%BC
            System.out.println("UTF-8:" +  urle.encode("ü", "UTF-8"));
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
        }
    }
 
      如果用UltraEdit来查看"ü"的ASCII的话,得到的结果如图:
 
      可见,UltraEdit使用的是操作系统默认的编码方式(实际上,MS采用的也不是GBK,而是另一种编码,但效果和GBK差不多),所以它显示的ASCII的编码为A8 B9,就是第一和第二种情况的结果。而第三种情况才是JDK帮助中所声明的情况。
 
      我查看了百度,提交了一下,结果和我预期的是一样的!

      如果你查看页面的源文件,会看到百度的charset为gb2312,而帮助中明确提到例子使用的是UTF-8编码,所以出现了不一致的问题,也正是因为这个原因,所以JDK中决定要废弃public static String encode(String s)方法,因为这个方法的编码的字符集依赖于程序运行的系统的默认的字符集!
 
                                                                     兔八哥
                                                             2005-2-15 17:41
 

posted on 2005-03-09 00:44 笨笨 阅读(740) 评论(0)  编辑  收藏 所属分类: ALLAppFuse

只有注册用户登录后才能发表评论。


网站导航: