[转载]httpclient的cookie,编码与上传

作者: ldsea 分类: 程序生活 发布时间: 2009-04-11 17:00

最近一直试图用httpClient做点自动化的工作,不过现在看来并没有想象中的那么轻松。

实际上登录一个网站,访问某个特点的页面,发表一篇文章,上传一些文件,并不是一个简单的事情。
HttpClient的基本使用因为发布的代码中带有几个例子,应该算是不难掌握的事情。下面我说下我遇到的几个问题。

1,登陆验证图片问题
首先登录的时候网站如果不想你对它编程的化通常都会设计一个验证图片,这个技术现在已经如此的易于使用,以至于随便到哪里都能找到代码来直接使用。对于验证图片的,现在还苦于无计可施状态。

2,笨蛋Cookie问题:
如果你要发送多个cookie,其实可以这样发的:

[code]state.addCookies (new Cookie[]{
            new Cookie(" www.aaa.com","popped","yes","/",new Date(2006,12,8),false),
            new Cookie(" www.aaa.com","rtime","2","/",new Date(2006,12,8),false),
            new Cookie(" www.aaa.com","ltime","1149940477953","/",new Date(2006,12,8),false),
            new Cookie(" www.aaa.com ","cnzz02","1","/",new Date(2006,12,8),false),
        });[/code]
但是截包就会发现,httpclient会在header里构件多个cookie项,每一项只含有一个cookie,这同IE是不一样的。IE和Firefox会把所有的cookie打包成一个,然后在这个cookie里按照分号把每一项隔开,中间有个空格。
所以如果用httpclient,还想让cookie正常的话,请使用下面这种形式:

[code]String cookies = "yes; rtime=2; ltime=1149940477953; cnzz02=1";
state.addCookie(new Cookie("blog.aaa.com","poped",cookies,"/",new Date(2006,12,8),false)); [/code]
3,编码问题:

httpClient处理编码并不像IE或FireFox那么智能,httpclient记不住上次会话的编码,这样如果默认不是ISO-8859-1的话,那都要在Content-Type里边指定,其实指定的方法也很简单。
本来要提交的是form,默认按照application/x-www-form-urlencoded来发送,在IE里边发送的话截包可以看到,报文中也就指定了这样一个Content-Type,但是人家IE已经把报文的内容按照会话的编码转换好了。而httpclient不行,它并不知道怎么转化,那么你没有设定转换的charset的话,它就按照Charset=ISO-8859-1转换了。这一点上Httpclient应该再改进一下,因为记住server发过来的页面编码是件很简单的事情。只要将类似于”Content-Type: text/html; charset=utf-8″这样的头保存一下状态就可以了。
为了弥补httpclient这一点的傻瓜表现,我们只好每次都手工设置一下喽:
postMethod.addRequestHeader(“Content-Type”,”application/x-www-form-urlencoded; charset=UTF-8″);

4,上传文件问题:

httpClient并不能很好的模拟文件上传。
首先是对于文件类型的识别,IE可以做到按照文件类型分别选择不同的Content-type进行发送,而httpclient就需要我们自己设定,这样如果对一个目录进行自动化上传的话就必须知道该目录下所有文件的类型,以及对应的charset,然后再设置FilePart的时候逐一判断文件扩展名,以赋给不同的content-type和charset,对于一些网页编码是gb2312,而另外一些网页编码是utf-8则会更加麻烦。
其次是如果发送的multiPartPost报文中除了FilePart以外,还需要一些form中的其他input的信息,又是一件很麻烦的事情。刚开始的时候我以为像一般的PostMethod一样,使用PostMethod.addParameters()就可以了,后来才发现这个 MultiPartPost跟那个Post根本就是两个不同的Post。虽然从网页上看都是Form,且只是在input的类型上 MultiPartPost包含一个file类型的input,其他完全一样,但实际上在httpClient中是完全不同的两套方案。对于 MultiPartPost而言,不能用addParameters(),而要使用

[code]someMultiPartPost.setRequestEntity(
     new MultipartRequestEntity(
         new Part[] { art1,part2,part3,part4},
                    someMultiPartPost.getParams())
);[/code]

这种形式。对于要上传的File,那么这些part就是FilePart对象,如果是跟随form的其他input,那么这些part就是 StringPart。这样发出去的报文才是:Content-Disposition: form-data; name=”newFolderName”这种形式。

总结起来,其实也不能怪人家HttpClient,天下间哪有那么多容易做到的事情,尤其是面对Http这样一个说来不算简单的协议。
实际上像这种开源已久的东西,已经有了不少的文档,虽然有时候不太好找,但很多问题还是能够猜或者试出来,毕竟相对比较成熟,而且遵循这rfc来做的。就像我在水母上问问题,有人说的那样,世界上有什么能模拟的像IE一样呢,也不能拿IE的标准要求HttpClient。
我现在的感觉是要想用好HttpClient,或者类似的别的什么工具(其他我就不知道了,有知道类似工具的麻烦告诉我一声),其实还是要把协议吃透,这样一旦遇到什么问题,才知道问题出在哪里,否则就只有郁闷的份儿了。
昨天去Apache的网站,看到一个新的Project叫做HttpComponent从common里边脱离出来,包含了HttpCore, HttpClient,HttpAsync,HttpNIO,HttpCookie,HttpConn,看不出到底想做成什么样子,不过HttpCore 4.0 alpha2已经发布了,以后HttpClient用起来可能又有新的变化了。

一周的时间,用的不是很多,有说得不妥的地方,还请大家指正。

一条评论
  • Dakuo

    2009年11月19日 09:20

    Marked

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注