一、我对java中编码的理解(摘)

1. 编码的产生
    对电脑而言,只认识0,1; 而现实世界是由各种符合组成,要想让计算机解释现实世界,就必须建立一套现实世界中的符号 和 计算机能处理的符号之间的对应关系,这个对应关系就是编码

2. 在一个编辑器中,当我们在键盘上敲入一个字符时,在该编辑器上就会显示对应的字符,这个过程用计算机执行步骤来解释大致如下:
    输入字符 –> 编辑器根据设定的编码格式把字符编成01格式 -> 编辑器再按编码规则对01解码–> 显示字符

3.几种常见的编码格式
1. ASCII码: 
    计算机中最早的一套编码格式,采用7位二进制表示一个常见的字符,我们知道,计算机是按照字节来处理数据的,一个字节8位,因此用一个字节就可以表示一个ASCII字符,且还有一个位空位,规定最高位不用,常见的把最高位设定为0。 7位二进制最多可以表示128个字符(2的7次方),ASCII码只能表示常见的英文字符,数字,和少量的符号(没办法,谁让计算机是人家老美先发明的啊,优先考虑本土语言,理解理解)
注: 由于ASCII最早定义,使用广泛,使得之后出现的新的”字符“(不是汉字喔)编码都尽量和它兼容 

2. iso-8859-1:
    尽管ASCII应用广泛,但是由于它定义的字符太少,即使对于同是使用字母语言的国家也不够用,更别说我们汉字啦,西欧许多国家使用拉丁语言,其中的很多字符ASCII编码都不认识喔,这当然会让它们不爽啦,总不能因为这个问题让那些国家的人不使用电脑吧, 于是ISO/IEC就推出了另外的一套编码标准ISO-8859-1. 这套标准完全和ASCII兼容,它使用8位二进制表示一个字符 —--- 刚好一个字节,其中最高位是0时的解释和ASCII一样(这样不就完全兼容啦,兼容很好理解吧),但最高位是1时则用于定义其它字符,这样就在保证和ASCII兼容的同时又扩展了ASCII,可以多表示字符啦

3. GBK编码
    光有字母语言国家的编码就可以么?, 可以啊,好好学习英语啊, 要不你看不懂啊,不想学?,那就不玩啊,呵呵,当然不会啦,对于中国,韩国,日本等这些国家,推出了一种新的编码GBK码, 在编码上GBK采用单双字节混合的方式,它也兼容ASCII喔,具体GBK怎么个编码,你查看资料啦, 这里重点关注的是编码的演化,提供的是思路哈

4. Unicode
    Unicode是为了打破这种编码的各自为政,带有强烈地域性的标示而推出的一种编码格式,目的是要达到世界的大同,大同好啊,方便交流啊,就是晚了点,计算机一出现就出来多好,就没了现在让程序员头疼的编码转来转去的麻烦了,恩,看来有界限的人心是会带来麻烦的,好了,啰嗦了这么多,才算真正引入正题,为什么会出现乱码,如何解决乱码
   
4. 揭示web中乱码的病因
    比如说现在有两个人,张三 和 make分别来自中国和美国,现在他们访问同一台j2ee服务器,他们都向服务器发送了一条消息
        张三:  嗨,我是张三
        Make:  hello, I’m make
    假如张三发送的信息采用的编码格式是GBK, make的是ASCII, 对于浏览器而言,留言器没有把发送的信息采用的编码格式告诉给web服务器(之前的浏览器没提供这个功能,又是地域性的见识啊,现在最新版的不知道有没有),web服务器不知道你发过来的信息编码格式啊,怎么解释呢,没办法只好提供个默认的吧,恩还是用iso-8859-1吧(毕竟java也是老美搞出的啊,没办法),英语的没问题,web服务器能听懂,毕竟大家都说英语嘛,并且make对web服务器而言,懂得字母还少了点呢;  汉语的就不行了,就好比一个人只懂汉语,另一个人只懂英语,怎么交流啊,可以交流?那就只好”~!@#¥%“, 这就是java中乱码的病因吧

5. 如何避免乱码的产生
    知道了病因,对症下药就好啦, 
      1. 让浏览器明确指定信息的编码格式, 这个不行啦,程序员干涉不了啦,这不是你的问题啦,不知道现在的浏览器是否已提供这种机制啊,请知道的朋友明示:?
      2. 明确采用GBK编码处理请求的数据啊
      3. 因为一般的浏览器可以解析多种编码格式,我们的web响应内容,最好指定编码格式喔,这个大家都知道啦
      4. 不知道那些国外的站点是如何处理中文的,请大师们开始啊

      注: 以上是个人理解,错漏之处难免,欢迎抓虫

摘自:http://topic.csdn.net/u/20090331/11/0D5E721C-0F61-4F60-9C0A-C643F649022D.html

类别: JVM. 标签: , , . 阅读(129). 订阅评论. TrackBack.

Leave a Reply

3 Comments on "一、我对java中编码的理解(摘)"

avatar
Feng
Guest

目前浏览器的策略都是服务器返回什么编码就会用什么编码再提交表单上去,所以只要像tomcat那样写一个好的filter大部分问题就解决好了。不过其中的对于get提交的数据会因为浏览器不同而有差异,尤其是在jsp中自己在<a>中拼接的参数数据,tomcat为解决此类问题提供了一个<connector>的URIEncoding属性。
另外,你举的例子中,如果网站的编码处理正确了,make不应该看到乱码,而是会看到很多方框,表示本地找不到可用的字库,不能渲染。这方面我记得在很久以前在英文系统中用netscape其实都能看到中文的,应该是浏览器自带了基本的中文字体。

隔叶黄莺
Guest

java 自己没什么方法进行编码检测,可以用第三方的工具,如 FindBugs 和 jlint 能对字节码进行检测;而 Checkstyle 是对编码规则上的检验,针对源代码的。

GreatGhoul
Guest

java中有没有什么方法进行编码检测呀.