问题描述,采用gbk页面传输中文到后台,后台显示乱码。
经过查看原来是prototype把前台的gbk自作聪明变成了utf8(这是合理的方法哈),造成后台无法取得正确的编码。
经过考虑还是用后台来解决乱码问题,网上找了几个urlencode的函数都不行,所以还是用php本身解决这个问题比较省心。如下的函数:
iconv("UTF-8", "GBK//IGNORE",substr(Char_cv($pwuser),0,50));
注意输出编码的解释IGNORE这个非常重要,后来在网上查到了一个帖子和我一样的问题,现在终于解决了全部的问题。
总结下prototype的乱码问题:
1 出来的乱码:这种问题可以在服务器配置是解决,我利用apache的defaultcode解决
2 进去的乱码:我建议大家还是用服务器端方法解决,这种方法效率比js解决高效些,也就是上述的表述。
最后表达下一条建议,建议如果没有历史问题,所有页面使用utf-8编码比较好,这个问题不仅是prototype我相信jquery或者yui都会有,因为utf-8才是最好的编码,也省却了很多麻烦,所以在使用这些东西的时候最好还是用utf8的页面。
经过查看原来是prototype把前台的gbk自作聪明变成了utf8(这是合理的方法哈),造成后台无法取得正确的编码。
经过考虑还是用后台来解决乱码问题,网上找了几个urlencode的函数都不行,所以还是用php本身解决这个问题比较省心。如下的函数:
iconv("UTF-8", "GBK//IGNORE",substr(Char_cv($pwuser),0,50));
注意输出编码的解释IGNORE这个非常重要,后来在网上查到了一个帖子和我一样的问题,现在终于解决了全部的问题。
总结下prototype的乱码问题:
1 出来的乱码:这种问题可以在服务器配置是解决,我利用apache的defaultcode解决
2 进去的乱码:我建议大家还是用服务器端方法解决,这种方法效率比js解决高效些,也就是上述的表述。
最后表达下一条建议,建议如果没有历史问题,所有页面使用utf-8编码比较好,这个问题不仅是prototype我相信jquery或者yui都会有,因为utf-8才是最好的编码,也省却了很多麻烦,所以在使用这些东西的时候最好还是用utf8的页面。