GB2312<GBK<GB18030
GB2312大概是94年出来的,GBK是2000年的标准吧。
GB2312大概是94年出来的,GBK是2000年的标准吧。
解决方案 »
- java.lang.ClassFormatError: Incompatible magic value 218762506 in class file 如果你见过这个异常就来说两句吧。 谢谢!
- import java.sql.*问题
- forward
- jfreechart 做折线图时,横轴刻度文字的方向问题
- 页面打印的问题
- 学校要做项目,半年时间,急急急急急~~~~~~~~~~~
- JSP解密的问题!!
- 权限控制问题!
- 寻求合作伙伴…………我出50m空间
- 我用tomcat3.2.1学习jsp,是中文的就不显示,我怎么解决这个问题???
- 救命啊,nvarchar类型的中文怎么查询不出来啊? 我改怎么办??
- tomcat5.0.19,如何部署自己的虚拟目录?
GBK包含了几乎所有的汉字。
所以如果有生僻汉字不能正常显示,而其他汉字可以,那么就使用GBK就解决了
但它识别gb2312,于是把gb2312转化成GBK,有的系统则不可以!!!!!!
Utf-8是一种标准存储编码格式,用utf-8编码后的字节流具有非常好的纠错和兼容能力。用utf-8编码(encode)unicode码时不会有信息损失。当然用utf-8解码(decode)utf-8编码的字节流,生成unicode码时也不会有信息损失。但禁止用utf-8解码非utf-8编码的字节流。总之Utf-8可以编码任何unicode 码,但只能解码utf-8编码的字节流。
Utf-16和utf-8用法是一样的,仅是一点不同:utf-16是双字节倍数编码,utf-8是单字节倍数编码,在英文国家里用utf-8和ascii编码后的字节流是一样的,这样有利于系统平稳升级到支持utf-8的系统里,但系统要升级到支持utf-16就要把所有数据都更新一遍,这显然不能接受。注意:utf-16根据字节排序不同有两种编码
Iso8859-1是西方国家频繁使用的字符编码格式。用iso8859-1编码unicode码中的东方字库部分的字符时统统编码成??,也就是说:用iso8859-1编码unicode码时信息会有损失。但用iso8859-1解码任意(iso8859-1编码的和非iso8859-1编码的)字符流时,信息不会有损失,这是因为一个字节中的所有256个字符对iso8859-1都是合法的都是合法的。有时候在一些linux操作系统和一些应用服务器里,默认的解码方式是iso8859-1,这是大多数乱码的原因。
Gb18030,gbk,gb2312是汉字字符的编码格式,用gb18030(gbk,gb2312和gb18030是同一系列,不过字库要小,但使用方式是一样的,这里不区分,统统用gb18030)编码unicode码时非中英文的字符会被编码为?,也就是说,用gb18030只能编码unicode中的中英文字符,其他的字符都会被损失掉。同样用gb18030解码只能解码gb18030编码的字符流。
Xml文件中 是告诉浏览器要用要用指定的编码格式解码自身这个文件,当然要求浏览器首先要支持这个编码格式(在客户端),jsp页面的字符集是告诉jsp服务器要用要用指定的编码格式解码自身这个jsp文件(在服务器段). 然而在servlet程序中response.setContentType("text/html; charset=GBK");是告诉servlet程序用指定编码格式编码(在服务器段)
字符集转换的基本思想很简单,用某种字符编码规则编码,就用什么编码规则解码,经常出问题的深层次原因是java对字节流未提供编码信息,可以认为这是一个严重的失误。估计未来的java能提供这样的信息。…待续
涉及编码问题的地方有:java类文件编辑时,java类文件编译时,实施文件,服务器指定,jsp文件内指定,xml(html)内指定,servlet文件指定,资源连接点配置中指定.
不能正常显示原因通常在两个地方:字符集;字库。对于通用的软件,一般都提供完整的字库支持。所以一般问题是解码不正确。
“我们知道,数据库是以gb2312编码形式保存”
不是所有数据库都是以gb2312编码形式保存,我知道的,mysql和oracle就不是用这种编码保存的,不信你转码后加进去,在不转码取出来试试,
同意楼上的说法,gb2312<gbk但是有的系统不支持gbk,所以建议使用gb2312,通用性强一些
:)