关于用SQLAlchemy处理Unicode,我遇到了一个奇怪的问题。
简而言之,当我将Python unicode字符串插入unicode列时
在我的MySQL数据库中,我可以轻松地把它取出来。在数据库上
但是,它被存储为一个奇怪的4字节序列(不,这个
似乎与默认打开的“utf8mb4”无关
MySQL数据库)
我的问题是我有一个来自另一台机器的MySQL转储
在SQL中包含直接的UTF8字符。当我试图找回
从另一台机器导入的数据
时间。
下面我包含了一个最小的例子来说明这个问题。
utf8test.sql:设置数据库并用Unicode创建一行
里面的人物
utf8test.py:使用SQLAlchemy打开数据库,插入1行
Python的UTF字符的概念,并检索这两行。
原来Python可以很好地检索它自己插入的数据,
但它在我输入到SQL导入脚本中的文字“ä”上遇到了阻碍。
mysqldump数据集的hexdump研究
MySQL的二进制数据文件本身显示了UTF字符
通过SQL插入是真正的交易(德语umlaut'228'=UTF'c3 bc'),
而Python插入的'228'被转换成序列
“c3 83 c2 a4”,我不明白(见下面的hexdump;
我用“xxx”和“yyy”作为标记来帮助找到它们
在hexdump)。
有人能解释一下吗?
这将创建测试数据库:
dh@jenna:~/python$ cat utf8test.sql
DROP DATABASE IF EXISTS utftest;
CREATE DATABASE utftest;
USE utftest;
CREATE TABLE x (
id INTEGER PRIMARY KEY AUTO_INCREMENT,
text VARCHAR(10)
);
INSERT INTO x(text) VALUES ('xxxü');
COMMIT;
dh@jenna:~/python$ mysql < utf8test.sql
下面是Pyhton脚本:
dh@jenna:~/python$ cat utf8test.py
# -*- encoding: utf8 -*-
from sqlalchemy import create_engine, Column, Unicode, Integer
from sqlalchemy.orm import sessionmaker
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class X(Base):
__tablename__ = 'x'
id = Column(Integer, primary_key=True)
text = Column(Unicode(10))
engine = create_engine('mysql://localhost/utftest',
encoding='utf8')
Base.metadata.create_all(engine)
Session = sessionmaker(engine)
db = Session()
x = X(text=u'yyyä')
db.add(x)
db.commit()
rs = db.query(X.text).all()
for r in rs:
print(r.text)
db.close()
当我运行脚本时会发生这种情况(当我
省略utf8test.sql中的INSERT INTO位:
dh@jenna:~/python$ python utf8test.py
Traceback (most recent call last):
File "utf8test.py", line 23, in <module>
rs = db.query(X.text).all()
[...]
UnicodeDecodeError: 'utf8' codec can't decode
byte 0xfc in position 3: invalid start byte
这里有一个HEXDIMP来确认这两个确实被储存了
在数据库中是不同的。使用高清我也证实了
Python和SQL脚本确实是UTF。
dh@jenna:~/python$ mysqldump utftest | hd
00000000 2d 2d 20 4d 79 53 51 4c 20 64 75 6d 70 20 31 30 |-- MySQL dump 10|
00000010 2e 31 36 20 20 44 69 73 74 72 69 62 20 31 30 2e |.16 Distrib 10.|
00000020 31 2e 33 37 2d 4d 61 72 69 61 44 42 2c 20 66 6f |1.37-MariaDB, fo|
00000030 72 20 64 65 62 69 61 6e 2d 6c 69 6e 75 78 2d 67 |r debian-linux-g|
00000040 6e 75 20 28 69 36 38 36 29 0a 2d 2d 0a 2d 2d 20 |nu (i686).--.-- |
[...]
00000520 4c 45 20 4b 45 59 53 20 2a 2f 3b 0a 49 4e 53 45 |LE KEYS */;.INSE|
00000530 52 54 20 49 4e 54 4f 20 60 78 60 20 56 41 4c 55 |RT INTO `x` VALU|
00000540 45 53 20 28 31 2c 27 78 78 78 c3 bc 27 29 2c 28 |ES (1,'xxx..'),(|
00000550 32 2c 27 79 79 79 c3 83 c2 a4 27 29 3b 0a 2f 2a |2,'yyy....');./*|
最佳答案
c3 83 c2 a4
是ä
的“双重编码”。正如伊利亚所指出的。进一步讨论here
http://mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases提供一个UPDATE
来修复数据。
以下是Python中可能需要修复的内容的清单:http://mysql.rjweb.org/doc.php/charcoll#python
但这很可怕:我看到了c3 bc
(Mojibake代表ü
)和c3 83 c2 a4
(双重编码ä
)。这意味着在同一个代码中发生了两个不同的问题。回到原点,确保在所有阶段都使用utf8(或utf8mb4)。您的数据库可能太混乱,无法从中恢复,因此请考虑重新开始。
可能唯一的问题是其中一个python脚本中没有# -*- encoding: utf8 -*-
但是,不,你确实需要,但是当你使用它的时候,双重编码就发生了。
底线:你有多个错误。