Saya ingat pernah mengalami masalah bodoh seperti ini menggunakan driver odbc, meskipun saat itu kombinasi java+oracle.
Intinya adalah bahwa driver odbc tampaknya mengkodekan string kueri saat mengirimnya ke DB. Bahkan jika bidangnya adalah Unicode, dan jika Anda memberikan Unicode, dalam beberapa kasus tampaknya tidak masalah.
Anda perlu memastikan bahwa apa yang dikirim oleh driver memiliki encoding yang sama dengan Database Anda (tidak hanya server, tetapi juga database). Jika tidak, tentu saja Anda mendapatkan karakter yang funky karena klien atau server mencampuradukkan banyak hal saat encoding/atau decoding. Apakah Anda memiliki gagasan tentang rangkaian karakter (titik kode seperti yang dikatakan MS) yang digunakan server Anda sebagai default untuk mendekode data?
Kolasi tidak ada hubungannya dengan masalah ini :)
Lihat halaman MS itu Misalnya. Untuk bidang Unicode, susunan hanya digunakan untuk menentukan urutan pengurutan dalam kolom, bukan untuk menentukan bagaimana data disimpan.
Jika Anda menyimpan data Anda sebagai Unicode, ada cara unik untuk mewakilinya, itulah tujuan Unicode:tidak perlu mendefinisikan charset yang kompatibel dengan semua bahasa yang akan Anda gunakan :)
Pertanyaannya di sini adalah "apa yang terjadi ketika saya memberikan data ke server yang tidak Unicode?". Misalnya:
- Saat saya mengirim string UTF-8 ke server, bagaimana cara memahaminya?
- Saat saya mengirim string UTF-16 ke server, bagaimana cara memahaminya?
- Saat saya mengirim string Latin1 ke server, bagaimana cara memahaminya?
Dari perspektif server, semua 3 string ini hanyalah aliran byte. Server tidak dapat menebak penyandian di mana Anda menyandikannya. Artinya Anda akan dapatkan masalah jika klien odbc Anda akhirnya mengirim bytestrings (string yang disandikan) ke server alih-alih mengirim unicode data:jika Anda melakukannya, server akan menggunakan pengkodean yang telah ditentukan (itu adalah pertanyaan saya:pengkodean apa yang akan digunakan server? Karena tidak menebak, itu harus menjadi nilai parameter), dan jika string telah dikodekan menggunakan a pengkodean yang berbeda, dzing , data akan rusak.
Ini persis seperti melakukan dengan 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')
Cobalah. Itu menyenangkan. String yang didekode seharusnya menjadi "Hei nama saya André", tetapi "Hei nama saya Andr". é diganti dengan bahasa Jepang
Karenanya saran saya:Anda perlu memastikan bahwa pyodbc dapat mengirim data secara langsung sebagai Unicode. Jika pyodbc gagal melakukan ini, Anda akan mendapatkan hasil yang tidak diharapkan.
Dan saya menjelaskan masalahnya dengan cara Client to Server. Tetapi masalah yang sama dapat muncul saat berkomunikasi kembali dari Server ke Klien. Jika Klien tidak dapat memahami data Unicode, kemungkinan besar Anda akan mendapat masalah.
FreeTDS menangani Unicode untuk Anda.
Sebenarnya, FreeTDS mengurus semuanya untuk Anda dan menerjemahkan semua data ke UCS2 unicode. (Sumber ).
- Server <--> FreeTDS :Data UCS2
- FreeTDS <--> pyodbc :string yang dikodekan, dikodekan dalam UTF-8 (dari
/etc/freetds/freetds.conf)
Jadi saya berharap aplikasi Anda berfungsi dengan benar jika Anda meneruskan data UTF-8 ke pyodbc. Faktanya, karena tiket django-pyodbc ini menyatakan, Django-pyodbc berkomunikasi dalam UTF-8 dengan pyodbc, jadi Anda akan baik-baik saja.
GratisTDS 0.82
Namun, cramm0 mengatakan bahwa FreeTDS 0.82 tidak sepenuhnya bebas bug, dan bahwa ada perbedaan yang signifikan antara 0.82 dan versi patch resmi 0.82 yang dapat ditemukan disini . Anda mungkin harus mencoba menggunakan FreeTDS yang ditambal
Diedit :menghapus data lama, yang tidak ada hubungannya dengan FreeTDS tetapi hanya relevan dengan driver odbc komersial Easysoft. Maaf.
