在线翻译小工具开发过程遇到的一些问题

这几天,  一直在研究跟HTTP包有关的方面. 先是HTTP包的抓包分析, 如

 

GET /translate_a/t?client=t&text=I%20am%20a%20man&hl=zh-CN&sl=en&tl=zh-CN&otf=1&pc=1 HTTP/1.1
Accept: */*
Referer: http://translate.google.cn/#en|zh-CN|I%20am%20a%20man
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; aff-kingsoft-ciba; staticlogin:product=cboxf09&act=login&info=ZmlsZW5hbWU9UG93ZXJ3b3JkMjAwOU94Zi4yNTI2OS40MDExLmV4ZSZtYWM9M0U4RUZERjg5ODFENEZCRjk2NDgwRTZFMjZERTg5QUEmcGFzc3BvcnQ9JnZlcnNpb249MjAwOS4wNS4yNS4zLjI3MiZjcmFzaHR5cGU9MQ==&verify=e84a7a0816428dd682b529411469ee5f; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; CIBA)
Host: translate.google.cn
Connection: Keep-Alive
Cookie: PREF=ID=57393dc89fc165f8:U=a7f5ccf3382f3283:NW=1:TM=1267595137:LM=1267595138:S=tFOklsTGqDNhCK2b; NID=32=NwOb4wVWv7g7fr_WflECuqPlMgmXaGVqvGJ3Ef_DlCT_AguO6L42NfKBddJ61pM8WX_SnrZZZGH7_bEpteZ08MMT035HuiMYTlCwzr7_8-QtR8fE8-Auz-U83HvtLjqz

 

这是一个提交到 translate.google.cn 的HTTP包, 意图是让其翻译 "I am  a man" 这句话.  之后, 便可以从服务器接收到的一个HTTP返回包, 内容大概是这样的.

 

HTTP/1.1 200 OK
Date: Mon, 08 Mar 2010 16:46:01 GMT
Expires: Mon, 08 Mar 2010 16:46:01 GMT
Cache-Control: private, max-age=86400
Content-Type: text/plain; charset=UTF-8
Content-Language: zh-CN
Content-Encoding: gzip
Server: translation
Content-Length: 128
X-XSS-Protection: 0

 

***数据部分***

 

其中数据部分是乱码, 没法贴上来. 现在我们来分析分析这个HTTP包的内容(我只简要的挑几个关键的说说)

首先,返回的状态码是200, 显然是成功了.  再看看Content-Type: text/plain; charset=UTF-8 .

 

想到什么了吗 ?  ...   返回的内容字符集编码是UTF-8的, 这也就不奇怪为什么会有乱码了. 

 

先来明确一下我们的目的: 得到经过翻译后相应的中文返回值(采用的是GB2312编码方式)

 

接着我们需要关注的只有两个了:

Content-Encoding: gzip

Content-Length: 128

Content-Length: 128 就不用我说了吧, 谁看谁知道.

 

我们要重点扯的是gzip这个东西.  GZIP是一种用于压缩数据的形式, 采用的好像是deflatet算法, 也没具体去研究过.

 

?     玍*N?I蚄N-V矈甐*)J?矓瀠L|6c龘
Ov瑉>e麚]粩t旘?觼r?
壒
?
箟y@1皢溙爔I
?囎(TY潂x匓掎厃E嘩?掌?%暏9
(zs  

 

看看上面这段乱码(保存到文本文件后, 再贴出来的).  这是服务器返回的HTTP包中的数据部分, 如果查看它的十六进制形式的话,

可以发现它是以 1F 8B 08 00 00 00 00 00 开头的. 没错, 这就是经过GZIP压缩后的数据的头部分, 通过它可以判断是否是经

过GZIP压缩的. 其尾部的信息也是挺是比较特殊的, 好像跟长度有关, 自己去查查看吧.

 

下面我们来说说关于GZIP的解码.  说到这个解码,  真是有点郁闷, 网络上有很多关于GZIP的解码的文章, 大多说的是用ZLIB来

对加密的数据部分进行解压. 之于ZLIB库的使用, 本人也尝试过, 不过效果极其不佳, 问题应该在于自身吧.  从HTTP包头得到的

加密部分直接进行解压的一直没有成功过. 但如果直接用里面的函数进行压缩再解压的话却可以.  为了这个问题,  我也忙活了好

几天,  一直没有找到答案.  最后也是从一个 Demo里面抽出的一个文件包(GZipHelper)才解压成功的 .

 

经过一段时间的折腾, GZIP解码的事是完了, 但解码后的数据咋一看还是有乱码. 于是想到了

 

Content-Type: text/plain; charset=UTF-8

 

想想应该是编码的问题.  几经波折证实了却是编码的问题, 自然而然新的任务就来了 : 

 

UTF-8 编码 转 GB2312编码

 

UTF-8 转 GB2312 必须先将 UTF-8 转为 Unicode 编码 , 然后再将 Unicode 转为 GB2312

转换的代码网上比较多, 这里不多说. (不推荐看vckbase里吴某人那篇, 总觉得是复杂化了)

 

 

 

前面的一系列工作完了之后, 剩下要做的就是开头

 

GET /translate_a/t?client=t&text=I%20am%20a%20man&hl=zh-CN&sl=en&tl=zh-CN&otf=1&pc=1 HTTP/1.1

 

提交数据的问题了. 注意text, 它是 "I am a man" 经过URL编码后的形式

 

至于URL编码, 这里不再多述了.

 

                                                                                                                            记于       2010-03-12