On Thu, 26 Oct 2000, hashao wrote:
> Hello gis88564,
> On Thursday, October 26, 2000, gis88564 wrote:
>
> g> [EMAIL PROTECTED] CCCII，
> g> 但是實際上台灣習慣用 big5，大陸習慣用 bgk，而廠商又喜歡用 Unicode
> g> ，而日本，韓國也都有自己習慣的 charset，所以想到輸入法何不
> g> 在啟動時，根據外部的轉換表格動態配置自己的 charset 來對映到
> g> 現存的 charset 呢？ [EMAIL PROTECTED] big5<=>unicode 的表格
> g> ，載入後，便動態給 big5 和 unicode [EMAIL PROTECTED]@個輸入法
> g> 自己看得懂的 32bit 編號，接下來，要載入輸入法（像倉頡）表格
> g> 時，假設表格是用 big5 ，那便把 big5 [EMAIL PROTECTED]@個轉成輸入
> g> [EMAIL PROTECTED]
> g> 被內碼的問題綁死，將來做各 charset 互轉時也會更方便些，什麼
> g> base on CCCII, big5, unicode, jis 都無所謂羅，反正只是個外
> g> 部的表格而已。
>
> 不是太看得懂。不過印象中 xcin 現在使用 UCS4 [EMAIL PROTECTED]
> 轉換成別的編碼(BIG5,GB)只是因為
> 目前X庫不能實時轉換國際化部分(也可以，麻煩)，而 XIM 是不能做到
> 實時編碼轉換的，所以 xcin 需要為不同的 locale [EMAIL PROTECTED]
>
> 如果有隨便轉換輸入法的協議， xcin 直接支持輸入輸出編碼轉換應該不是什麼
> 問題。 chinput 3 [EMAIL PROTECTED]@些 hack ，不
> 是很標準。
>
> IIIMP 應該可以解決這個問題。
>
我之前所提的簡單的說，就是做各種內碼的轉換，之所以提出”輸入法
內部字元集”是因為，不論採用何種編碼(UCS-4)，都會遇到缺字的問題
，也就是在 A 字元集有 aa，而 B 字元集卻沒有 aa，就算選擇 UCS-4
當內碼也不是萬靈丹，畢竟 UCS-4 沒定的字，沒有就是沒有，所以一
[EMAIL PROTECTED] UCS-4 時，掉字是可想而知的，所以讓使用者有
選擇自己喜歡的字元集當核心是比較好的，或者在做內碼轉換時， aa
由 A => B => C 時，萬一 B 缺了 aa 這個字，最後轉到 C 時，只要
C 定這 aa 這個字，也應該要能轉換成功，或者，如果你假設 UCS-4
[EMAIL PROTECTED] superset ，那上述的問題也就不會發生囉。。:)
[EMAIL PROTECTED]
表達出自己的意思。。 :~~~
不過我實在不欣賞 X 對 locale，字形，input method 的處理，
感覺上 X [EMAIL PROTECTED]
