Я помню такие глупые проблемы с использованием драйверов odbc, даже если в то время это была комбинация java + oracle.
Суть в том, что драйвер odbc, по-видимому, кодирует строку запроса при отправке ее в БД. Даже если поле имеет Unicode и если вы предоставляете Unicode, в некоторых случаях это не имеет значения.
Необходимо убедиться, что отправляемое драйвером имеет ту же кодировку, что и ваша база данных (не только сервер, но и база данных). В противном случае, конечно, вы получите забавные символы, потому что либо клиент, либо сервер смешивают вещи при кодировании / или декодировании. Есть ли у вас какие-либо представления о кодировке (кодовая точка, которую MS хотел бы сказать), которую ваш сервер использует по умолчанию для декодирования данных?
Сличение не имеет ничего общего с этой проблемой:)
См. на этой странице MS , например. Для полей Unicode сортировка используется только для определения порядка сортировки в столбце, не , чтобы указать, как хранятся данные.
Если вы храните свои данные в формате Unicode, существует уникальный способ их представления, это цель Unicode: нет необходимости определять кодировку, совместимую со всеми языками, которые вы собираетесь использовать :)
Вопрос здесь «что происходит, когда я передаю данные на сервер, который не Unicode?». Например:
- Когда я отправляю на сервер строку UTF-8, как она это понимает?
- Когда я отправляю на сервер строку UTF-16, как она это понимает?
- Когда я отправляю строку Latin1 на сервер, как она это понимает?
С точки зрения сервера, все эти 3 строки представляют собой только поток байтов. Сервер не может угадать кодировку, в которой вы их кодировали. Это означает, что у вас будут проблемы, если ваш клиент odbc в конечном итоге отправит на сервер bytestrings (закодированную строку) вместо отправки unicode данных: если вы это сделаете Итак, сервер будет использовать предопределенную кодировку (это был мой вопрос: какую кодировку будет использовать сервер? Поскольку это не угадывание, это должно быть значение параметра), и если строка была закодирована с использованием другой кодировки, dzing , данные будут повреждены.
Это точно так же, как в Python:
uni = u'Hey my name is André'
in_utf8 = uni.encode('utf-8')
# send the utf-8 data to server
# send(in_utf8)
# on server side
# server receives it. But server is Japanese.
# So the server treats the data with the National charset, shift-jis:
some_string = in_utf8 # some_string = receive()
decoded = some_string.decode('sjis')
Просто попробуйте. Это весело. Предполагается, что декодированная строка «Эй, меня зовут Андре», но «Эй, меня зовут Андр ﾃ ﾃ». заменяется на японский ﾃ ｩ
Отсюда мое предложение: вам нужно убедиться, что pyodbc может напрямую отправлять данные в формате Unicode. Если pyodbc этого не сделает, вы получите неожиданные результаты.
И я описал проблему в пути от клиента к серверу. Но такие же проблемы могут возникать при обратной связи с сервера клиенту. Если Клиент не может понять данные Unicode, вы, вероятно, столкнетесь с проблемами.
FreeTDS обрабатывает Unicode для вас.
На самом деле FreeTDS позаботится о вас и переведет все данные в кодировку UCS2. ( Источник ).
- Сервер <-> FreeTDS: данные UCS2
- FreeTDS <-> pyodbc: закодированные строки, закодированные в UTF-8 (из
/etc/freetds/freetds.conf)
Так что я ожидаю, что ваше приложение будет работать правильно, если вы передадите данные UTF-8 в pyodbc. На самом деле, как говорится в django-pyodbc билете, django-pyodbc взаимодействует в UTF-8 с pyodbc, так что с вами все будет в порядке.
FreeTDS 0.82
Однако, cramm0 говорит, что FreeTDS 0.82 не является полностью безглючной, и что существуют значительные различия между 0.82 и официальной исправленной версией 0.82, которую можно найти здесь . Возможно, вам следует попробовать использовать пропатченную FreeTDS
Отредактировано : удалены старые данные, которые не имели ничего общего с FreeTDS, но относились только к коммерческому драйверу Easysoft odbc. К сожалению.