討論服務器端和客戶端工具字符集問題。
這裏提到的客戶端工具包括isql、exp、imp、obsv等使用了dmapi連接數據庫的工具。
初始化建庫工具initdb有unicode編碼參數選項，一般來說，選擇默認的unicode=0，即不使用unicode編碼。
1. 服務器端和客戶端字符集一樣，則客戶端不需要做轉換。
2. 如果服務器端和客戶端字符集不一樣，dmapi會自動判別並做轉換。
比如：服務器是GBK編碼，而客戶端是unicode編碼，客戶端判斷本地編碼，連接到服務器後取得服務器端返回的編碼，
兩者不一樣則在連接上置轉換標記爲TRUE，這樣兩者交互傳遞消息時就可以相互轉換，從而保證各自的編碼爲自身所識別。
反之，服務器端是unicode編碼而客戶端是GBK編碼也可以正確地交互。
以上兩條原則還比較好理解，下面再引入兩種情況：
3. 客戶端工具本身打印的中文信息顯示時遇到的字符集問題
由於編寫客戶端工具時，其中涉及到提示的中文都是在windows系統下書寫的，因此爲GBK編碼，到了默認unicode編碼（如utf-8）
的系統上（如麒麟64位、suse linux、中標5.0等)顯示出來的是亂碼。
因此在編寫客戶端工具時，客戶端需要判斷本地編碼如果是unicode則要將中文字符串轉換。同時也要設置env環境句柄上的local_code屬性爲本地編碼，
這樣服務器返回來的消息通過dmapi自動轉換，不需要客戶端工具自己再做轉換了。
4. 複雜一些的導入導出工具字符集問題
在做導出時，保存的實際數據的編碼格式是和客戶端本地編碼相同，而和服務器端編碼格式無關。
也就是說如果客戶端本地編碼是GBK，那麼導出的數據編碼也是GBK。
dmp文件頭中只要記錄下本地編碼，導入工具就可以根據這個信息設置客戶端env的編碼，即可導入。
如果這個編碼和本地編碼不一致，則可能還需要轉換一下api從服務器返回的消息。
另外一種方法：導出都按照服務器的編碼。這樣導出的時候客戶端env編碼要設置成和服務器一樣。