16
回答
Python的中文问题
利用AWS快速构建适用于生产的无服务器应用程序,免费试用12个月>>>   

如图:当其中的变量tablename为英文时,一切正常,但是为中文时,就会提示错误。

这个文件的开头是#coding:gbk,并且保存成ANSI编码。

请诸位指点是什么原因引起的,我应该怎样解决?

举报
李绣雪
发帖于6年前 16回/2K+阅
共有16个答案 最后回答: 6年前

引用来自“李绣雪”的答案

引用来自“neverno”的答案

处理下编码试试

import sys
type = sys.getfilesystemencoding()
tablename = tablename.decode('gbk').encode(type)

奇怪的是,使用你的语句之后,倒是没有报错了。

但是不知道为何,当tablename为中文时,差不出任何记录,而为英文时,却可以查出来。

我可以确定我的数据库表中是有中文,且查询语句是正确的。

这样的话,你的tablename和sql变量都需要把编码处理一下(或者就处理sql)~~~

引用来自“李绣雪”的答案

引用来自“neverno”的答案

引用来自“李绣雪”的答案

引用来自“neverno”的答案

处理下编码试试

import sys
type = sys.getfilesystemencoding()
tablename = tablename.decode('gbk').encode(type)

奇怪的是,使用你的语句之后,倒是没有报错了。

但是不知道为何,当tablename为中文时,差不出任何记录,而为英文时,却可以查出来。

我可以确定我的数据库表中是有中文,且查询语句是正确的。

这样的话,你的tablename和sql变量都需要把编码处理一下(或者就处理sql)~~~
tablename和sql变量都处理过,中文查询仍然不行。
那我也无能为力了,等大牛回答吧,按理,python声明好编码,文件编码,搭配上数据库那边的编码统一起来(连接时设置charset),没出现过状况~

--- 共有 1 条评论 ---
李绣雪我后来尝试使用 type = sys.getfilesystemencoding() sql = sql.decode('utf-8').encode(type) 将之前的gbk改为utf-8,结果就可以使用中文查询了。。。但是,搞不懂为什么会这样,已经被py的编码彻底搞晕了。 6年前 回复

首先 编码很多人产生误区的地方是:你的编辑器  比如我们用的eclipse 一般是gbk 但是修改以后也支持utf8 (中文目前只有这两种)  如果编辑器是utf8 那你就在源文件头加#-*- coding: utf-8 -*-  但一般都是gbk 实在不行 用win7记事本修改 那个是gbk错不了 但是#-*- coding: utf-8 -*- 数据库因为gbk比较省空间嘛 你可以分3种情况选择 表级别编码 )engine=innodb default_character_set=gbk; 也可以直接数据库客户端级 vim -o $mysql_home$/my.cnf -e "[mysql] default_character_set=gbk" 还可以服务器端改 但是如果你服务器端是utf8(插入的时候使用的是utf8编辑器) 客户端即使改成了gbk也是乱码 反过来 即使服务器是latin 客户端修改后取出来还是gbk正常码 只是少占用一些内存而已 Utf8多占些而已 不过确保不会有写不出来的字符  javascript最麻烦  几句话说不清楚 但保证数据库不是乱码就还是很好改 也是一层一层套 db->server cgi -> js -> html

乱码问题很简单的 你只要记住 "一层一层处理 除了Ajax 其他都是层层传递的" 

--- 共有 1 条评论 ---
李绣雪呃,好深奥~~ 6年前 回复
pywin32函数一般都是Unicode的,需要转成Python内部Unicode格式
--- 共有 7 条评论 ---
李绣雪py3以上版本都不用考虑这些编码问题了吗?那太好了! 6年前 回复
kajhsdjkah回复 @宏哥 : 我再等等,等那个Tornado的Python3版本完善了,那么Web方面的就没有问题了,如果PyCharm能支持Tornado的模板就更完美了 6年前 回复
宏哥回复 @mallon : 我决定冒险! 6年前 回复
kajhsdjkah回复 @宏哥 : 哈哈我也想用噢,一直下不了决心,万一碰到个急需的第三方模块不支持Python3就麻烦了,例如数据库的驱动... 6年前 回复
宏哥回复 @mallon : 这也是我后来坚持用python3的原因.其实python3也就这点好过python2,其他的进步真是看不到. 6年前 回复

你数据库里面是什么编码呢?得把整句 sql 转成对应的编码才行啊。在此之前可以

from __future__ import unicode_literals

让面量统一使用 Unicode。

PS:拼字符串的 SQL 很容易升天。

--- 共有 4 条评论 ---
ValueError回复 @李绣雪 : 如果没有这个 feature,也可以尝试在所有字符串面量前面加前缀 u,就像 u"My Literal" 这样 6年前 回复
李绣雪多谢,但是不知道是不是因为我是py2.5的原因,使用from __future__ import unicode_literals会报错,而我用easy_install也没有下载到第三方库。 这是自带的么?py什么版本开始自带的? 6年前 回复
ValueError回复 @李绣雪 : 我是指被注入的危险,DB API 是肯定可以传参查询的,你用的应该是 ADO 吧,应该也有传参查询的方式,但我不了解。参考 http://bit.ly/I3IPVD 6年前 回复
李绣雪你说的升天,是因为有可能编码不一样导致错误吗? 但是如果不拼字符串的话,我应该怎样做比较好呢? 6年前 回复

应该是你的字符编码和数据库记录编码不一致.

编码问题最好统一成UTF-8,在程序内转换成unicode.不能确定编码的话,可以试下用chardet判断字符编码.

>>> chardet.detect(rawdata)

{'confidence': 0.98999999999999999, 'encoding': 'GB2312'}

--- 共有 1 条评论 ---
李绣雪好的,谢谢 6年前 回复
另外源代码文本文件不要用GBK编码,用UTF-8,我现在看到有人用GBK就来气,呵呵
--- 共有 2 条评论 ---
mark35回复 @李绣雪 : UTF-8是不需要BOM的 6年前 回复
李绣雪刚开始我也是使用utf-8的,不过不知道是不是因为Windows自带的记事本的原因,我使用它保存成utf-8,结果还是乱码。后来发现这个utf-8又有BOM和无BOM的区别。我应该保存成有BOM的utf-8,还是无BOM的utf-8? 6年前 回复
你混淆了编辑状态和实际运行状态,中文的内码可能存在的差异。这个在linux下编程经常遇到,如果你没概念的话,用C写代码,把中文的内码传递给外设,也会出现类似情况。
顶部