Detaillierte Erklärung von Speicherlecks und verstümmelten chinesischen Zeichen im MySQL-Modul in Python

Beim Herstellen einer Verbindung zu MySQL-Python schreibt standardmäßig jeder

con=MySQLdb.connect(user='xxx',passwd='xxx',host='xxx',port=6600,charset='gbk')

Sobald „gbk“ angegeben ist, setzt MySQL-Python standardmäßig use_unicode=True. Das Ergebnis ist, dass MySQL-Python das Python-eigene Codec-Modul für die Zeichendekodierung verwendet. In der Praxis stellt sich jedoch heraus, dass der GBK-Codierungszeichensatz der MySQL-Bibliothek größer ist als der GBK-Codierungssatz von Python. Einige Zeichen, die in MySQL gespeichert werden können, lösen Fehler aus, wenn sie mit dem Python-Codec analysiert werden. Ein schwerwiegenderes Problem besteht darin, dass use_unicode=True vor mysql-python1.2.3 mysql-python dazu veranlasste, diesen Speicherleckfehler zu dekodieren. Alle dekodierten Datenbankzeichenfolgen werden über MySQL-Python als Unicode-Objekte ausgegeben und müssen erneut kodiert werden, um in eine Datei ausgegeben zu werden.

Die Lösung besteht darin, use_unicode=False zu erzwingen. Das heißt:

con=MySQLdb.connect(user='xxx',passwd='xxx',host='xxx',port=6600,charset='gbk',use_unicode=False)

Auf diese Weise kommt es zu keinen Speicherverlusten und es ist keine Codierung bei der Ausgabe der Datei erforderlich. Es vermeidet auch das Problem, dass der Codec von Python die in MySQL GBK gespeicherten Zeichenfolgen nicht analysieren kann. Schließlich können wir für MySQL4 den Zeichensatzparameter leer lassen:

con=MySQLdb.connect(user='xxx',passwd='xxx',host='xxx',port=6600,use_unicode=False)

Das löst dieses Problem perfekt, haha