common-jdbc說明

oracle使用西文數據庫時，使用jdbc直接訪問得到的是亂碼，需要手工轉碼，雖然oraclejdbc的文檔表明似乎oci方式是
完全等同于客戶端方式，只要客戶端nls設置正確就可以正常存取，但是鄙人折騰一天都沒搞定。另外實驗發現，此種西文
數據庫情況，如果不轉碼，在jsp頁面輸出的話，由瀏覽器負責轉碼也可以保證輸入輸出正常，但是中間部分就沒法做單元
測試和一些值修改操作了。而且在我使用的wicket框架里面也無法這樣設置轉換。

最后還是絕定通過修補jdbc的方式來實現自動轉碼，最初想法是反編譯oracle的jdbc, 對setString, getString, sql，進行轉碼修補，但是發現反編譯后的代碼有問題，修復工作量太大。再考慮這種方式會導致不容易升級jdbc，遂想用proxy的方式來實現一套jdbc殼，起初考慮省時間用p6spy的修改，后來搜索發現網絡強人[http://www.dling.com] 令少已經干了同樣的事情了，就直接拿過來改了。

他主要是改了2個地方，一個是getString做了中文轉碼，而setString沒轉碼，只做了trim處理（trim的原因是oracle的char的問題。 和通常的理解不同的是， char類型并不比varchar2更有效率。 在現在版本的oracle中，char實際是一種偽裝的varchar2. 保留char可能是為了和以前版本兼容。而char本身在使用上有很多問題，主要是他會自動補齊字符串，導致比對時候容易犯錯。所以建議9i以后的數據庫今可能使用varchar2代替char），但是我實驗有點問題。

相對令少的修改：
 1. 對rs.getObject方法也進行了判斷，是String對象就轉碼。另外還修補了幾個update方法。
 2. 修補了stamment 和pstatemnt 的setString和 setObject，進行了轉碼
 3. 對所有會調用sql的地方進行了轉碼，防止sql中含有中文的情況。

基本轉碼方式是 取數據時 從系統字符集（8859-1）轉換到gbk， 存的時候反之。

配置參看單元測試程序代碼。

@Before
 public void setUp() throws Exception {
  DriverManager.registerDriver(new com.dingl.jdbc.CommonDriver());

   conn = DriverManager.getConnection(
  "jdbc:common/dbtype=oracle&host=localhost&port=1521&dbname=ora9i&useTrim=yes&charset=gbk&os-charset=iso8859-1", "system", "manager1");
 }