字符集问题上， 最后剩下的是java.File生成静态文件的字符集不对。这个问题已经相对容易解决了，但却非常重要。因为为了适应搜索引擎的扫描强度，已经不允许使用动态响应的sql查询页面，而必须先生成若干静态文件。由此既可以实时响应请求，又可以避免jakatar相对脆弱的web服务功能，让apache承担更大的负载。在数据结构上，相当于非规范化过程。原理上当访问压力不大，维护压力大时，就采用规范化过程；反之则采用非规范化过程。由于搜索引擎时代的到来，无可避免地越来越向非规范化转向。
其实搜索引擎技术本身，就是非规范化。它们不是把搜索的结果存在结构数据库中，而是存进一个散列化的文本文件中。文本文件本身有可能分类型，再存在某种数据库中。象google那样庞大的搜索引擎，大概每个存储服务器（阵列，相当于硬盘）只存放一个散列，然后通过一个树型的目录，功能类似LDAP，向搜索者提供访问已经散列化的数据（相当于静态文件）的接口。这样才可以做到速度非常快的搜索响应。但也意味着，更新各个散列是非常巨大的系统负担。
因此，google拒绝中国政府要求的“过滤政治关键词”的要求，既有其管理者的政治偏好，也有系统技术上的限制。因为中国的关键词是变来变去的，但是非规范化散列一旦确定，就不允许过分频繁的变换。google驯服于天朝帝国的奇怪要求，技术代价可能比中国官方的想象大得多。
负载强度大的页面，会设置自动更新的功能。java中没有定时器，而且不可靠。在linux系统中有现成的crond。因此可靠的办法是使用本地的crod转到相应的帐号上执行：
su -l javaadmin -c "java tools.Importer target=localhost front=publishfragments7"
之类的办法，等同于管理员定时自已执行相应的程序，这样就可以实现静态页面的更新。
至于平常的页面更新，就通过jsp界面上调用的cmd:file之类的标签完成。java:tag是structs/tags中的功能，构筑了通过java:bean，通过jsp标签的调用，操作系统必要功能的作用。由于bean是由自已维护功能的，因此也可以控制安全上的问题。
所以静态文件的字符集如果不对，整个系统就不能正常工作。幸好，此时已经知道读取的文件是gbk，写出的文件是unicode；所以应该与系统本身的默认语言有关。将/etc/sysconfig/i18n文件中的设定改为LANG="zh_CN.GBK"
＃source /etc/sysconfig/i18n
重置了输出默认字符集，初时好象搞定了。但是不知怎么的，过了一段时间 ，忽然发现还不地。
找到File写出字符串的字段；byte[] barray =str.getBytes("gbk");
这回就可以。
这几天的字符集问题，在软件项目止，属系统平台的管理员和首席程序员的工作，负责搭建出一个开发的平台，处理在此平台后面的系统环境的所有变量。以后的程序更改，就是相对重复性的，反复试错，观察结果，测试，修改的工作。