Java Unicode编码系统

Unicode是一种通用的国际标准字符编码,能够表示世界上大多数的书面语言。

为什么java使用Unicode系统?
在Unicode之前,有很多语言标准:

ASCII (美国信息交换标准代码)。
ISO 8859-1 用于表示西欧语言。
KOI-8 用于表示俄文。
GB18030 和 BIG-5 用于表示中文等等。

这导致两个问题:
指定代码值对应于各种语言标准中的不同字母。
具有大字符集的语言的编码具有可变长度。一些常见字符被编码为单字节,其他需要两个或多个字节。
解决办法
为了解决这些问题,开发了一种新的语言标准,即Unicode系统。在unicode中,每个字符保存为2个字节,因此java也使用2个字节的字符。(这里的两个字节表示是指每个字符代表的两个字节的二进制值,是映射规则,但是存储时有另外的规则,如utf-8,utf-16,JVM使用的是utf-16)

最小值: \u0000
最高值: \uFFFF

Java编码问题存在两个方面:JVM之内和JVM之外。
1、Java文件编译后形成class
这里Java文件的编码可能有多种多样,但Java编译器会自动将这些编码按照Java文件的编码格式正确读取后产生class文件,这里的class文件编码是Unicode编码(具体说是UTF-16编码(用2或4个字节表示一个字符,即1或2个16进制,高位补0))。
因此,在Java代码中定义一个字符串:
String s=“汉字”;
不管在编译前java文件使用何种编码,在编译后成class后,他们都是一样的----Unicode编码表示。
2、JVM中的编码
JVM加载class文件读取时候使用Unicode编码方式正确读取class文件,那么原来定义的String s=“汉字”;在内存中的表现形式是Unicode编码。
3、流中的编码是否正确转换和被正确解读

浅析unicode和UTF-8、UTF-16、UTF-32的区别
1、区别编码字符集和字符集编码
首先要注意的是unicode是编码字符集(将字符编码),而UTF-8、UTF-16、UTF-32是字符集编码(好绕哎有没有)。下面我来具体解释一下:

比如汉字的”汉”,在unicode中,汉”的unicode值为0x6C49。问:把这个”汉”字保存到计算机中(硬盘、内存),机器码是多少呢?
学过《计算机组成原理》的人都知道,计算机内部存储的形式都是0101的二进制数字串。”汉”字保存在计算机里肯定也是0101的数字串。”汉”的unicode值是0x6C49,转化为2进制 1101100 01001001,那么把这个”汉”字保存到计算机中也是 1101100 01001001 吗?答案:NO!

答案:取决于用到的字符集编码是哪种 (字符集编码是用于存储的)
比如你用到的字符集编码是UTF-8,那么”汉”字在计算机内部保存的值为0xE6B189,也就是111001101011000110001001,可以看到”汉”字变成了3个字节。UTF-8用1-8个字节来保存unicode编码的字符。
而如果用UTF-16来保存,那么”汉”字仍为仍为0x6C49,也就是 1101100 01001001。UTF-16只能是选两字节或四字节来保存字符
而UTF-32就是把所有的字符都用32bit也就是4个字节来表示。
所以这就是编码字符集(unicode)和字符集编码的区别。

2、unicode的一段历史
首先要注意unicode并不是用2个字节来表示字符串的。unicode旧版本,所有的字符都是2个字节。但是现在的unicode编码在一百一十万左右,远远超过了2的16次方,也就是2个字节。所以,现在讲unicode编码是2个字节是错误的!。至于这段历史,大家可以自行google。unicode2.0版本也就是UCS-2,是2个字节的,现在是unicode4.0版本,UCS-4是4个字节的,现在远远还没填充完。

3、过程
ide中java的文件编码,将.java文件按照utf-8保存到.java文件中然后javac将.java文件按照utf-8读取、编译成unicode(utf-16)的.class文件,然后JVM按照unicode的方式读取、执行代码命令。这里整体需要把控的过程是.java文件按照utf-8保存时没有乱码,还有javac是按照utf-8来读取就可以了。如果涉及到流,就要看tomcat接收的编码格式是否与浏览器中h5页面、js定义的、提交上来的编码格式一致。要知道浏览器由于历史原因做了一个urlencode的过程,tomcat本身也自带了urldecode的过程,而且旧版本的tomcat默认是以iso-8859-1编码来进行二次解码。

Java中unicode编码详解
首先讲一下几种字符的编码方式:

ASCII码
我们知道,在计算机内部,所有的信息最终都表示为一个二进制的字符串。每一个二进制位(bit)有0和1两种状态,因此八个二进制位就可以组合出256种状态,这被称为一个字节(byte)。也就是说,一个字节一共可以用来表示256种不同的状态,每一个状态对应一个符号,就是256个符号,从0000000到11111111。

