距离我在《web.py应用工具库：webpyext 》里说要换用bottle，已经过去快两个月了……事实上在那之前我已经開始着手在换了。眼下那个用于 Backbone.js 介绍的样例程序已经完毕更换，其他一些原来基于web.py的应用也在逐步重写中。期间各种小坑不断，还好至今还没有碰到什么大坑……只是目測应该也不会有大坑。
unicode
作为非英文应用的开发人员，unicode是一个绕只是去的坑。 web.py 对此是不作处理的，全都按原编码方式处理。 bottle 则作了一个有点奇怪的处理：
request.query 或 request.forms 都是一个 FormDict 类型，其特点是：当以属性方式訪问数据时——如 request.query.foo，返回的结果是 unicode ，当以字典试訪问数据时——如 request.query['foo']，则返回的结果是原编码字符串。混合使用的时候，一不小心就会出问题……
比方大部分时候都用属性方式，可是某个数据须要有特定默认值的时候，就会习惯性地用字典方式操作： request.query.get("foo", "bar") ，这时就easy出编码错误。这样的情况应该使用 request.query.getunicode() 函数。
更彻底的方式是用 args=request.query.decode("utf-8") 然后 args.foo 或 args["foo"] 就都能够返回 unicode 了。
至于在实际应用中要用哪种方式来处理，就自己看情况选择了。
cookies
bottle 在这点上比 web.py 要坑，问题主要是出在 path 上。
web.py 的 setcookie 函数參数选择非常少，比方 path 就没有，默认仅仅能存放于"/"，尽管这算是一个小小的限制，但使用中基本不会有什么问题。
可是bottle就坑了，它的 set_cookie 的默认 path 是当前路径，也就是说，在这个页面上存入的 cookie 在别的页面一般是取不到的，不熟悉这点的人差点儿都要栽在这里。
并且更坑的一点是： set_cookie 有 path 參数能够指定 path ，可是 get_cookie 却可耻地没有这个 path 參数可选——也就是说，你即使设置了其他 path ，假设 get_cookie 的时候不是刚好在那个 path 下的话，也取不到……
这个……反正我如今能用的办法就是跟 web.py 里一样，把全部的 cookie 都放到"/"以下，至少眼下用下来感觉没问题。
除了这个坑以外，相比 web.py 的 cookie ， bottle 另一点不算不足但有时不太方便的地方：
web.py 的 cookie 能够存放不论什么可持久化的数据，比方 dict/list 。可是 bottle 的 cookie 似乎仅仅能放字符串，我试过放 list 出错。
当然这不是什么大问题，用一个 json.dumps/json.loads 就可以解决。