Java 的 i18n 问题,即 Java 的 Internationalization 问题,指的是如何使应用程序能够同时支持多种语言的问题。对我国这样的非英语国家而汉字又有多种编码方式的情况下具有现实意义。本文将对用 java 编制 i18n 程序的方法作一介绍。
一、实现目标
作为 i18n 程序,不单是能够识别不同编码这么简单。它应能解决如下问题:
*能识别不同的编码方式,如 GB 码、BIG5 码等;
*与编码有关的元素,如状态行、消息、按钮的 caption 等应在程序之外存储。使新增一种语言时不用修改程序;
*根据不同的语言习惯动态调整与语言相关的元素,如数字、金额、日期等的显示。
二、解决方法
1.不同地区码的识别
Java 中用 Locale 类识别不同的地区码。创建 Locale 类的实例时指定了语言代码和地区代码。创建GB 中文和 BIG5 中文资源的 Locale 类实例的语句分别如下:
zhLocale=new Locale(zh,CN);
twLocale=new Locale(tw,TW)。
此构造函数第一个参数是 ISO -639 中定义的语言代码;第二个参数为 ISO -3166 中定义的国家代码。
用户选定了适用的语言后,应将此 Locale 设为默认值:Locale.setDefault(new Locale(zh,CN)).
2. 与语言相关的资源单独存放
Java 提供了两种方法存放与语言相关的资源。一种是用文本文件;另一种是用 ListResourceBundle 资源类。下面分别阐述两者的不同之处。
*文本文件
使用文本文件存放资源的好处是简单易用。可以用任何文本编辑器编写此文件,而且当修改资源时无须重新编译程序。其格式是 ′ 键= 值′ 的列表。例子如下:
#The list in WebTaxResource_zh_CN.properties
button1= 税金
button2= 税率
status1= 初始化中
其中以′ #′ 开头的行为注释行。对应每一种语言写一个这样的资源文件,但所有的资源文件都必须包含相同的键。
*ListResourceBundle 资源类
虽然用文本文件存储资源非常容易,但它只能存储字符对象。而对于数字、自定义对象等它就无能为力了。因此 Java 提供了 ListResourceBundle 类。其缺点是每次对资源的修改都必须重新编译程序。此类的结构如下:
//file WebTaxResource_zh_CN.java
import java.util. *;
public class WebTaxResource_zh_CN extends
ListResourceBundle {
static final Object[][] contents = {
{frametitle, 工资、薪金所得适用},
{label_qizhengdian, 起征点:},
{label_shuikuan, 税款:},
{label_shourue, 收入额:},
{checkbox_qiushouru, 求收入},
{checkbox_qiushuie, 求税额},
{lable1, 简易税金计算器},
{button1, 工资、薪金个人所得税计算},
{button_caculate, 计算},
};
public Object[][] getContents() {
return contents;
}
}
其中两维的 Object 数组存放的是键-值对。每对中的第一个元素是键。在各个资源类中所有键的数量和标识都必须完全一致。
3. 资源的获取
不同语言的资源存放的文件名都不相同,那如何从正确的文件取得我们需要的资源呢?留意到前面例子中properties 文件名和 ListResourceBundle 类名中下划线后的部分吗?没错,它们就是在创建 Locale 实例时指定的语言代码和地区代码!剩下的问题就是要解决下划线前面的基本类名部分了。它是由一个ResourceBundle 类的实例来指定的:
ResourceBundle
bundle=ResourceBundle.getBundle(WebTax ?
Resource,currentLocale);
getBundle 的第一个参数指定了资源文件和资源类的基本类名;第二个参数是你所创建的 Locale 的实例,指定了当前程序所有资源默认的语言代码和地区代码。
可见,资源文件名或类名是由 基本类名_ 语言代码_ 地区代码 组成的。Java 将先查找有无此名称的类,若没有则查找具有此名称的 properties 文件。
匹配了正确的资源文件名或类名后,要获取某键对应的值就变得相当容易。例如,要创建标识为 计算器 的标签,只要调用以下语句:
label1=new Label(bundle.getString(label_ jisuanqi), Label.CENTER);
getString 方法的参数是资源文件中的键名。除了 getString 外,ResourceBundle 类还提供了其他方法获取不同的对象,如 getStringArray、getObject 等(因为在 ListResourceBundle 的实例中允许存在非字符对象)。
4. 转换非 Unicode 资源
在 Java 内部字符是用 Unicode 字符表示的。Unicode 是一种 16bit 的编码,支持大多数地区的语言。具体标准可到 http://www.unicode.org/index.html 查询。因此,无论是用文本文件还是用资源类的方式存储资源,都应该将非 Unicode 字符转换为Unicode 字符。Java 为我们提供了转换的工具-Native2ascii。将含有GB 编码的汉字的 WebTaxResource_zh.CN.properties 文件转换为只含 Unicode 字符的例子如下:
native2ascii -encoding GB2321 WebTaxRe
source_zh_CN.properties
.outputWebTaxResource_zh_CN.properties
到此为止,一个支持 i18n 的程序就已初步完成了。
三、其他相关问题
正如实现目标中所讲到,支持 i18n 的程序不但要识别不同的编码方式,还要根据不同的语言习惯动态调整与语言相关的元素,如数字、金额、日期等的显示。
例如在法文中数值 123456.78 表示为123 456,78;而在德文中应表示为 123.456,78。除了数值和货币之外,不同语言有不同表示的元素还有日期、时间和文本消息。Java 提供了 NumberFormat、DateFormat、MessageFormat 类根据不同的Locale 实例动态改变这些元素的显示模式。下面的例子将根据不同的 Locale 实例改变数值 123456.78 的显示方式。
Double amount = new Double (123456.78);
NumberFormat numberFormatter;
String amountOut;
numberFormatter = NumberFormatgetNumber ?
Instance(currentLocale);
amountOut = numberFormatter.format
(amount);
System.out.println(amountOut + +
currentLocale.toString());
当然,实现 Java 程序的 i18n 还有很多问题要考虑,如不同语言的语法问题等。但在 Java 中,遇到问题多看看联机文档或其他相关的资料,一般都能得到满意的答案。
如果应用系统是面向多种语言的,编程时就不得不设法解决国际化问题,包括操作界面的风格问题、提示和帮助语言的版本问题、界面定制个性化问题等。 |
由于Java语言具有平台无关、可移植性好等优点,并且提供了强大的类库,所以Java语言可以辅助我们解决上述问题。Java语言本身采用双字节字符编码,采用大汉字字符集,这就为解决国际化问题提供了很多方便。从设计角度来说,只要把程序中与语言和文化有关的部分分离出来,加上特殊处理,就可以部分解决国际化问题。在界面风格的定制方面,我们把可以参数化的元素,如字体、颜色等,存储在数据库里,以便为用户提供友好的界面;如果某些部分包含无法参数化的元素,那么我们可能不得不分别设计,通过有针对性的编码来解决具体问题。 |
在用Java解决国际化问题的过程中,可能利用到的主要的类都是由java.util包提供的。该类包中相关的类有Locale、ResourceBundle、ListResourceBundle、PropertyResourceBundle等,其继承关系如下图所示。 |
Locale:该类包含对主要地理区域的地域化特征的封装。其特定对象表示某一特定的地理、政治或文化区域。通过设定Locale,我们可以为特定的国家或地区提供符合当地文化习惯的字体、符号、图标和表达格式。例如,我们可以通过获得特定Locale下的Calendar类的实例,显示符合特定表达格式的日期。 |
ResourceBundle:该类是一个抽象类,需要通过静态方法ResourceBundle.getBundle()指定具体实现类或属性文件的基本名称。基本名称会协同指定的或默认的Locale类,决定具体调用的类或属性文件的唯一名称。例如:指定基本类或属性文件名称为TestBundle,而指定的Locale是CHINESE,那么最适合匹配的类名称为TestBundle_zh_CN.class,而最佳匹配属性文件名称为TestBundle_zh_CN.properties。按照Java Doc和相关文档的要求,如果该类或属性文件没有找到,系统会查找近似匹配(主文件名依次为TestBundle_zh和TestBundle的类或属性文件)。该类提供的getKeys()方法用于获得所有成员的键名,并提供handleGetObject方法获得指定键的对应元素。 |
ListResourceBundle:该类继承ResourceBundle类,主要是增加了一些便于操作的成分,但还是抽象类。如果希望使用类的方式实现具体的ResourceBundle,一般情况下最好继承这个类。 |
PropertyResourceBundle:该类也继承ResourceBundle类,可以实例化。该类的行为特征如同java.util.properties类,可以从输入流中获得具体属性对。 |
如果涉及日期和时间显示等问题时,可以利用java.text包以及java.util包中的TimeZone、SimpleTimeZone和Calendar等类进行辅助处理。 |
在具体应用时,可以把具体国家或地区特征中可以参数化的部分放在经过特殊命名的属性文件中,在确定具体的Locale后,通过PropertyResourceBundle类读取相应的属性文件,实现国际化特征。 |
使用PropertyResourceBundle类获得当地版本的国际化信息,部分代码如下: |
public static final String BASE_PROP_FILE = |
public static final String SUFFIX = |
locale = Locale.getDefault(); |
String propFile = BASE_PROP_FILE + “_” + locale.toString()+ SUFFIX; |
File file = new File(propFile); |
is = new FileInputStream(file); |
rb = new PropertyResourceBundle(is); |
if (rb == null) System.out.println(“No Resource”); |
} catch (IOException ioe) { |
System.out.println(“Error open file named ” + propFile); |
Enumeration e = rb.getKeys(); |
while (e.hasMoreElements()){ |
key = (String)e.nextElement(); |
value = (String)rb.handleGetObject(key); |
System.out.println(“KEY: ” + key + |
DISP_zh_TW.properties文件的具体内容如下: |
等号后面是利用native2ascii程序转化后的繁体汉字,如果不进行转化,系统可能显示乱码。 |
对于提示语言和帮助文件部分,可以把语言映射放在属性文件或者ListResourceBundle类的子类中。下面程序是一个Servlet,它通过接受客户端的选择,把特定语言和字符版本的信息返回到客户端。 |
public class ProcessServlet extends HttpServlet |
public static final String DEFAULT_LANGUAGE = “zh”; |
public static final String DEFAULT_COUNTRY = “CN”; |
public void service(HttpServletRequest req, |
HttpServletResponse res) throws IOException, ServletException { |
HttpSession session = req.getSession(true); |
// 从客户端收到的指定语言和字符的参数应当与Sun公司相关规定一致 |
String lang = req.getParameter |
String country = req.getParameter |
//如果没有收到参数,就试图从Session里获得 |
lang = (String) session.getAttribute |
country = (String) session.getAttribute |
session.setAttribute(“language”, lang); |
session.setAttribute(“country”, country); |
//如果无法从上述手段得到语言和字符信息,就使用默认值 |
country = DEFAULT_COUNTRY |
session.setAttribute(“language”, lang); |
session.setAttribute(“country”, country); |
ResourceBundle bundle = null; |
locale = new Locale(lang, country); |
System.out.println(“No locale with” + |
locale = Locale.getDefault(); |
bundle = ResourceBundle.getBundle( |
} catch( MissingResourceException e) { |
System.out.println( “No resources available for locale ” + locale); |
bundle = ResourceBundle.getBundle |
(“DisplayList”, Locale.US); |
res.setContentType(“text/html”); |
PrintWriter out = res.getWriter(); |
String title = bundle.getString(“title”); |
String welcome =bundle.getString |
String notice = bundle.getString(“notice”); |
out.println(“<title>”+ title + |
out.println(“<body bgcolor=/” |
out.println(“<h3>” + welcome + |
out.println(“<b>” + notice + |
上述Servlet使用的属性文件(DisplayList_zh_CN. |
注意:该文件直接采用了中文,而不是经过转化的Unicode编码,这是由于大多数Web服务器不需要上述转化。 |
在实际使用中,如果Web服务器支持Servlet 2.3规范(如jakarta-tomcate 4.0),那么上面提到的Servlet应当稍加改变,以作为其他Servlet的处理器使用。另外,如果把ResourceBundle的特定版本存放在无状态会话Bean中,就可以在一定程度上提高程序效率。 |
笔者在实际测试中发现了如下问题,其中部分问题得到了解决: |
1. 对于显示字符出现乱码的问题,如果是通过属性文件实现国际化解决方案,那么可能是直接在属性文件中写入了非标准ASCII文字。解决方法是利用JDK提供的工具native2ascii.exe扫描所有属性文件,用扫描结果覆盖原有文件内容。如果我们是利用类文件实现转换方案,那么需要重新编译相关类文件,并在编译时指定编码集。例如,编译使用国标码的类文件,采用的编译命令如下: |
javac -encoding GB2312 your_java_file |
2. 虽然Sun宣称,在ResourceBundle类的实例化过程中,该类会查找与指定的基础类绝对匹配和尽量与指定的Locale属性相匹配的类。例如:如果我们指定ResourceBundle基础类为TestBundle,而Locale中指定使用zh_CN(中国大陆地区简体中文),那么如果系统找不到TestBundle_zh_CN,系统应当顺次查找TestBundle_zh、TestBundle。但是笔者在系统开发过程中发现,该匹配没有产生任何实际效果。 |
笔者的测试平台是Windows 2000 Server,没有配置任何Service Pack,使用的JDK版本是1.3.0版本。笔者试图通过查看JDK目录下src.jar中附带的源码找到引起问题的原因,但是发现有关的操作被封装在sun.misc包中,而src.jar文件没有提供该包中任何类的源码。本文把这个问题提出来,希望与有关开发人员一起探讨。 |
java程序显示中文是大家都遇到过的问题,尤其是JAD文件的中文问题,一般都用native2ascii工具转换,这里收藏了native2ascii工具的详细说明:
native2ascii-Native-to-ASCIIConverter
Convertsafilewithnative-encodedcharacters(characterswhicharenon-Latin1andnon-Unicode)toonewithUnicode-encodedcharacters.
SYNOPSIS
native2ascii[options][inputfile[outputfile]]
DESCRIPTION
TheJavacompilerandotherJavatoolscanonlyprocessfileswhichcontainLatin-1and/orUnicode-encoded(/uddddnotation)characters.native2asciiconvertsfileswhichcontainothercharacterencodingsintofilescontainingLatin-1and/orUnicode-encodedcharaters.
Ifoutputfileisomitted,standardoutputisusedforoutput.If,inaddition,inputfileisomitted,standardinputisusedforinput.
OPTIONS
-reverse
Performthereverseoperation:convertafilewithLatin-1and/orUnicodeencodedcharacterstoonewithnative-encodedcharacters.
-encodingencoding_name
Specifytheencodingnamewhichisusedbytheconversionprocedure.ThedefaultencodingistakenfromSystempropertyfile.encoding.Theencoding_namestringmustbeastringtakenfromthefirstcolumnofthetablebelow.
-------------------------------------------------------------
ConverterDescription
Class
-------------------------------------------------------------
8859_1ISO8859-1
8859_2ISO8859-2
8859_3ISO8859-3
8859_4ISO8859-4
8859_5ISO8859-5
8859_6ISO8859-6
8859_7ISO8859-7
8859_8ISO8859-8
8859_9ISO8859-9
Big5Big5,TraditionalChinese
CNS11643CNS11643,TraditionalChinese
Cp037USA,Canada(Bilingual,French),Netherlands,
Portugal,Brazil,Australia
Cp1006IBMAIXPakistan(Urdu)
Cp1025IBMMultilingualCyrillic:Bulgaria,Bosnia,
Herzegovinia,Macedonia(FYR)
Cp1026IBMLatin-5,Turkey
Cp1046IBMOpenEditionUSEBCDIC
Cp1097IBMIran(Farsi)/Persian
Cp1098IBMIran(Farsi)/Persian(PC)
Cp1112IBMLatvia,Lithuania
Cp1122IBMEstonia
Cp1123IBMUkraine
Cp1124IBMAIXUkraine
Cp1125IBMUkraine(PC)
Cp1250WindowsEasternEuropean
Cp1251WindowsCyrillic
Cp1252WindowsLatin-1
Cp1253WindowsGreek
Cp1254WindowsTurkish
Cp1255WindowsHebrew
Cp1256WindowsArabic
Cp1257WindowsBaltic
Cp1258WindowsVietnamese
Cp1381IBMOS/2,DOSPeople'sRepublicofChina(PRC)
Cp1383IBMAIXPeople'sRepublicofChina(PRC)
Cp273IBMAustria,Germany
Cp277IBMDenmark,Norway
Cp278IBMFinland,Sweden
Cp280IBMItaly
Cp284IBMCatalan/Spain,SpanishLatinAmerica
Cp285IBMUnitedKingdom,Ireland
Cp297IBMFrance
Cp33722IBM-eucJP-Japanese(supersetof5050)
Cp420IBMArabic
Cp424IBMHebrew
Cp437MS-DOSUnitedStates,Australia,NewZealand,
SouthAfrica
Cp500EBCDIC500V1
Cp737PCGreek
Cp775PCBaltic
Cp838IBMThailandextendedSBCS
Cp850MS-DOSLatin-1
Cp852MS-DOSLatin-2
Cp855IBMCyrillic
Cp857IBMTurkish
Cp860MS-DOSPortuguese
Cp861MS-DOSIcelandic
Cp862PCHebrew
Cp863MS-DOSCanadianFrench
Cp864PCArabic
Cp865MS-DOSNordic
Cp866MS-DOSRussian
Cp868MS-DOSPakistan
Cp869IBMModernGreek
Cp870IBMMultilingualLatin-2
Cp871IBMIceland
Cp874IBMThai
Cp875IBMGreek
Cp918IBMPakistan(Urdu)
Cp921IBMLatvia,Lithuania(AIX,DOS)
Cp922IBMEstonia(AIX,DOS)
Cp930JapaneseKatakana-Kanjimixedwith4370UDC,
supersetof5026
Cp933KoreanMixedwith1880UDC,supersetof5029
Cp935SimplifiedChineseHostmixedwith1880UDC,
supersetof5031
Cp937TraditionalChineseHostmiexedwith6204UDC,
supersetof5033
Cp939JapaneseLatinKanjimixedwith4370UDC,
supersetof5035
Cp942Japanese(OS/2)supersetof932
Cp948OS/2Chinese(Taiwan)supersetof938
Cp949PCKorean
Cp950PCChinese(HongKong,Taiwan)
Cp964AIXChinese(Taiwan)
Cp970AIXKorean
EUCJISJIS,EUCEncoding,Japanese
GB2312GB2312,EUCencoding,SimplifiedChinese
GBKGBK,SimplifiedChinese
ISO2022CNISO2022CN,Chinese
ISO2022CN_CNSCNS11643inISO-2022-CNform,T.Chinese
ISO2022CN_GBGB2312inISO-2022-CNform,S.Chinese
ISO2022KRISO2022KR,Korean
JISJIS,Japanese
JIS0208JIS0208,Japanese
KOI8_RKOI8-R,Russian
KSC5601KSC5601,Korean
MS874WindowsThai
MacArabicMacintoshArabic
MacCentralEuropeMacintoshLatin-2
MacCroatianMacintoshCroatian
MacCyrillicMacintoshCyrillic
MacDingbatMacintoshDingbat
MacGreekMacintoshGreek
MacHebrewMacintoshHebrew
MacIcelandMacintoshIceland
MacRomanMacintoshRoman
MacRomaniaMacintoshRomania
MacSymbolMacintoshSymbol
MacThaiMacintoshThai
MacTurkishMacintoshTurkish
MacUkraineMacintoshUkraine
SJISShift-JIS,Japanese
UTF8UTF-8
不过WTK可以直接解决JAD的中文问题:
settings>MidLets>MidLet-1属性改成你想要显示的中文后重新生成JAD和JAR文件即可。
JAVA字符的编码
一、概要
在JAVA应用程序特别是基于WEB的程序中,经常遇到字符的编码问题。为了防止出现乱码,首先需要了解JAVA是如何处理字符的,这样就可以有目的地在输入/输出环节中增加必要的转码。其次,由于各种服务器有不同的处理方式,还需要多做试验,确保使用中不出现乱码。
二、基本概念
2.1JAVA中字符的表达
JAVA中有char、byte、String这几个概念。char 指的是一个UNICODE字符,为16位的整数。byte 是字节,字符串在网络传输或存储前需要转换为byte数组。在从网络接收或从存储设备读取后需要将byte数组转换成String。String是字符串,可以看成是由char组成的数组。String 和 char 为内存形式,byte是网络传输或存储的序列化形式。
举例:
英
Stringying = “英”;
char ying = ying.charAt(0);
String yingHex = Integer.toHexString(ying);
82F1
byte yingGBBytes = ying.getBytes(“GBK”);
GB编码的字节数值
D3A2
2.2编码方式的简介
String序列化成byte数组或反序列化时需要选择正确的编码方式。如果编码方式不正确,就会得到一些0x3F的值。常用的字符编码方式有ISO8859_1、GB2312、GBK、UTF-8/UTF-16/UTF-32。
ISO8859_1用来编码拉丁文,它由单字节(0-255)组成。
GB2312、GBK用来编码简体中文,它有单字节和双字节混合组成。最高位为1的字节和下一个字节构成一个汉字,最高位为0的字节是ASCII码。
UTF-8/UTF-16/UTF-32是国际标准UNICODE的编码方式。 用得最多的是UTF-8,主要是因为它在对拉丁文编码时节约空间。
UNICODE值UTF-8编码
U-00000000 - U-0000007F:0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
三、J2SE中相关的函数
String str =”英”;
//取得GB2312编码的字节
byte[] bytesGB2312 = str.getBytes(“GB2312”);
//取得平台缺省编码的字节(solaris为ISO8859_1,windows为GB2312)
byte[] bytesDefault = str.getBytes();
//用指定的编码将字节转换成字符串
String newStrGB = new String(bytesGB2312, “GB2312”);
//用平台缺省的编码将字节转换成字符串(solaris为ISO8859_1,windows为GB2312)
String newStrDefault = new String(bytesDefault);
//用指定的编码从字节流里面读取字符
InputStream in = xxx;
InputStreamReader reader = InputStreamReader( in, “GB2312”);
char aChar = reader.read();
四、JSP、数据库的编码
4.1JSP中的编码
(1) 静态声明:
CHARSET有两个作用:
JSP文件的编码方式:在读取JSP文件、生成JAVA类时,源JSP文件中汉字的编码
JSP输出流的编码方式:在执行JSP时,往response流里面写入数据的编码方式
(2) 动态改变:在往response流里面写数据前可以调用response.setContentType(),设定正确的编码类型。
(3) 在TOMCAT中,由Request.getParameter() 得到的参数,编码方式都是ISO8859_1。所以如果在浏览器输入框内输入一个汉字“英”,在服务器端就得到一个ISO8859_1编码的(0x00,0xD3,0x00,0xA2)。所以通常在接收参数时转码:
String wrongStr = response.getParameter(“name”);
String correctStr = new String(wrongStr.getBytes(“ISO8859_1”),”GB2312”);
在最新的SERVLET规范里面,也可以在获取参数之前执行如下代码:
request.setCharacterEncoding(“GB2312”);
4.2数据库的编码
(1) 数据库使用UTF-16
如果String中是UNICODE字符,写入读出时不需要转码
(2) 数据库使用ISO8859_1
如果String中是UNICODE字符,写入读出时需要转码
写入:String newStr = new String(oldStr.getByte(“GB2312”), “ISO8859_1”);
读出:String newStr = new String(oldStr.getByte(“ISO8859_1”),”GB2312”);
五、源文件的编码
5.1 资源文件
资源文件的编码方式和编辑平台相关。在WINDOWS平台下编写的资源文件,以GB2312方式编码。在编译时需要转码,以确保在各个平台上的正确性:
native2ascii –encoding GB2312 source.properties
这样从资源文件中读出的就是正确的UNICODE字符串。
5.2 源文件
源文件的编码方式和编辑平台相关。在WINDOWS平台下开发的源文件,以GB2312方式编码。在编译的时候,需要指定源文件的编码方式:
javac –encoding GB2312
JAVA编译后生成的字节文件的编码为UTF-8。
①最新版TOMCAT4.1.18支持request.setCharacterEncoding(String enc)
②资源文件转码成company.name=/u82f1/u65af/u514b
③如果数据库使用utf-16则不需要这部分转码
④页面上应有
转码ⅰ:
String s = new String
(request.getParameter(“name”).getBytes(“ISO8859_1”),”GB2312”);
转码ⅱ:
String s = new String(name.getBytes(“GB2312”),”ISO8859_1”);
转码ⅲ:
String s = new String(name.getBytes(“ISO8859_1”),” GB2312”);