上个世纪60年代,美国制定了一套字符编码,对英语字符与二进制位之间的关系,做了统一规定。这被称为ASCII码,一直沿用至今。

ASCII码一共规定了128个字符的编码,比如空格“SPACE”是32(二进制00100000),大写的字母A是65(二进制01000001)。这128个符号(包括32个不能打印出来的控制符号),只占用了一个字节的后面7位,最前面的1位统一规定为0。

2、非ASCII编码

英语用128个符号编码就够了,但是用来表示其他语言,128个符号是不够的。比如,在法语中,字母上方有注音符号,它就无法用ASCII码表示。于是,一些欧洲国家就决定,利用字节中闲置的最高位编入新的符号。比如,法语中的é的编码为130(二进制10000010)。这样一来,这些欧洲国家使用的编码体系,可以表示最多256个符号。

但是,这里又出现了新的问题。不同的国家有不同的字母,因此,哪怕它们都使用256个符号的编码方式,代表的字母却不一样。比如,130在法语编码中代表了é,在希伯来语编码中却代表了字母Gimel (ג),在俄语编码中又会代表另一个符号。但是不管怎样,所有这些编码方式中,0—127表示的符号是一样的,不一样的只是128—255的这一段。

至于亚洲国家的文字,使用的符号就更多了,汉字就多达10万左右。一个字节只能表示256种符号,肯定是不够的,就必须使用多个字节表达一个符号。比如,简体中文常见的编码方式是GB2312,使用两个字节表示一个汉字,所以理论上最多可以表示256x256=65536个符号。

中文编码的问题需要专文讨论,这篇笔记不涉及。这里只指出,虽然都是用多个字节表示一个符号,但是GB类的汉字编码与后文的Unicode和UTF-8是毫无关系的。

3.Unicode

正如上一节所说,世界上存在着多种编码方式,同一个二进制数字可以被解释成不同的符号。因此,要想打开一个文本文件,就必须知道它的编码方式,否则用错误的编码方式解读,就会出现乱码。为什么电子邮件常常出现乱码?就是因为发信人和收信人使用的编码方式不一样。

可以想象,如果有一种编码,将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码,那么乱码问题就会消失。这就是Unicode,就像它的名字都表示的,这是一种所有符号的编码。

Unicode当然是一个很大的集合,现在的规模可以容纳100多万个符号。每个符号的编码都不一样,比如,U+0639表示阿拉伯字母Ain,U+0041表示英语的大写字母A,U+4E25表示汉字“严”。具体的符号对应表,可以查询unicode.org,或者专门的汉字对应表。

Unicode的问题
需要注意的是,Unicode只是一个符号集,它只规定了符号的二进制代码,却没有规定这个二进制代码应该如何存储。

比如,汉字“严”的unicode是十六进制数4E25,转换成二进制数足足有15位(100111000100101),也就是说这个符号的表示至少需要2个字节。表示其他更大的符号,可能需要3个字节或者4个字节,甚至更多。

这里就有两个严重的问题,第一个问题是,如何才能区别unicode和ascii?计算机怎么知道三个字节表示一个符号,而不是分别表示三个符号呢?第二个问题是,我们已经知道,英文字母只用一个字节表示就够了,如果unicode统一规定,每个符号用三个或四个字节表示,那么每个英文字母前都必然有二到三个字节是0,这对于存储来说是极大的浪费,文本文件的大小会因此大出二三倍,这是无法接受的。

它们造成的结果是:1)出现了unicode的多种存储方式,也就是说有许多种不同的二进制格式,可以用来表示unicode。2)unicode在很长一段时间内无法推广,直到互联网的出现。

5.UTF-8

互联网的普及,强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32,不过在互联网上基本不用。重复一遍,这里的关系是,UTF-8是Unicode的实现方式之一。

UTF-8最大的一个特点,就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号,根据不同的符号而变化字节长度。

UTF-8的编码规则很简单,只有二条:

1)对于单字节的符号,字节的第一位设为0,后面7位为这个符号的unicode码。因此对于英语字母,UTF-8编码和ASCII码是相同的。

2)对于n字节的符号(n>1),第一个字节的前n位都设为1,第n+1位设为0,后面字节的前两位一律设为10。剩下的没有提及的二进制位,全部为这个符号的unicode码。

下表总结了编码规则,字母x表示可用编码的位。

Unicode符号范围 | UTF-8编码方式
UTF字节数 (十六进制) | (二进制)
——————–+———————————————

