java字符编码转换过程(转)

在Java中,String的getBytes()方法是得到一个操作系统默认的编码格式的字节数组。这个表示在不通OS下,返回的东西不一样!

String.getBytes(String decode)方法会根据指定的decode编码返回某字符串在该编码下的byte数组表示,如

byte[] b_gbk = "中".getBytes("GBK"); 
byte[] b_utf8 = "中".getBytes("UTF-8"); 
byte[] b_iso88591 = "中".getBytes("ISO8859-1");

将分别返回“中”这个汉字在GBK、UTF-8和ISO8859-1编码下的byte数组表示,此时b_gbk的长度为2,b_utf8的长度为3,b_iso88591的长度为1。

而与getBytes相对的,可以通过new String(byte[], decode)的方式来还原这个“中”字时,这个new String(byte[], decode)实际是使用decode指定的编码来将byte[]解析成字符串。

String s_gbk = new String(b_gbk,"GBK"); 
String s_utf8 = new String(b_utf8,"UTF-8"); 
String s_iso88591 = new String(b_iso88591,"ISO8859-1");

通过打印s_gbk、s_utf8和s_iso88591,会发现,s_gbk和s_utf8都是“中”,而只有s_iso88591是一个不认识的字符,为什么使用ISO8859-1编码再组合之后,无法还原“中”字呢,其实原因很简单,因为ISO8859-1编码的编码表中,根本就没有包含汉字字符,当然也就无法通过"中".getBytes("ISO8859-1");来得到正确的“中”字在ISO8859-1中的编码值了,所以再通过new String()来还原就无从谈起了。

因此,通过String.getBytes(String decode)方法来得到byte[]时,一定要确定decode的编码表中确实存在String表示的码值,这样得到的byte[]数组才能正确被还原。

有时候,为了让中文字符适应某些特殊要求(如http header头要求其内容必须为iso8859-1编码),可能会通过将中文字符按照字节方式来编码的情况,如

String s_iso88591 = new String("中".getBytes("UTF-8"),"ISO8859-1"),

这样得到的s_iso8859-1字符串实际是三个在 ISO8859-1中的字符,在将这些字符传递到目的地后,

目的地程序再通过相反的方式String s_utf8 = new String(s_iso88591.getBytes("ISO8859-1"),"UTF-8")来得到正确的中文汉字“中”。这样就既保证了遵守协议规定、也支持中文。

===================================================

JAVA编码转换的详细过程

我们常见的JAVA程序包括以下类别: 
       *直接在console上运行的类(包括可视化界面的类) 
       *JSP代码类(注:JSP是Servlets类的变型) 
       *Servelets类 
       *EJB类 
       *其它不可以直接运行的支持类 
这些类文件中,都有可能含有中文字符串,并且我们常用前三类JAVA程序和用户直接交互,用于输出和输入字符,如:我们在JSP和Servlet中得到客户端送来的字符,这些字符也包括中文字符。无论这些JAVA类的作用如何,这些JAVA程序的生命周期都是这样的: 
*编程人员在一定的操作系统上选择一个合适的编辑软件来实现源程序代码并以.java扩展名保存在操作系统中,例如我们在中文win2k中用记事本编辑一个java源程序; 
       *编程人员用JDK中的javac.exe来编译这些源代码,形成.class类(JSP文件是由容器调用JDK来编译的); 
       *直接运行这些类或将这些类布署到WEB容器中去运行,并输出结果。 
      那么,在这些过程中,JDK和JVM是如何将这些文件如何编码和解码并运行的呢? 
      这里,我们以中文win2k操作系统为例说明JAVA类是如何来编码和被解码的。 
