Harbour v3.1 and Unicode 補完計畫 2.50 問題
發表於 : 2014-09-23, 12:26
話說...自從將 Harbour 從 3.0 換為 3.1 之後，發現中文字上發生了一些變化，
改變原因在於 win_ole 這部份，以前一些使用 FileXLS 將資料輸出至 Excel
含有中文字方面出現了些許變化，例如宏碁的「碁」字，內碼為 0xF9D6，
轉至 Excel 卻不是 0xF9D6, 於是追蹤了 win_ole 方面到底是哪裡出了問題，
最後終於找到是 %hbdir%\contrib\hbwin\olecore.c 檔案，從 3.1 之後
將 hb_oleItemToString 的轉碼工作由 MultiByteToWideChar 改為由
codepage 方式處理，變成了 hb_itemCopyStrU16，於是將這部份函數
改為舊版 3.0 的程式碼，測試結果，嘿嘿！中文字正常了！
但是，後來想想，這麼做方式不就跟開發者的原意相違背了嗎？
開發者無異想建立一個完整的轉碼機制， Harbour for Unicode 版
也開始著手修改了，這麼改下去，將來也許會造成很大困擾也說不定，
於是便發了信件至 harbour user 詢問，結果的到的答覆是，
big5.txt 中的 big5 轉 unicode 列表，只轉到 0xF9D5，
而宏碁的「碁」字剛好是 0xF9D6，超出了範圍，於是開發者便新增了
for windows 的 'CP950' 語系，支援編碼就比 big5 增加到 0xF9FE，
那宏碁的「碁」字就包含在內了，經過測試，呵呵～已經能正常將「碁」
字輸出至 Excel 了，程式碼方面也要作些許改變如下：
主程式一開始需加上：
由上面發現，我已經將 codepage 從 big5 改為 cp950 了，
另外，在主程式的 INIT PROCEDURE 中也作了些修改：
hb_CDPSelect 也從 'BIG5' 改選用 'CP950' 了！
本以為這事件到此就算落幕解決了，哪知道過沒幾天，客戶又反映說有些中文字
又變成亂碼了，例如油?菜籽的「?」字，轉至 Excel 又變成亂碼，經追問客戶之下
才知道客戶安裝了所謂的 'Unicode 補完計畫 2.50', 這套軟體的字型硬是從 CP950 的
0xF9FE 增加到 0xFEFE，所以，只要超過 'CP950' 的 0xF9FE 編碼，
轉至 Excel 全部變成亂碼!!
如今唯一解決之道，就是找到一份 Unicode 補完計畫 2.50 對照 Unicode 的轉碼資料，
才能正確的將超過 0xF9FE 的內碼正常的轉至 Unicode 去，
於是便上網找了好久的資料，終於在網站: http://moztw.org/docs/big5/ 中
找到了一份 Unicode 補完計畫 2.50 版的 big5 -> unicode 對照表，
於是便將該表中大於 0xF9FE 到 0xFEFE 之間的編碼貼上 big5.txt，
然後執行 big5_gen 產生出 big5.c，再將 big5.c 中的相關程式碼複製到 cp950.c 中
相對應的程式碼去，重新編譯產生新的 hbcpage.lib, 然後複製到 %hbdir%\lib\ 改名為
hbcpage_u250.lib，以後只要客戶有安裝 'Unicode 補完計畫' 的，.lnk 檔便從
hbcpage.lib 改為連結 hbcpage_u250.lib 就好了，
以後就不再擔心有什麼內碼轉不出來了!!
ps. 若有香港網友有使用 'Big5-HKSCS' 編碼，也可以參照此方法做出一份
自己的 codepage lib.
改變原因在於 win_ole 這部份，以前一些使用 FileXLS 將資料輸出至 Excel
含有中文字方面出現了些許變化，例如宏碁的「碁」字，內碼為 0xF9D6，
轉至 Excel 卻不是 0xF9D6, 於是追蹤了 win_ole 方面到底是哪裡出了問題，
最後終於找到是 %hbdir%\contrib\hbwin\olecore.c 檔案，從 3.1 之後
將 hb_oleItemToString 的轉碼工作由 MultiByteToWideChar 改為由
codepage 方式處理，變成了 hb_itemCopyStrU16，於是將這部份函數
改為舊版 3.0 的程式碼，測試結果，嘿嘿！中文字正常了！
但是，後來想想，這麼做方式不就跟開發者的原意相違背了嗎？
開發者無異想建立一個完整的轉碼機制， Harbour for Unicode 版
也開始著手修改了，這麼改下去，將來也許會造成很大困擾也說不定，
於是便發了信件至 harbour user 詢問，結果的到的答覆是，
big5.txt 中的 big5 轉 unicode 列表，只轉到 0xF9D5，
而宏碁的「碁」字剛好是 0xF9D6，超出了範圍，於是開發者便新增了
for windows 的 'CP950' 語系，支援編碼就比 big5 增加到 0xF9FE，
那宏碁的「碁」字就包含在內了，經過測試，呵呵～已經能正常將「碁」
字輸出至 Excel 了，程式碼方面也要作些許改變如下：
主程式一開始需加上：
代碼: 選擇全部
#if (HB_VERSION_RELEASE>=3) && (HB_VERSION_MAJOR >= 1)
REQUEST HB_LANG_ZHB5 // 正體中文 Big5 .lnk 要加上 hblang.lib
// REQUEST HB_CODEPAGE_BIG5 // .lnk 檔要加入 hbcpage.lib
REQUEST HB_CODEPAGE_CP950 // .lnk 檔要加入 hbcpage.lib
#endif
另外，在主程式的 INIT PROCEDURE 中也作了些修改：
代碼: 選擇全部
#if (HB_VERSION_RELEASE>=3) && (HB_VERSION_MAJOR >= 1)
hb_LangSelect('ZHB5') // 選擇 Big5 中文語系
hb_CDPSelect('CP950') // GTWVT 需?[此，WinTitle 才會正確顯示中文字
SET( _SET_OSCODEPAGE, 950)
#endif
本以為這事件到此就算落幕解決了，哪知道過沒幾天，客戶又反映說有些中文字
又變成亂碼了，例如油?菜籽的「?」字，轉至 Excel 又變成亂碼，經追問客戶之下
才知道客戶安裝了所謂的 'Unicode 補完計畫 2.50', 這套軟體的字型硬是從 CP950 的
0xF9FE 增加到 0xFEFE，所以，只要超過 'CP950' 的 0xF9FE 編碼，
轉至 Excel 全部變成亂碼!!
如今唯一解決之道，就是找到一份 Unicode 補完計畫 2.50 對照 Unicode 的轉碼資料，
才能正確的將超過 0xF9FE 的內碼正常的轉至 Unicode 去，
於是便上網找了好久的資料，終於在網站: http://moztw.org/docs/big5/ 中
找到了一份 Unicode 補完計畫 2.50 版的 big5 -> unicode 對照表，
於是便將該表中大於 0xF9FE 到 0xFEFE 之間的編碼貼上 big5.txt，
然後執行 big5_gen 產生出 big5.c，再將 big5.c 中的相關程式碼複製到 cp950.c 中
相對應的程式碼去，重新編譯產生新的 hbcpage.lib, 然後複製到 %hbdir%\lib\ 改名為
hbcpage_u250.lib，以後只要客戶有安裝 'Unicode 補完計畫' 的，.lnk 檔便從
hbcpage.lib 改為連結 hbcpage_u250.lib 就好了，
以後就不再擔心有什麼內碼轉不出來了!!
ps. 若有香港網友有使用 'Big5-HKSCS' 編碼，也可以參照此方法做出一份
自己的 codepage lib.