首页
开源项目
问答
动弹 博客 翻译 资讯
专题
活动 招聘 众包 码云代码托管
16
回答
 Python的中文问题

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

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

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

Python
举报
李绣雪
发帖于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年前 回复
mallon： 回复 @宏哥 : 我再等等，等那个Tornado的Python3版本完善了，那么Web方面的就没有问题了，如果PyCharm能支持Tornado的模板就更完美了 6年前 回复
宏哥： 回复 @mallon : 我决定冒险! 6年前 回复
mallon： 回复 @宏哥 : 哈哈我也想用噢，一直下不了决心，万一碰到个急需的第三方模块不支持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写代码，把中文的内码传递给外设，也会出现类似情况。
顶部