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-ASCII Converter
Converts a file with native-encoded characters (characters which are non-Latin 1 and non-Unicode) to one with Unicode-encoded characters.
SYNOPSIS
native2ascii [options] [inputfile [outputfile]]
DESCRIPTION
The Java compiler and other Java tools can only process files which contain Latin-1 and/or Unicode-encoded (/udddd notation) characters. native2ascii converts files which contain other character encodings into files containing Latin-1 and/or Unicode-encoded charaters.
If outputfile is omitted, standard output is used for output. If, in addition, inputfile is omitted, standard input is used for input.
OPTIONS
-reverse
Perform the reverse operation: convert a file with Latin-1 and/or Unicode encoded characters to one with native-encoded characters.
-encoding encoding_name
Specify the encoding name which is used by the conversion procedure. The default encoding is taken from System property file.encoding. The encoding_name string must be a string taken from the first column of the table below.
-------------------------------------------------------------
Converter Description
Class
-------------------------------------------------------------
8859_1 ISO 8859-1
8859_2 ISO 8859-2
8859_3 ISO 8859-3
8859_4 ISO 8859-4
8859_5 ISO 8859-5
8859_6 ISO 8859-6
8859_7 ISO 8859-7
8859_8 ISO 8859-8
8859_9 ISO 8859-9
Big5 Big5, Traditional Chinese
CNS11643 CNS 11643, Traditional Chinese
Cp037 USA, Canada(Bilingual, French), Netherlands,
Portugal, Brazil, Australia
Cp1006 IBM AIX Pakistan (Urdu)
Cp1025 IBM Multilingual Cyrillic: Bulgaria, Bosnia,
Herzegovinia, Macedonia(FYR)
Cp1026 IBM Latin-5, Turkey
Cp1046 IBM Open Edition US EBCDIC
Cp1097 IBM Iran(Farsi)/Persian
Cp1098 IBM Iran(Farsi)/Persian (PC)
Cp1112 IBM Latvia, Lithuania
Cp1122 IBM Estonia
Cp1123 IBM Ukraine
Cp1124 IBM AIX Ukraine
Cp1125 IBM Ukraine (PC)
Cp1250 Windows Eastern European
Cp1251 Windows Cyrillic
Cp1252 Windows Latin-1
Cp1253 Windows Greek
Cp1254 Windows Turkish
Cp1255 Windows Hebrew
Cp1256 Windows Arabic
Cp1257 Windows Baltic
Cp1258 Windows Vietnamese
Cp1381 IBM OS/2, DOS People's Republic of China (PRC)
Cp1383 IBM AIX People's Republic of China (PRC)
Cp273 IBM Austria, Germany
Cp277 IBM Denmark, Norway
Cp278 IBM Finland, Sweden
Cp280 IBM Italy
Cp284 IBM Catalan/Spain, Spanish Latin America
Cp285 IBM United Kingdom, Ireland
Cp297 IBM France
Cp33722 IBM-eucJP - Japanese (superset of 5050)
Cp420 IBM Arabic
Cp424 IBM Hebrew
Cp437 MS-DOS United States, Australia, New Zealand,
South Africa
Cp500 EBCDIC 500V1
Cp737 PC Greek
Cp775 PC Baltic
Cp838 IBM Thailand extended SBCS
Cp850 MS-DOS Latin-1
Cp852 MS-DOS Latin-2
Cp855 IBM Cyrillic
Cp857 IBM Turkish
Cp860 MS-DOS Portuguese
Cp861 MS-DOS Icelandic
Cp862 PC Hebrew
Cp863 MS-DOS Canadian French
Cp864 PC Arabic
Cp865 MS-DOS Nordic
Cp866 MS-DOS Russian
Cp868 MS-DOS Pakistan
Cp869 IBM Modern Greek
Cp870 IBM Multilingual Latin-2
Cp871 IBM Iceland
Cp874 IBM Thai
Cp875 IBM Greek
Cp918 IBM Pakistan(Urdu)
Cp921 IBM Latvia, Lithuania (AIX, DOS)
Cp922 IBM Estonia (AIX, DOS)
Cp930 Japanese Katakana-Kanji mixed with 4370 UDC,
superset of 5026
Cp933 Korean Mixed with 1880 UDC, superset of 5029
Cp935 Simplified Chinese Host mixed with 1880 UDC,
superset of 5031
Cp937 Traditional Chinese Host miexed with 6204 UDC,
superset of 5033
Cp939 Japanese Latin Kanji mixed with 4370 UDC,
superset of 5035
Cp942 Japanese (OS/2) superset of 932
Cp948 OS/2 Chinese (Taiwan) superset of 938
Cp949 PC Korean
Cp950 PC Chinese (Hong Kong, Taiwan)
Cp964 AIX Chinese (Taiwan)
Cp970 AIX Korean
EUCJIS JIS, EUC Encoding, Japanese
GB2312 GB2312, EUC encoding, Simplified Chinese
GBK GBK, Simplified Chinese
ISO2022CN ISO 2022 CN, Chinese
ISO2022CN_CNS CNS 11643 in ISO-2022-CN form, T. Chinese
ISO2022CN_GB GB 2312 in ISO-2022-CN form, S. Chinese
ISO2022KR ISO 2022 KR, Korean
JIS JIS, Japanese
JIS0208 JIS 0208, Japanese
KOI8_R KOI8-R, Russian
KSC5601 KS C 5601, Korean
MS874 Windows Thai
MacArabic Macintosh Arabic
MacCentralEurope Macintosh Latin-2
MacCroatian Macintosh Croatian
MacCyrillic Macintosh Cyrillic
MacDingbat Macintosh Dingbat
MacGreek Macintosh Greek
MacHebrew Macintosh Hebrew
MacIceland Macintosh Iceland
MacRoman Macintosh Roman
MacRomania Macintosh Romania
MacSymbol Macintosh Symbol
MacThai Macintosh Thai
MacTurkish Macintosh Turkish
MacUkraine Macintosh Ukraine
SJIS Shift-JIS, Japanese
UTF8 UTF-8
不过WTK可以直接解决JAD的中文问题：
settings>MidLets>MidLet-1属性改成你想要显示的中文后重新生成JAD和JAR文件即可。
JAVA字符的编码
一、概要
在JAVA应用程序特别是基于WEB的程序中，经常遇到字符的编码问题。为了防止出现乱码，首先需要了解JAVA是如何处理字符的，这样就可以有目的地在输入/输出环节中增加必要的转码。其次，由于各种服务器有不同的处理方式，还需要多做试验，确保使用中不出现乱码。
二、基本概念
2．1 JAVA中字符的表达
JAVA中有char、byte、String这几个概念。char 指的是一个UNICODE字符，为16位的整数。byte 是字节，字符串在网络传输或存储前需要转换为byte数组。在从网络接收或从存储设备读取后需要将byte数组转换成String。String是字符串，可以看成是由char组成的数组。String 和 char 为内存形式，byte是网络传输或存储的序列化形式。
举例：
英
String ying = “英”;
char ying = ying.charAt(0);
String yingHex = Integer.toHexString(ying);
82 F1
byte yingGBBytes = ying.getBytes(“GBK”);
GB编码的字节数值
D3 A2
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．1 JSP中的编码
(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”);
扫一扫
308
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
