scim输入日文、韩文半完美解决

davidl

命令行下locale命令列出所有locale设定
拷贝显示的内容
在/etc/sysconfig/i18n这份文件里替换为拷贝的内容，特别的将
LC_CTYPE="zh_CN.GB18030"
改成
LC_CTYPE="zh_CN.utf8"
这样scim就可以完美输入日文、韩文。不会有方框了
不过在magic configure center里面的输入法设定里面的scim那项后面的智能输入法几个字变成了方框，其他问题倒没发现

woolzey

这个已经快算是scim的bug了。

scim输入法引擎的基类里面判断该输入法当前是否有效是通过判断该输入法对应的语言，所以对应ja的日文输入法在zh的locale下是没法使用的。不过引擎基类里面默认的方法在判断前先看当前是否是utf-8，如果是就返回有效而不管语言了。

这个方法解决其实有点毛病，不过说bug也谈不上，因为理论上应该由输入法自己去重载这个方法，自己去判断，不过大多数输入法都是直接继承这个方法而没有自己判断。所以就出了这些问题。

解决起来也很简单，直接修改基类在判断完utf-8后在判断一次gb18030就行了。不过在代码里面硬编码这些总是不太妥当。比如要输入日文的gbk编码一样没戏了。

dogking

那些垃圾根本不算是文字，所以没有必要研究那些。中文才是最优秀的

cjacker

[quote:85aab04377="woolzey"]这个已经快算是scim的bug了。

scim输入法引擎的基类里面判断该输入法当前是否有效是通过判断该输入法对应的语言，所以对应ja的日文输入法在zh的locale下是没法使用的。不过引擎基类里面默认的方法在判断前先看当前是否是utf-8，如果是就返回有效而不管语言了。

这个方法解决其实有点毛病，不过说bug也谈不上，因为理论上应该由输入法自己去重载这个方法，自己去判断，不过大多数输入法都是直接继承这个方法而没有自己判断。所以就出了这些问题。

解决起来也很简单，直接修改基类在判断完utf-8后在判断一次gb18030就行了。不过在代码里面硬编码这些总是不太妥当。比如要输入日文的gbk编码一样没戏了。[/quote]
这个怎么能算Bug。For Ja的输入法应该仅仅在ja或者utf8下才有效，如果ja输入法在gb下输入会是什么东西？GB编码的日文。这还是日文吗？

woolzey

日语GB2312就已经收录了，GBK进一步完善，大多数日语在GB下是没问题的。所以如果有人想写一个中文的日语教程，或者记个日语课的笔记之类的东西，就有在GBK下输入日文的需求。这个要求不算过分吧。

所以现在的scim无法用日语输入法输入GB中的日文字符，只能内码输入，这个至少算个缺陷吧。我也没说这是bug，只是说这快要是bug了。如果说日语输入法被设计成只能在ja或者utf-8下工作，那当然就不能算bug。

wkt

这样scim就可以完美输入日文、韩文。不会有方框了

这我想对我没有任何吸引力
中文和英文就够用了
呵呵

haulm

对大多数中国用户来说，英文、中文就够了，其它录入可以有其它方法解决好了。

haulm

多说两句，在UBUNTU里用的是UTF8码，除了原GB文件名乱码外，其它都正常，如果CJACKER认为系统用UTF8码更符合趋势，其实可以在系统增加一个GUI的切换工具（虽然对老鸟来说没必要）。

我的观点有些转变，其实系统用utf8码也没什么，KDE的思想也需要转变一下，不过mysql等包一定要编译成UTF8或GBK，而不是拉丁文。

jiangtao9999

其实系统用utf8码也没什么，KDE的思想也需要转变一下

问题是没那么容易。
编码转换增加的成本比继续使用 GB 系列编码高无数倍。

haulm

转换应该没有什么成本，从gb码转换成utf8码花不了多少时间，何况更多的是保留GBK支持，说白了只是程序问题。需要的是管理员对编码有清晰的判断能力和程序修改能力。如果是面对普通用户，只要有个图形转换界面工具就可以了，而服务器用户，都懂得用iconv命令，或者在编译Mysql时指定参数GBK，现在PW和DZ这种论坛程序也提供UTF8版本，主要的原因是因为国外发行版的中文化在进步，使用freebsd等服务器的用户也不在少数。

Ubuntu也提供Mysql包，和ML一样没有加载默认GBK或UTF8参数进行编译，结果使用的是拉丁文字集，虽然不影响WEB使用，但mysql5的mysqldump导出数据时又会是UTF8编码，结果GB码的拉丁文存储的UTF8存储，很多朋友就晕了。

haulm

最大的困惑其实是文件名，一个UTF8的文件名不能被默认GB码的系统正确认知，一个GB码的文件名也不能被默认UTF8码的系统正确认知。

大量的开源软件都使用了UTF8，而国内没有什么开发力量，这使GB码的应用和GB码数据的唯护成本在增加。。。，用什么编码到头来不是国人说了算。。。

写个批量文件名转换工具好了，用什么编码大家自己喜欢什么用什么!

woolzey

scim的这个问题和默认采用哪种locale其实是两回事。不论默认采用UTF-8还是GB，用户如果有需要，随时可以自由切换。而且在gdm这样的登录管理器和convmv这样的文件系统自动改名工具的帮助下，这个切换并不难。

但是scim目前的状态是没有简单的方法可以在GB下使用其他语言的输入法，而这个实际上是有用户需要的。好的软件不应该自作聪明的教导用户你该有什么样的需求，而应该在能力范围内满足用户的需求，要不跟微软那些把用户当弱智的软件有什么区别。事实上，就scim的这个问题，解决起来表面上看并没有特别的困难。比如在scim中添加一个忽略语言检查的选项：默认行为跟现在一样；但是如果用户有需求，可以打开这个选项。至于当前locale是否能正确显示输入的文字，这个由用户负责。