就 没任何意义了,用户需要对数据进行保存,读取,打印,输入等等操作,每一样操作都是存 在“转码”处理的,只是一般我们不会去关心,JRE 已经帮你做好了很多事。 下面进入下一个重点知识,JRE 与操作系统字符编码转换。 Windows 操作系统默认支持的是 GBK,它是一种编码标准。GBK 我没深入研究过,它肯 定是一种编码标准,因为它的编码可以写入文件。但是不是字符集笔者也不曾深入研究。我 们不讨论它的编码原理,只需要知道它是和 UNICODE 不一样的,也就是说同一个字符在它 们之间存放的十六进制数是不一样的。 JRE 运行在 WINDOWS 中。 我们从键盘输入的字符是以 windows 默认的编码标准接收的, 也就是你输入的任何东西先是进入到操作系统又才会进入 JRE。操作系统读取数据的时候内
存中存放的是操作系统的默认支持的编码标准。这种编码格式不是 JRE 默认支持的。所以数 据再进入 JRE 的时候就需要一次转码。 java.nio.charset.Charset.defaultCharset().name()方法可以得到当前操作系统默认使用的 编码标准。JRE 与操作系统之间进行数据通信时,在未特别指定的情况下都以这个编码进行 转化,实际上就是 UNICODE 和这个方法返回的结果的那个编码进行转换。 通常情况下,当 JRE 读取控制台输入的字符时不需要进行编码指定,因为控制台接收数 据后所存放的编码不会被用户更改, 所以 JRE 只要用
系统默认的编码进行转化就可以正确处 理。 (这个过程是:操作系统中存在一个字符串,它是
以 GBK 编码的。而 JRE 需要将它读到 JRE 的内存里头,就需要通过 JRE 里面已经编写好了的 GBK->UNICODE 算法进行转化。String 类中提供了转化的方法,详细请看 java.lang.String 类的多种构造方法) 。 当处理的是文件的时候就复杂一点了, 因为文件中字符串的编码并不肯定是系统默认的 编码。这个时候用户在读取的时候可以指定某一种编码来读取,使用 InputStreamReader 类, 它有设置编码的构造方法。 由于 JRE 封装好了 UNICODE 与系统平台之间的编码转换,所以对于不经常使用编码的 人员来说,编码问题就不重要了。 UTF-8 编码 Java 中经常使用的编码标准莫过于“UTF-8”了。它是编码标准而非单单是字符集,它 也不是 UNICODE。UNICODE 中是以固定长存放字符的,而 UTF-8 是变长的。这其中又有什 么关系呢?其实 UTF-8 和 GBK、GB2312 等等属于同一类,只是一种编码标准而已。它的功 能是将内存中的字符保存到硬盘或者发送到
网络传输线的时候使用的编码。 这里需要注意理 解一点,UNICODE 字符集所用来表示字符的编码是“不能”直接写入硬盘和发送当网络传 输线上去的。 也就是说 “6c49” 这个 4 个十六进制字符所代表的字符是 “汉” 但如果将 , “汉” 这个字写入到文件, 无论以哪种编码格式写入, 在文件里保存的二进制编码中绝对不是 6c49 所表示的二进制编码。 (以上为个人理解和测试的结果) 。 内存中的 “汉” 这个字, 所占用的两个字节里面存放的是 “6c” “49” 如果要以 UTF-8 和 。 格式写入到文件中,它的字节数组将是什么呢?下面通过测试得到这个字节数组的值。(具 体这些编码标准什么编码的不是本文讨论的
问题, 因为它怎么编其实并不直接影响乱码的出 现,而是编码之间的转化才导致了乱码)。 String str = "汉" ; byte [] str_utf8_bytes = str.getBytes("UTF-8");
得到的 str_utf8_bytes 则是“汉”这个字用 UTF-8 编码时的字节数组。它的值经过测试 得到结果是{-26,-79,-119}。也就是说,当“汉”这个字以 UTF-8 编码标准写入文件时,它占 用了三个 byte 的大小,分别是-26,-79,-119。通过这三个数字组成一个字节数组,是可以还 原得到一个汉字“汉”的。代码如下: byte[] bytes_utf8 = new byte[]{-26,-79,-119}; //创建字节数组 String str = n