中文编码问题

   在编程中字符编码绝对是个值得重视的问题,当读取一个文件或是得到一个输入流,你需要分析数据的编码方式、形态,以便能正确的处理、显示数据所表示的字符。

[细节]
      1)  在简体中文操作系统中,从键盘输入的原始字符采用的是GBK编码方式,对应到其他操作系统,采用的应是系统默认的本地字符集。而在程序设计语言中,字符和字符串则通常是使用Unicode编码方式,这一点可以用下列代码说明(使用Java语言描述)。

      int ch = System.in.read(); //从键盘输入中读取一个字节的数据
      如果输入“中国”两个字符,使用上面的代码将所有的数据读取,将得到“D6 D0 B9 FA”,这写数据正是“中国”两个字符的GBK编码值。
      String tmp = "中国"; //定义字符串并赋值
      for(int i=0;i<tmp.length();i++)
      {
      //将字符串中的每个字符编码值以十六进制形式显示
         System.out.println(Integer.toHexString(ch));
      }

      上面代码最后显示的内容是“4E2D 56FD”,而这正是“中国”两个字符的Unicode编码值。
 
      2) 不仅是输入的原始字符采用GBK编码,屏幕输出的最终数据也要采用GBK编码,下面的代码能说明问题。

      String tmp = "中国"; //定义字符串并赋值
      System.out.println(tmp); //将字符串tmp输出到显示屏

      代码运行后,在显示屏上显然能看到“中国”两个字符,而字符串tmp分明是采用Unicode进行编码的,是不是刚才提出的命题站不住脚呢?其实,在调用println()方法后,该方法自动的将字符串tmp的编码方式从Unicode转换成了本地编码GBK,这样才能在屏幕上正常的显示中文。如果你仍然怀疑,请继续往下看。

      byte [] buf1 = tmp.getBytes("Unicode"); //将字符串tmp以Unicode编码方式储存在字节数组中
      byte [] buf2 = tmp.getBytes("GB2312"); //将字符串tmp以UGBK编码方式储存在字节数组中
      //在屏幕输出流中直接写字节数组
      System.out.write(buf1);
      System.out.write(buf2);

      这样的作法将会得到什么结果呢?结果也许会令你感到惊讶,buf1的数据输出后显示为乱码,而buf2的数据输出后赫然显示为“中国”两个字符。可以把命题说得明确点:如果要在屏幕上输出汉字,那么字符的最终编码方式必须是GBK编码方式。对于数字和英文字母,以及ASCII编码集中包含的符号,字符的最终编码方式可以是ASCII,这种情况下如果使用Unicode编码,那么显示的结果会是这样“1 2 3 a b c ”,本来想显示的内容是“123abc”。显示结果字符间多了个貌似空格的字符,这是因为ASCII编码使用一个字节,Unicode编码使用两个字节,在ASCII编码转换为Unicode时候,只是单纯地在编码值前面补充一个全为0的字节,这个字节在最终显示的时候被看做是空字符NUL。
 
      3) 在涉及网页、网络流和关系数据库方面编程的时候,字符编码总喜欢戏弄编程人员,不花心思去驯服它的结果将是得到一堆乱码。例如在读取数据数据时候,数据库中的内容是中文字符,如果数据库没有考虑到中文支持问题就很容易得到乱码。再例如程序运行的平台默认编码并非GBK,在获取GBK编码的字符数据时候,程序会将数据看作默认编码,这样也容易产生乱码。在上述情况中编写程序的时候,就应该耐心的分析数据的编码方式,合理的编写代码防止乱码。
 
