| | | | | | | [文章信息] | | | 作者: | PETERY | | 时间: | 2003-08-23 | | 出处: | 论坛 | | 责任编辑: | 方舟 | |
| [文章导读] | | | 利用手机与别人沟通成了我们生活的一部份...... | |
| |
|
| | | |
|
|
|
|
|
Motorola J2ME SDK对中文的支持
相信看过RUN!PC 11月号的文章「利用Java 编写PalmOS应用程序基础篇」的读者，在编写PalmOS上的Spotlet时一定会遇到中文无法正常显示的问题。中文的问题分成两个部分，一个是在用户接口上的中文问题，一个是在命令列输出(利用System.out.println()函式所做的输出)上的中文问题，请大家做个小实验，将前面我们所编写的程序改如下:
HelloMIDlet.java
import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
public class HelloMIDlet extends MIDlet
{
private Display firstDisplay ;
private Form firstForm ;
HelloMIDlet()
{
firstDisplay = Display.getDisplay(this) ;
firstForm = new Form("哈罗!MIDlet") ;
StringItem firstStrItem = new StringItem("哈罗","米德列特") ;
firstForm.append(firstStrItem) ;
System.out.println("MIDlet启动") ;
}
protected void startApp() throws MIDletStateChangeException
{
firstDisplay.setCurrent(firstForm) ;
}
protected void pauseApp()
{
}
protected void destroyApp(boolean unconditional)
throws MIDletStateChangeException
{
}
}
将本MIDlet编译并经过预身审核之后，我们开启模拟器来执行此MIDlet，底下为执行结果:
| 用户接口输出: |
命令列输出 |
  |
|
我们从结果发现，预设的编译指令会让用户接口正常输出中文，而命令列无法输出正确的中文。
|
接着请将compileAll.bat之中原本的指令
javac -O -bootclasspath ..\..\lib %COMPILECLASS%
修改为
javac –encoding ISO8859_1 -O -bootclasspath ..\..\lib %COMPILECLASS%
之后，重新编译此MIDlet执行结果:
| 用户接口输出: |
命令列输出 |
  |
|
| 我们从结果发现，预设的编译指令会让用户接口无法正常输出中文，而命令列却可以输出正确的中文。 |
这个结果与PalmOS上所做的中文测试结果有所不同。
当您编写Spotlet时，如果您使用javac 。。。指令时，您会发现模拟器上的用户接口输出是乱码，可是命令列上的输出却可以正常输出中文。但是如果您使用的是javac -encoding ISO8859_1 。。。指令，则CLDC内附模拟器上的用户接口输出或是命令列上的输出全部都变成乱码，无法正常输出中文(这个部分是因为CLDC内附模拟器实做的问题，造成与实际机器的结果有差异)。
总之，如果之前您所编写的Spotlet无法在装有中文系统的实际机器或POSE上正常输出中文，请您也如法炮制，在编译指令中加入-encoding ISO8859_1，就可以在实际机器或POSE上看到正常的中文字了。
会产生此问题的主因，主要是因为编译好的Java类文件(byte code)之中，所有的文字编码都采用UTF8。举例来说，当您在程序码里用到"启动"这两个中文字时，
"起"这个字的Big5编码为B1D2。
"动"这个字的Big5编码为B0CA。
我们会使用javac xxxx.java来编译原始码以产生类文件。其实这行指令，在繁体中文的Windows环境底下，相当于javac -encoding "Big5" xxxx.java。也就是说，当编译器读取到Big5编码范围的中文字时，会自动将此Big5码经过「Big5è Unicode 对照表」将Big5转为Unicode，也就是说,经过查表之后，
“起”这个字的Unicode编码为555F。
“动”这个字的Unicode编码为5272。
然后再利用UTF8编码将此Unicode转为UTF8，储存在类文件之中，因此，如果您用UltraEdit之类的文字编辑器查看类文件时，您会看到，
"起"这个字的UTF8编码为E5959F。
"动"这个字的UTF8编码为E58B95。
接着，当我们在程序执行时如果要将中文输出，则JVM会负责读进UTF8码，然后将其转回Unicode，最后依据您所使用的系统环境预设的编码转回Big5，再输出至屏幕上。
可是经过测试结果，KVM似乎只有做到把UTF8读进来，转换回Unicode之后就直接输出了。少了转回Big5的步骤，因此，操作系统把Unicode当作Big5来处理，自然就找不到该码所对应的中文字了，也因此输出的是一堆 ????? 的符号。这也是我们在PalmOS上即使装了中文系统，也无法正常显示中文的缘故。
OK，既然知道KVM只帮我们做了一半的工作，那事情就好办了，我们只要让UTF8转回之后，仍然保有Big5的编码方式即可，于是我们使用指令javac -encoding ISO8859_1 xxxx.java，请编译器不要将程序码中中文Big5编码的两个byte视为一体(因为视为一体就会引发查询Big5 è Unicode对照表的工作)，只要将中文当作是普通的西欧字母字集即可，因此，当我们使用了上述指令，您会发现类文件之中的中文变成，
"起"这个字的UTF8编码为C2B1 C392。
"动"这个字的UTF8编码为C2B0 C38A。
大家可以发现编译器把B1、D2、B0、CA个别当作一个码来处理。于是，当KVM读到此编码时，就会将他们转回B1D2以及B0CA，然后KVM直接输出，就可以正常地使用中文了。
最后总结整个问题，就笔者的推断，CLDC内附的模拟器再没有使用javac –encoding ISO8859_1 xxxx.java指令之前，会在用户接口使命令列输出乱码，这才是正常的结果， 而Motorola J2ME SDK内附模拟器的用户接口中文之所以没问题，很可能只是因为模拟器操作的差异。因此根据KVM的输出结果来看，很可能在实际的手机上，我们都必须加上-encoding ISO8859_1选项才能正确输出中文吧!
在此特别感谢静宜大学资管系的唐恺隆(kailung.tang@msa.hinet.net)同学。因为笔者于他经过热烈的讨论之后，我们才能对J2ME的中文问题有更深入的认识
|
|
|
|
|
|
|
|
