Le Monde du Java

La Maison de René

导航

公告

爱是恒久忍耐、又有恩慈。
爱是不嫉妒。爱是不自夸。
不张狂。不作害羞的事。
不求自己的益处。
不轻易发怒。不计算人的恶。
不喜欢不义。只喜欢真理。
凡事包容。凡事相信。
凡事盼望。凡事忍耐。
爱是永不止息。

—哥林多前书13:4-8


邮箱地址

Email address

Translation


流量统计

page counter  51La


版权声明

Creative Commons License
Creative Commons License.

图片链接

随笔分类(303)

文章分类(5)

随笔档案(251)

文章档案(11)

相册

统计

Amis

Blogs

Google

Others

学习

日常生活

留学法国

始终逃不过的字符编码问题

小时候刚开始学程序设计的时候就为了中文编码而头痛,尤其是做JSP的时候。不是页面显示不对,就是参数获取上有问题。记得经常和Vincent两个人很快把程序架构写好后,要为了字符编码问题忙上好久。

在第一次飞法国的飞机上就想过,终于可以不用为了编码而困扰了。工作后,公司的项目都是英、法、德三种语言,没有超越Latin1字符集。默认的工作环境也是ISO-8859-1编码集。一年多以来,倒也是相安无事。

最近,开始了一个新项目。不算很大的工作量,也没有什么陌生的技术,一开始进展很是顺利。但是在实际测试时发现了问题,就是表单数据的字符编码。这个项目有两个版本,罗马尼亚语和土耳其语。这两种语言都超越了西欧Latin1字符集,却又分属于ISO-8859-2ISO-8859-9两个不同的编码集。

其实完全可以全部用UTF-8编码了事。但是公司的TomcatMySQL全局环境都显式配置为ISO-8859-1,而且在庞大的底层程序中有好几处都硬编码成Latin1。更改全局配置是不可能的,也不想冒极大的风险来修改底层类。

最后完全迷失于编码转换中……很神奇的是没有乱码出现。Latin1以外的字符被转换成HTML格式编码了。所以就用了很恶心的方法,把读入的表单数据从8859-1读入转换成UTF-8HTML <-> UTF是很容易的)后再转成8859-2/9显示(由于客户方终端不支持UTF-8方案,不能直接用输出Unicode)。尽管8859-1编码集不支持Latin1字符集以外的字符,但是这层转换的内部处理还是通过Unicode,不存在信息丢失问题。说白了就是UTF-8 -> ISO

不过数据库中的数据却始终无法正常存储。数据永远以乱码读出,而且无法转换。奇怪的是,如果把控制台编码换成8859-2/9的话,可以在数据库中看到正确的数据。但是运行

SELECT HEX(columnFROM table

得到的结果却是错误的。获得的十六进制编码是信息经过8859-1编码后的Unicode值。这个问题涉及到系统底层类,数据库配置等多个方面。Rene甚至不知道在数据库中贮存的到底是什么。

最后的理解是这样的,底层接口类把数据转换成8859-1编码存入数据库,同样也以8859-1读出。SQL请求以字节流返回,这也说明了在控制台下可以用8859-2/9编码看到正确结果。但是中间结果由于全局配置的关系,被编码成8859-1,所以显示的Unicode值不对。在程序中,由于数据取出后被强制转换成8859-1编码,所以造成了信息丢失。就再也找不回Latin1以外的字符了。

最终的解决方案,让Rene恶心到可以从Montparnasse上跳下来。由于数据在存入数据库前是正确的,其实在存入时也是正确的。所以打算在存入前,把信息转成十六进制编码。理论上应该是可行的,就是会很难看,非常非常难看。

posted on 2009-11-05 00:24 Rene 阅读(238) 评论(0)  编辑  收藏 所属分类: Programming


只有注册用户登录后才能发表评论。


网站导航: