摘要：我們需要注意的是只有在數據庫服務器端與客戶端的編碼一致的情況下我們才能正常的顯示非編碼而在中默認會將查詢的字符串強制將其轉換為。而正常的情況應該指定其編碼為中國而設定就是相當于修改上述的編碼為。

近期在項目中,要對1張100多萬條記錄的表進行查詢,然后進行一些數據的統計,但是在這個過程中,發現只查詢出來幾條數據就出現了UnicodeDecodeError了。
在這里,我們使用sqlalchemy庫進行查詢,其內部還是Cx_Oracle來進行對應的操作,使用的Python版本為3.5.0,宿主系統為Windows 2008 Server,然后進行類似如下的操作:

from sqlalchemy import create_engine

engine = create_engine("oracle://demo:123456@192.168.1.202/TEST")
conn = engine.connect()
sql = "select t.type from TS t"
result = conn.execute(sql)
for row in result:
    print(row["type"])

在這里,我們首先創建1個到數據庫的連接,然后進行對應的查詢操作。很不幸的是,只查詢不到10條記錄就出現了1個UnicodeDecodeError錯誤了。
本來以為是數據庫的服務器編碼問題,因此在create_engine函數中追加了encoding參數,將其更改為:

engine = create_engine("oracle://demo:123456@192.168.1.202/TEST",encoding="UTF-8")

而另外1種可用的方式直接在連接路徑中指定編碼,類似如下:

engine = create_engine("oracle://demo:123456@192.168.1.202/TEST?charset=utf-8")

但是問題還是沒有解決。在網上搜索了一下都沒有找到適應的解決方案,突然想起來之前在使用Mysql數據庫(個人喜歡Postgresql多一些)的時候,出現亂碼的時候,我們常常會進行如下的操作:

set names gbk;

我們通過這種方式設置客戶端的編碼,而不是服務器端的編碼,來解決終端下出現亂碼的情況(由于Postgresql默認數據庫就是UTF-8因此出現亂碼的可能性較低)。而另外在Linux下安裝Oracle的客戶端時,設置了1個NLS_LANG的環境變量,詳情可以參考Ubuntu14.04安裝Oracle Instant Client這篇文章,當然這篇文章有一些細節的東西沒有介紹。
一般情況下,我們在cmd中進行如下的設置:

setenv NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK

我們指定Oracle消息使用的語言為簡體中文,而客戶端的字符集為GBK。
另外,我們還可以執行如下的語句來確保上述的操作是正確的:

SELECT * FROM v$nls_parameters;

由于上述數據庫服務器是部署在Windows上的,因此其結果自然為GBK,因此如果我們客戶端使用UTF8字符集進行解碼,自然而言會出現解碼的錯誤。
我們需要注意的是,只有在數據庫服務器端與客戶端的編碼一致的情況下,我們才能正常的顯示非ASCII編碼,而在sqlalchemy中默認會將查詢的字符串強制將其轉換為Unicode。因此類似Python3的如下過程:

>>> a="中國".encode("gbk")
>>> a
b"xd6xd0xb9xfa"

而在sqlalchemy中由于強制進行編碼轉換,因此類似執行如下的過程:

>>> a.decode("utf-8")
Traceback (most recent call last):
  File "", line 1, in 
UnicodeDecodeError: "utf-8" codec can"t decode byte 0xd6 in position 0: invalid continuation byte

因此就出現上述的問題了。而正常的情況應該指定其編碼為GBK:

>>> a.decode("gbk")
"中國"

而設定NLS_LANG就是相當于修改上述的編碼為GBK。

參考文章:

http://docs.oracle.com/cd/E12...
docs.sqlalchemy.org/en/latest/core/engines.html