[例子]   
      记得在《Java手机程序设计入门与应用》(王森 编著)一书的第13章-MIDP网络程序设计中有一段使用HTTP进行网络连接的实例代码,部分代码如下所示。

      String url = " http://127.0.0.1/test.html ";
      HttpConnection hc = (HttpConnection)Connector.open(url);
      DataInputStream dis = new DataInputStream(hc.openInputStream());
      String content = "";
      int ic;
      while((ic = dis.read()) != -1)
      {
          content += (char)ic;
      }
      Form f = new Form("HTTP Test");
      f.append(content);
      Display.getDisplay(this).setCurrent(f);

      这段代码让手机通过HTTP协议与网络中的主机进行通信,然后获得网络主机上的文件test.html并将文件内容读取到字符串变量中,最后显示到程序窗体中。如果程序这般执行的话,你会发现MIDlet显示出来中文都是乱码。作者称“之所以会有这种结果,原因在于我们的仿真器支持Unicode的缘故。”,作者的意思似乎是MIDlet将本地编码的字符数据误认为了Unicode编码的数据,因此不能正常显示,然后推荐了一种解决方法:使用ASCII形态的Unicode。
      所谓ASCII形态的Unicode指的是使用ASCII编码的字符来表示Unicode编码值,反过来说就是将Unicode的编码值看做字符,再用ASCII对这些字符进行编码存放。比如“中国”这两个字符的ASCII形态的Unicode编码字符为“\u4e2d\u56fd”,0x4E2D 0x56FD 分别为“中”和“国”的Unicode编码值,将编码值作为字符,然后在前面添加“\u”标识符,以便进行还原。再对这些字符进行ASCII编码就得到了ASCII形态的Unicode编码值,最终的值为“5C 75 34 65 32 64 5C 75 35 36 66 64”,一共12个字节的数据,分别对应了“\u4e2d\u56fd”中的一个字符。使用jdk*\bin文件夹下的native2ascii.exe程序可以很方便的将一个文件转换为ASCII形态的Unicode编码。将文件test.html转换形态后,MIDlet中需要再次将ASCII形态的Unicode转换为Unicode编码,这个转换方法需要自己写,最后MIDlet中显示出来的就是正常的中文字符。

      在我看来,那本书的作者没有把握住问题的真正原因,也或许是我们使用的模拟器和平台不同。如果把握住真正的原因,问题的解决方法就变得很简单了。前面说过,要在屏幕上显示出中文,字符的最终编码形式必须是GBK,在中国大陆发现的手机都能显示中文,也就说明手机中都支持GBK编码。那为什么会出现中文字符乱码的问题呢?我的理由是手机中采用的默认编码是ISO8859-1,对于从网络中读入的字符数据,在没有指明的情况下,MIDlet一律将它们看作是ISO8859-1编码的数据。而test.html的编码方式是GBK,MIDlet犯了个错误,它将GBK编码的数据误认为了ISO8859-1编码的数据,然后在显示的时候又进行了一次ISO8859-1到GBK的编码转换,这样的结果是数据遭到了破坏,显示出来的中文也就变成了乱码。
      把握住了原因,解决起来就十分方便了。既然MIDlet将GBK编码的数据误认为ISO8859-1编码的数据,那么我们只要在程序中指明数据的编码方式就可以了,而不用使用“ASCII形态的Unicode”这样的舍本求末的方法。下面是解决MIDlet网络连接中文乱码问题的代码,这些代码将证明我的观点。

      http://127.0.0.1/test.html;
      HttpConnection hc = (HttpConnection)Connector.open(url);
      byte [] buf = new byte[1024];
      int len = hc.openInputStream().read(buf);  //读取网络数据
      String content = new String(buf,0,len,"GB2312");  //指定数据为GBK编码
      Form f = new Form("HTTP Test");
      f.append(content); 
      display.setCurrent(f);

      上述代码中关键的一句是:
      String content = new String(buf,0,len,"GB2312");
      这句代码告诉MIDlet从网络中读取的数据使用的是GBK编码方式,然后MIDlet便能争取处理和显示这些数据。
      如果将这句代码改写为: 
      String content = new String(buf,0,len);
      或者是:
      String content = new String(buf,0,len,"ISO8859-1");
      都将出现同样的中文乱码现象,由此断定错误的原因是手机默认编码使用ISO8859-1,MIDlet将从网络中读取的GBK编码的数据误认成了ISO8859-1编码的数据。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值