一个关于Unicode字符编码的奇怪问题

系统 1888 0

有一个学员问了一个关于 Unicode 字符编码的奇怪问题。

问题如下:

String strChina = " 中国 ";

1 )直接把每个字符中的内容对应着的整数打印出来,显示的结果就是这个字符的 Unicode 码,则下面的代码:

for(int i=0; i<strChina.length(); i++)

{

System.out.println(Integer.toHexString((int)strChina.charAt(i)));

}

打印出的结果是:

4e2d

56fd

2 )下面的代码:

byte [] buf = strChina.getBytes("Unicode");

for(int i=0; i<buf.length; i++)

{

System.out.println(Integer.toHexString(buf[i]));

}

打印出的结果是:

ffffffff

fffffffe

2d

4e

fffffffd

56

打印出的“ ffffffff ”和“ fffffffe ”表示什么?“ 2d ”和“ 4e ”为什么和直接打印的结果是相反的?

回答如下:

在不同体系结构的计算机系统中, UTF-16 编码的 Unicode 字符在内存中的字节存储顺序是不同的。使用 Intel CPU 的计算机中,一个多字节数据在内存中的存储形式通常是:低字节在前,高字节在后,这种方式称为 Little-Endian (最不重要的字节在先)。但是,在使用其他 CPU 的一些计算机中,又是以高字节在前,低字节在后的方式存储多字节数据的,这种方式称为 Big-Endian (最重要的字节在先)。对于 0x1234 这样一个双字节数据,使用 Little-Endian Big-Endian 两种方式在内存中存储的格式如图 7.4 所示。

一个关于Unicode字符编码的奇怪问题

<shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></path><lock v:ext="edit" aspectratio="t"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 285.75pt; HEIGHT: 164.25pt" type="#_x0000_t75"><imagedata src="file:///C:%5CDOCUME~1%5Cflx%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.png" o:title=""></imagedata></shape>

对于采用 UTF-16 编码的文件,通常都要用字节顺序标记( Byte Order Mark ,简称 BOM )来说明文件中的字符所使用的字节存储顺序。如果文件以 0xFE 0xFF 这两个字节开头,则表明文本的其余部分是 Big-Endian UTF-16 编码;如果文件以 0xFF 0xFE 这两个字节开头,则表明文本的其余部分是 Little-Endian UTF-16 编码;如果文件开头没有使用任何字节顺序标记,则暗指全部文本都是 Big-Endian UTF-16 编码。

ffffffff ”和“ fffffffe ”实际上是 0xff 0xfe 的两个字节,把他们当作整数打印时,就成了 4 个字节, 由于 0xfe 最高 bi t 位是 1 ,当它转成 4 字节的整数时,前面 3 个字节的所有 bit 位都补 1, 结果就成了 0xfffffffe 。前面打印出:

ffffffff

fffffffe

2d

4e

fffffffd

56

实际上是:

ff

fe

2d

4e

fd

56

前两个字节是在说字节存储顺序!

一个关于Unicode字符编码的奇怪问题


更多文章、技术交流、商务合作、联系博主

微信扫码或搜索:z360901061

微信扫一扫加我为好友

QQ号联系: 360901061

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描下面二维码支持博主2元、5元、10元、20元等您想捐的金额吧,狠狠点击下面给点支持吧,站长非常感激您!手机微信长按不能支付解决办法:请将微信支付二维码保存到相册,切换到微信,然后点击微信右上角扫一扫功能,选择支付二维码完成支付。

【本文对您有帮助就好】

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描上面二维码支持博主2元、5元、10元、自定义金额等您想捐的金额吧,站长会非常 感谢您的哦!!!

发表我的评论
最新评论 总共0条评论