Press "Enter" to skip to content

升级Django到svn trunk需要做的工作

花了不少时间,走了不少弯路,多了不少Bug,总算是把理财易的Django升级到svn trunk版本了,值不值得还不知道,不过,用新的总归没什么坏处,而且,1.0已经不远了,现在做好准备也不错。

首先删除原来的Django 0.96版的安装,全新安装svn trunk版,启动服务器,打开首页,出现一堆错误。首先是前面提到过的那个用来做“记住密码”密码功能的自定义的DualSessionMiddleware,它引用的页面发生了变化,SessionWrapper类已经不存在了,所以启动报错。暂时修改Settings文件,使用默认的session middleware,OK,通过了。然后提示_()函数不存在。这个是gettext函数,用来做多语言界面的,查了一下 兼容列表,果然,这个函数被移除了。于是在所有出现这个函数的文件里加上from django.utils.translation import ugettext as _,通过。进留言板,进不去,提示编码转换错误,什么"ascii can not decode”什么的,跑到官网一查,说是什么修改了对Unicode字符串的处理,现在整个系统各个环节的Unicode已经统一(大概是输入,转换,和输出)。结果是:需要把所有的用%来拼接字符串的地方,加上u标志。比如s=’用户名%s不存在’ % username,如果这个username是中文,这里就会报错,一定要把前面的这个变量加上u,标明这是Unicode变量。

改了N多地方,总算又通过了,然后继续测试,发现另一个地方又是转换错误,但是这里只是把一个包含中文的数组用join的方法串起来,我去哪里加这个u呢?想来想去,找到了定义这些中文的地方,在每一个中文变量的前面加上u,通过了。现在,代码变得相当丑陋了。(为了给省和市的名字加这个u,做了近200个替换,也不知道有没有留下后遗症)。

想到的地方都解决了,就更新到了服务器上。结果第二天有人报告无法注册,原来检查用户名是否符合规则的地方也变了。以前获取到的用户输入都是UTF8的,用正则来判断是否包含中文,需要先转换成Unicode,于是对输入字符串做了一个decode(‘utf8’),现在,这一步变成了多余的,所有的输入本来就是Unicode的。(但是读写数据库的时候似乎会自动转换成UTF8,否则写入Mysql应该会报错。)

后来又想到WAP那边也有中文的处理,打开手机一试,果然如此,中文用户无法登录了。以前的解决方案是利用客户端的能力,把输入的字符串编码成URL模式,中文会变成%D7%B7这样的字符串,拿到以后用urllib.unquote来解析出来,然后,如果客户端是UTF8的,要用decode(‘utf8’)来处理,如果客户端是gb2312的,要用decode(‘gb2312’)来处理。(虽然我在所有的WAP页面里都指定了编码是UTF8,但是在我的Palm上使用Blazer浏览器,仍然是GB2312编码的。)因为无法预知客户端如何编码,所以用try做两次解码。但是现在,不管用哪个,都会报错。

在这个问题花了许多时间,尝试各种各样的解码规则,都失败了。后来终于想到了问题所在,在不使用任何解码的情况下,服务器端接收到的是%D7%B7的字符串,说明这一步是正确的,然后,在unquote以后,文字就已经变成乱码了,按理说,应该只是把%变成\x而已。这一步实在是出乎意料,因为按理说收到的都是英文字符串,难道对英文字符串的处理也会因为编码而不同?经过测试,还真是如此。以前request.get拿到的字符串是没有编码的,也就是说%D7%B7就是作为一个普通的ascii字符串,但是现在,这个字符串被作为了Unicode字符串。unquote方法在解析Unicode字符串的时候,得到的结果是错误的。知道了问题,答案就找到了。先对输入的字符串做一个encode(‘ascii’),再进行unquote,啊,终于结束了。

另外,系统在从0.96更新到0.96.1的时候(也就是打了那个多语言方面的补丁以后),多语言功能消失了。IE的用户看上去是正常的,但是Firefox的用户看到的都是英文。(如果Firefox的语言选项里只有zh和zh-cn,那他看到的是中文,如果有了en,哪怕是在最下面,还是会显示英文界面。)跑到google group里去发了个帖子,最后得到了官方的回复,这是他们的一个Bug,在修改的过程中出错了,而且,只有zh-cn,zh-tw和pt-br出错,zh-cn需要改成zh_CN,在conf下面的default setting文件里。算了,还是不要改了,反正暂时关了多语言也没关系,等官方版本修改了这个再说吧。

11月4号更新:今天根据用户的反馈,测试了一下,发现Opera访问WAP的问题还是没有解决,中文编码不正确。不只是WAP上,用PC上的Opera登录WAP站,它的中文也有问题。在Postfield里面使用:e标识符以后,其它的浏览器都会根据自己的编码(gb2312或utf8)对中文进行URL编码然后发送,但是在Opera上编码以后,却丢了一半的值(一个汉字经过GB2312的URL编码以后应该是%D7%C7这样的两组值,但是Opera却只返回了后面的这一个,解码当然就不对了。

改了几种编码都不对,后来把:e的编码方式去掉一试,居然成功了。看来Opera对中文的兼容性已经远远超越了其它的手机浏览器,能够不编码发送完整的中文到服务器端。但是把:e去掉以后,别的浏览器又不对了(Palm上的Blazer会丢掉最后一个汉字)。不过既然知道了具体的现象,也就有解决办法了。通过服务器端判断User_Agent是否包含Opera字符来判断用户使用的是不是Opera浏览器,如果是,在生成页面的时候就不要添加:e标识符。经过测试,PC上和Palm上的Opera Mini都已经可以正常使用中文了。