一个字节 0000 0000-0000 007F | 0xxxxxxx
两个字节 0000 0080-0000 07FF | 110xxxxx 10xxxxxx
三个字节 0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
四个字节 0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

下面, 还是以汉字“严”为例,演示如何实现UTF-8编码。

已知“严”的unicode是4E25(100111000100101),根据上表,可以发现4E25处在第三行的范围内(0000 0800-0000 FFFF),因此“严”的UTF-8编码需要三个字节,即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后,从“严”的最后一个二进制位开始,依次从后向前填入格式中的x,多出的位补0。这样就得到了,“严”的UTF-8编码是“11100100 10111000 10100101”,转换成十六进制就是E4B8A5。

Unicode与UTF-8之间的转换
通过上一节的例子,可以看到“严”的Unicode码是4E25,UTF-8编码是E4B8A5,两者是不一样的。它们之间的转换可以通过程序实现。

在Windows平台下,有一个最简单的转化方法,就是使用内置的记事本小程序Notepad.exe。打开文件后,点击“文件”菜单中的“另存为”命令,会跳出一个对话框,在最底部有一个“编码”的下拉条。

iso8859-1编码

属于单字节编码,最多能表示的字符范围是0-255,应用于英文系列。比如,字母a的编码为0×61=97.很明显,iso8859-1编码表示的字符范围很窄,无法表示中文字符。但是,由于是单字节编码,和计算机最基础的表示单位一致,所以很多时候,仍旧使用iso8859-1编码来表示。而且在很多协议上,默认使用该编码。比如,虽然”中文”两个字不存在iso8859-1编码,以gb2312编码为例,应该是”d6d0 cec4”两个字符,使用iso8859-1编码的时候则将它拆开为4个字节来表示:”d6 d0 ce c4”(事实上,在进行存储的时候,也是以字节为单位处理的)。而如果是UTF编码,则是6个字节”e4 b8 ad e6 96 87”.很明显,这种表示方法还需要以另一种编码为基础。

java对字符的处理

在java应用软件中,会有多处涉及到字符集编码,有些地方需要进行正确的设置,有些地方需要进行一定程度的处理。
1
getBytes(charset)

这是java字符串处理的一个标准函数,其作用是将字符串所表示的字符按照charset编码,并以字节方式表示。注意字符串在java内存中总是按unicode编码存储的。比如”中文”,正常情况下(即没有错误的时候)存储为”4e2d 6587”,如果charset为”gbk”,则被编码为”d6d0 cec4”,然后返回字节”d6 d0 ce c4”.如果charset为”utf8”则最后是”e4 b8 ad e6 96 87”.如果是”iso8859-1”,则由于无法编码,最后返回 “3f 3f”(两个问号)。

java .class类的编码为:unicode;

windows 默认的编码为:中文:gb2312; 英文:iso8859;

String str = “张三” ;

byte[] jiema= str.getBytes(“gb2312”) ; //解码

String bianma = new String(jiema,”UTF-8”);//编码 如果上面的解码不对 可能出现问题

new String(charset)

这是java字符串处理的另一个标准函数,和上一个函数的作用相反,将字节数组按照charset编码进行组合识别,最后转换为unicode存储。参考上述getBytes的例子,”gbk” 和”utf8”都可以得出正确的结果”4e2d 6587”,但iso8859-1最后变成了”003f 003f”(两个问号)。

因为utf8可以用来表示/编码所有字符,所以new String( str.getBytes( “utf8” ), “utf8” ) === str,即完全可逆。

setCharacterEncoding()

该函数用来设置http请求或者相应的编码。

对于request,是指提交内容的编码,指定后可以通过getParameter()则直接获得正确的字符串,如果不指定,则默认使用iso8859-1编码,需要进一步处理。参见下述”表单输入”.值得注意的是在执行setCharacterEncoding()之前,不能执行任何getParameter()。java doc上说明:This method must be called prior to reading request parameters or reading input using getReader()。而且,该指定只对POST方法有效,对GET方法无效。分析原因,应该是在执行第一个getParameter()的时候,java将会按照编码分析所有的提交内容,而后续的getParameter()不再进行分析,所以setCharacterEncoding()无效。而对于GET方法提交表单是,提交的内容在URL中,一开始就已经按照编码分析所有的提交内容,setCharacterEncoding()自然就无效。

对于response,则是指定输出内容的编码,同时,该设置会传递给浏览器,告诉浏览器输出内容所采用的编码。

处理过程

下面分析两个有代表性的例子,说明java对编码有关问题的处理方法。

4.1. 表单输入

User input (gbk:d6d0 cec4) browser (gbk:d6d0 cec4) web server iso8859-1(00d6 00d 000ce 00c4) class,需要在class中进行处理:getbytes(”iso8859-1”)为d6 d0 ce c4,new String(”gbk”)为d6d0 cec4,内存中以unicode编码则为4e2d 6587.

