Хотя в freetds.conf установлена ​​кодировка UTF-8, pyodbc fetchall возвращает кодировку в юникоде?

Я использую pyodbc, ODBC с freetds для доступа к удаленной базе данных MSSQL. Недавно я перешел с Centos + Python 2.4 на Ubuntu + Python 2.7, и они ведут себя по-разному. Мой файл freetds.conf:

[global]
        # TDS protocol version
        tds version = 4.2

        # If you get out-of-memory errors, it may mean that your client
        # is trying to allocate a huge buffer for a TEXT field.  
        # Try setting 'text size' to a more reasonable limit 
        text size = 64512

[server]
        host = server
        port = 1333
        tds version = 8.0
        client charset = UTF-8

Мой код Python (упрощенный):

import pyodbc
msConn =  pyodbc.connect('DSN=%s;UID=%s;PWD=%s' % (self.dsn, self.user, self.passwd))

msCur = msConn.cursor()
msQuery='''select ...'''
msCur.execute(msQuery % startUpdateStamp)

for row in msRows:
    print rows

Когда я выполняю приведенный выше код на своем сервере Centos (с Python 2.4), все специальные символы кодируются в utf-8. Однако при выполнении того же кода с той же конфигурацией на сервере Ubuntu (python 2.7) специальные символы находятся в юникоде. Как будто конфигурация client charset = UTF-8 полностью игнорируется.

Однако я попытался установить client charset на другие значения, в ответ сервер не разрешает соединение. Это означает, что настройка клиентской кодировки проходит. Я также пытался изменить tds version = 8.0 безрезультатно.

Я также просматривал здесь, но ответ не объясняет, почему для одной и той же базы данных два системы дают две кодировки.

Как я могу заставить Ubuntu возвращать UTF-8? Я не разбираюсь в MSSQL или ODBC. Любая помощь приветствуется.


person yutongluo    schedule 27.06.2013    source источник
comment
Оказывается, в моей системе Centos я использовал более старую версию pyodbc. Данные на самом деле в Юникоде, но старая версия неправильно возвращает utf-8. (Полный журнал изменений для pyodbc находится здесь.) Старое поведение возврата utf-8 был исправлен в более поздней версии. Ответ здесь был абсолютно правильным.   -  person yutongluo    schedule 27.06.2013