第一步,我们在中文win2k中用编辑软件如记事本编写一个Java源程序文件(包括以上五类JAVA程序),程序文件在保存时默认采用了操作系统默认支持GBK编码格式(操作系统默认支持的格式为file.encoding格式)形成了一个.java文件,也即,java程序在被编译前,我们的JAVA源程序文件是采用操作系统默认支持的file.encoding编码格式保存的,java源程序中含有中文信息字符和英文程序代码;要查看系统的file.encoding参数,可以用以下代码: 
public class ShowSystemDefaultEncoding { 
public static void main(String[] args) { 
String encoding = System.getProperty("file.encoding"); 
System.out.println(encoding); 
}} 
第二步,我们用JDK的javac.exe文件编译我们的Java源程序,由于JDK是国际版的,在编译的时候,如果我们没有用-encoding参数指定我们的JAVA源程序的编码格式,则javac.exe首先获得我们操作系统默认采用的编码格式,也即在编译java程序时,若我们不指定源程序文件的编码格式,JDK首先获得操作系统的file.encoding参数(它保存的就是操作系统默认的编码格式,如WIN2k,它的值为GBK),然后JDK就把我们的java源程序从file.encoding编码格式转化为JAVA内部默认的UNICODE格式放入内存中。然后,javac把转换后的unicode格式的文件进行编译成.class类文件,此时.class文件是UNICODE编码的,它暂放在内存中,紧接着,JDK将此以UNICODE编码的编译后的class文件保存到我们的操作系统中形成我们见到的.class文件。对我们来说,我们最终获得的.class文件是内容以UNICODE编码格式保存的类文件,它内部包含我们源程序中的中文字符串,只不过此时它己经由file.encoding格式转化为UNICODE格式了。这一步中,对于JSP源程序文件是不同的,对于JSP,这个过程是这样的:即WEB容器调用JSP编译器,JSP编译器先查看JSP文件中是否设置有文件编码格式,如果JSP文件中没有设置JSP文件的编码格式,则JSP编译器调用JDK先把JSP文件用JVM默认的字符编码格式(也即WEB容器所在的操作系统的默认的file.encoding)转化为临时的Servlet类,然后再把它编译成UNICODE格式的class类,并保存在临时文件夹中。如:在中文win2k上,WEB容器就把JSP文件从GBK编码格式转化为UNICODE格式,然后编译成临时保存的Servlet类,以响应用户的请求。 
      第三步,运行第二步编译出来的类,分为三种情况: 
      A、 直接在console上运行的类 
      B、 EJB类和不可以直接运行的支持类(如JavaBean类) 
      C、 JSP代码和Servlet类 
      D、 JAVA程序和数据库之间 
下面我们分这四种情况来看。 
A、直接在console上运行的类 
这种情况,运行该类首先需要JVM支持,即操作系统中必须安装有JRE。运行过程是这样的:首先java启动JVM,此时JVM读出操作系统中保存的class文件并把内容读入内存中,此时内存中为UNICODE格式的class类,然后JVM运行它,如果此时此类需要接收用户输入,则类会默认用file.encoding编码格式对用户输入的串进行编码并转化为unicode保存入内存(用户可以设置输入流的编码格式)。程序运行后,产生的字符串(UNICODE编码的)再回交给JVM,最后JRE把此字符串再转化为file.encoding格式(用户可以设置输出流的编码格式)传递给操作系统显示接口并输出到界面上。以上每一步的转化都需要正确的编码格式转化,才能最终不出现乱码现象。 
B、EJB类和不可以直接运行的支持类(如JavaBean类) 
由于EJB类和不可以直接运行的支持类,它们一般不与用户直接交互输入和输出,它们常常与其它的类进行交互输入和输出,所以它们在第二步被编译后,就形成了内容是UNICODE编码的类保存在操作系统中了,以后只要它与其它的类之间的交互在参数传递过程中没有丢失,则它就会正确的运行。 
C、JSP代码和Servlet类 
经过第二步后,JSP文件也被转化为Servlets类文件,只不过它不像标准的Servlets一校存在于classes目录中,它存在于WEB容器的临时目录中,故这一步中我们也把它做为Servlets来看。 
对于Servlets,客户端请求它时,WEB容器调用它的JVM来运行Servlet,首先,JVM把Servlet的class类从系统中读出并装入内存中,内存中是以UNICODE编码的Servlet类的代码,然后JVM在内存中运行该Servlet类,如果Servlet在运行的过程中,需要接受从客户端传来的字符如:表单输入的值和URL中传入的值,此时如果程序中没有设定接受参数时采用的编码格式,则WEB容器会默认采用ISO-8859-1编码格式来接受传入的值并在JVM中转化为UNICODE格式的保存在WEB容器的内存中。Servlet运行后生成输出,输出的字符串是UNICODE格式的,紧接着,容器将Servlet运行产生的UNICODE格式的串(如html语法,用户输出的串等)直接发送到客户端浏览器上并输出给用户,如果此时指定了发送时输出的编码格式,则按指定的编码格式输出到浏览器上,如果没有指定,则默认按ISO-8859-1编码发送到客户的浏览器上。 
D、Java程序和数据库之间 
对于几乎所有数据库的JDBC驱动程序,默认的在JAVA程序和数据库之间传递数据都是以ISO-8859-1为默认编码格式的,所以,我们的程序在向数据库内存储包含中文的数据时,JDBC首先是把程序内部的UNICODE编码格式的数据转化为ISO-8859-1的格式,然后传递到数据库中,在数据库保存数据时,它默认即以ISO-8859-1保存,所以,这是为什么我们常常在数据库中读出的中文数据是乱码。

来源http://jiapumin.iteye.com/blog/1006144

java字符编码转换过程(转)

时间: 2024-09-30 18:21:17