l 用户输入的编码方式和页面指定的编码有关,也和用户的操作系统有关,所以是不确定的,上例以gbk为例。

l 从browser到web server,可以在表单中指定提交内容时使用的字符集,否则会使用页面指定的编码。而如果在url中直接用?的方式输入参数,则其编码往往是操作系统本身的编码,因为这时和页面无关。上述仍旧以gbk编码为例。

l Web server接收到的是字节流,默认时(getParameter)会以iso8859-1编码处理之,结果是不正确的,所以需要进行处理。但如果预先设置了编码(通过request. setCharacterEncoding ()),则能够直接获取到正确的结果。

l 在页面中指定编码是个好习惯,否则可能失去控制,无法指定正确的编码。

4.2. 文件编译

假设文件是gbk编码保存的,而编译有两种编码选择:gbk或者iso8859-1,前者是中文windows的默认编码,后者是linux的默认编码,当然也可以在编译时指定编码。

Jsp (gbk:d6d0 cec4) java file (gbk:d6d0 cec4) compiler read uincode(gbk: 4e2d 6587; iso8859-1: 00d6 00d 000ce 00c4) compiler write utf(gbk: e4b8ad e69687; iso8859-1: *) compiled file unicode(gbk: 4e2d 6587; iso8859-1: 00d6 00d 000ce 00c4) class.所以用gbk编码保存,而用iso8859-1编译的结果是不正确的。

class unicode(4e2d 6587) system.out / jsp.out gbk(d6d0 cec4) os console / browser.

l 文件可以以多种编码方式保存,中文windows下,默认为ansi/gbk.

l 编译器读取文件时,需要得到文件的编码,如果未指定,则使用系统默认编码。一般class文件,是以系统默认编码保存的,所以编译不会出问题,但对于jsp文件,如果在中文windows下编辑保存,而部署在英文linux下运行/编译,则会出现问题。所以需要在jsp文件中用pageEncoding指定编码。

l Java编译的时候会转换成统一的unicode编码处理,最后保存的时候再转换为utf编码。

l 当系统输出字符的时候,会按指定编码输出,对于中文windows下,System.out将使用gbk编码,而对于response(浏览器),则使用jsp文件头指定的contentType,或者可以直接为response指定编码。同时,会告诉browser网页的编码。如果未指定,则会使用iso8859-1编码。对于中文,应该为browser指定输出字符串的编码。

l browser显示网页的时候,首先使用response中指定的编码(jsp文件头指定的contentType最终也反映在response上),如果未指定,则会使用网页中meta项指定中的contentType.

几处设置

对于web应用程序,和编码有关的设置或者函数如下。

5.1. jsp编译

指定文件的存储编码,很明显,该设置应该置于文件的开头。例如:。另外,对于一般class文件,可以在编译的时候指定编码。

5.2. jsp输出

指定文件输出到browser是使用的编码,该设置也应该置于文件的开头。例如:。该设置和response.setCharacterEncoding(”GBK”)等效。

5.3. meta设置

指定网页使用的编码,该设置对静态网页尤其有作用。因为静态网页无法采用jsp的设置,而且也无法执行response.setCharacterEncoding()。例如:

如果同时采用了jsp输出和meta设置两种编码指定方式,则jsp指定的优先。因为jsp指定的直接体现在response中。

需要注意的是,apache有一个设置可以给无编码指定的网页指定编码,该指定等同于jsp的编码指定方式,所以会覆盖静态网页中的meta指定。所以有人建议关闭该设置。

5.4. form设置

当浏览器提交表单的时候,可以指定相应的编码。例如:。一般不必不使用该设置,浏览器会直接使用网页的编码。

首先介绍两种字符集 gb2312 和 gbk
gb2312 简体中文编码
gbk 中文字符编码 包括繁体中文

指定jsp文件里内容的的编码方式

@ page language=”java” import=”java.util.*” pageEncoding=”gb2312”

指定html文件里内容的编码方式
当响应用户的请求时,输出到用户浏览器上的编码方式

<%@ page contentType=”text/html”; charset=”gb2312”%>
相当于生成的代码 response.setContentType(“text/html; charset=gb2312”);

把用户传递过来的参数作为指定的编码
request.setCharacterEncoding(“gb2312”);

对比
request.setCharacterEncoding(“gb2312”); //设置输入编码格式
response.setContentType(“text/html; charset=gb2312”); //设置输出编码格式

©️2020 CSDN 皮肤主题: 精致技术 设计师:CSDN官方博客 返回首页