>>有个疑问，我看mysql数据库当前采用的字符集是Latin-1,它支持的字符集包括GBK,就是说把GBK编码的字符送进字符集为Latin-1的mysql数据库，mysql会自动处理这样的转换

数据库本身不做任何转换。由于数据库一般都支持双字节，所以即使数据库默认字符集是Latin-1，它也能处理GBK编码的字符串。

Java GUI如果通过RMI和App Server通讯（例如调用EJB），也不用考虑字符串处理的问题，因为JVM之间序列化对象，对象之内的字符串都是UTF-8编码。

Java GUI如果通过SOAP和App Server通讯，看SOAP调用的XML信息用什么编码，如果也是UTF-8编码，也没有问题，或者采用客户端操作系统默认的编码也可以，如果是其他编码，客户端就必须自己编程进行转换编码。此时编码问题主要和服务端使用的XML解析器有关系，我没有仔细研究过。

Java GUI如果通过HTTP和Servlet通讯的话，客户端需要编程模拟浏览器，我还没有研究过这种编程模式下的编码问题。


这里有个客户端通过封装的http协议和远程servlet，ejb通信的框架，不过目前只支持swing。通过它的思路可以构造自己的框架，没时间看的说。

突然又想起碰到过这样的中文问题。一个applet上显示中文的问题。

是这样的： 如果用JDK的Java-plugin集成到浏览器（在控制面板->Java(TM)Plug-in控制面板->浏览器 选中IE/NC），那么打开IE浏览applet的时候会在系统托盘处出来一个java控制台，而且这样的话，applet中显示的所有中文都变成“口”（占两个字节位置的方框）。如果不用Java-plugin集成浏览器，中文就可以正常显示。 当时我们处理中文统一用iso-8859-1的编码，applet包由于用的是别人的，没有源码，所以没有仔细研究。 就一直没弄清楚是什么原因产生的乱码。

当浏览器用JDK的plugin时，感觉装入applet时速度很慢，而用浏览器自带的applet解释器反而快，且没有乱码。 另外，微软打官司赢了，可以不在windows系统中绑定java，那是否意味着今后applet不再被IE支持，要想在IE中看applet，就必须装sun的java plugin了。

我也碰到过类似问题，IE的JVM可以正常显示中文，但是Sun JRE不行。但是这应该是JRE/JDK的版本问题，JDK1.4.0就有这个问题，到了JDK1.4.1就解决了，applet里面的中文不会变成方框了。Sun的Java控制台可以隐藏掉，不显示在系统托盘上。

MS IE自带的JVM版本非常低，大概相当于JRE1.1.7的样子，很多类库都没有。Sun JDK启动慢是因为带的东西多，不像IE Java plugin那么精简。

读，受益非浅!

to yadan
http://www.bs-factory.org/
这个框架很好，正是我现在做的一些EJB组件。
其中的TREE SERVICE和我的思路很相似，如果你有时间可以交流交流。

上页