java字符编码转换过程(转)的相关文章

java字符编码详解

引用自:http://blog.csdn.net/jerry_bj/article/details/5714745 GBK.GB2312.iso-8859-1之间的区别 GB2312,由中华人民共和国政府制定的,简体汉字编码规范,大陆所有计算机中的简体中文,都使用此种编码格式.目前,我也不知道还有另外的简体汉字编码规范.与此对应的还有BIG5,是中华民国政府制定的,繁体汉字的编码规范,一般应用于海外计算机的繁体中文显示.所谓的繁体中文Windows,简体中文Windows,指的就是采用BIG5和

【字符编码】Java字符编码详细解答及问题探讨

一.前言 继上一篇写完字节编码内容后,现在分析在Java中各字符编码的问题,并且由这个问题,也引出了一个更有意思的问题,笔者也还没有找到这个问题的答案.也希望各位园友指点指点. 二.Java字符编码 直接上代码进行分析似乎更有感觉.   运行结果:   说明:通过结果我们知道如下信息. 1. 在Java中,中文在用ASCII码表示为3F,实际对应符号'?',用ISO-8859-1表示为3F,实际对应符号也是为'?',这意味着中文已经超出了ASCII和ISO-8859-1的表示范围. 2. UTF

Java 字符编码归纳总结

String newStr = new String(oldStr.getBytes(), "UTF-8");       java中的String类是按照unicode进行编码的,当使用String(byte[] bytes, String encoding)构造字符串时,encoding所指的是bytes中的数据是按照那种方式编码的,而不是最后产生的String是什么编码方式,换句话说,是让系统把bytes中的数据由encoding编码方式转换成unicode编码.如果不指明,by

java字符编码转换

在开发的过程中,字符编码常常令我们头痛.经常会出现各种各样的乱码.下面就介绍java的编码转换和常见的乱码是使用什么样的编码去读取的: 先看一张图片: 在看看java中如何处理编码的转换: package com.test; /** * 字符串编码转换 * @author Herman.xiong * @date 2015年7月16日09:36:59 * @version V3.0 * @since Tomcat6.0,Jdk1.6 * @copyright Copyright (c) 2015

java字符编码

java中的文字是16位整数(2个byte)序列,文件中的数据是8位的byte序列,如何将字符char转为byte -- 编码 字符编码(char encoding):将字符序列拆分为byte序列的拆分方法称为字符的编码 (1)UTF-16BE:将字符切两半,String.getByte("utf-16be"),支持65535个字符,中英文都是两个byte,定长编码,缺点是,英文浪费时间,只能支持unicode 4.0 (2)UTF-8:采用的是变长编码,1-4字节,按照数值从小到大采

Java 字符编码与解码

1.字符编码的发展历程 ①.ASCII 码 因为计算机只认识数字,所以我们在计算机里面的一切数据都是以数字来表示,因为英文字符有限,所以规定使用的字节的最高位是 0,每一个字节都是以 0-127 之间的数字来表示.比如 A 对应 65,a 对应 97.这便是 美国标准信息交换码,ASCII String str = new String("Aa"); byte[] strASCII = str.getBytes("ASCII"); System.out.printl

JAVA字符编码测试

几点注意: 1,ASCII码和ISO-8859-1都是单字节编码,ASCII码能表示128个字符,ISO-8859-1总共能表示256个字符.都不能表示中文,如果中文字符或其它不在IOS-8859码值范围内的字符会统一用3f表示(显示为"?", 通常所说的"黑洞"): 2,GBK兼容GB2312,是双字节编码,GB2312包含6763个汉字,GBK包含21003个汉字: 3,UTF-16为定长双字节编码,大大简化了字符串的操作,但是会浪费存储空间.JAVA以UTF-

Java字符编码的转化问题

概述: 我想字符串的编码问题的确会困扰到非常多开发人员.我近期也是被困扰到了. 问题是这种,我们通过二维码扫描来获得二维码中的信息.可是.我们的二维码的产生过程却是"多样化"的.即在产生二维码的时候是以不同的字符串编码类型进行编码的.比方,GBK.GB2312.UTF-8等等.而这些不同的编码类型会产生不同的字节.在Java中.GBK和GB2312都是1个汉字占2个字节,UTF-8是1个汉字占3个字节.而ISO编码则是1上汉字1个字节.这样一来,我们在扫描二维码的时候就会出现一些&qu

java字符编码,字符转码

编码:String->byte[]; str.getBytes(charsetName) 解码:byte[]->String; new String(byte[],charsetName); package pack; import java.io.UnsupportedEncodingException; import java.lang.reflect.Array; import java.util.Arrays; public class Demo{ /** * 用gbk编码 utf解码