`
jiasudu1649
  • 浏览: 732086 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

jsp语言处理

阅读更多
世界上的各地区都有本地的语言。地区差异直接导致了语言环境的差异。在开发一个国际化
程序的过程中,处理语言问题就显得很重要了。
这是一个世界范围内都存在的问题,所以,Java提供了世界性的解决方法。本文描述的
方法是用于处理中文的,但是,推而广之,对于处理世界上其它国家和地区的语言同样适
用。
汉字是双字节的。所谓双字节是指一个双字要占用两个BYTE的位置(即16位),分
别称为高位和低位。中国规定的汉字编码为GB2312,这是强制性的,目前几乎所有的能处
理中文的应用程序都支持GB2312。GB2312包括了一二级汉字和9区符号,高位从0xa1到
0xfe,低位也是从0xa1到0xfe,其中,汉字的编码范围为0xb0a1到0xf7fe。
另外有一种编码,叫做GBK,但这是一份规范,不是强制的。GBK提供了20902个汉
字,它兼容GB2312,编码范围为0x8140到0xfefe。GBK中的所有字符都可以一一映射到
Unicode 2.0。
在不久的将来,中国会颁布另一种标准:GB18030-2000(GBK2K)。它收录了藏、蒙
等少数民族的字型,从根本上解决了字位不足的问题。注意:它不再是定长的。其二字节部
份与GBK兼容,四字节部分是扩充的字符、字形。它的首字节和第三字节从0x81到0xfe,
二字节和第四字节从0x30到0x39。
本文不打算介绍Unicode,有兴趣的可以浏览“http://www.unicode.org/”查看更多的信
息。Unicode有一个特性:它包括了世界上所有的字符字形。所以,各个地区的语言都可以
建立与Unicode的映射关系,而Java正是利用了这一点以达到异种语言之间的转换。
在JDK中,与中文相关的编码有:
表1 JDK中与中文相关的编码列表
编码名称说明
ASCII 7位,与ascii7相同
ISO8859-1 8-位,与 8859_1,ISO-8859-1,ISO_8859-1,latin1...等相同
GB2312-80 16位,与gb2312,gb2312-1980,EUC_CN,euccn,1381,Cp1381, 1383, Cp1383,
ISO2022CN,ISO2022CN_GB...等相同
GBK 与MS936相同,注意:区分大小写
UTF8 与UTF-8相同
GB18030 与cp1392、1392相同,目前支持的JDK很少
在实际编程时,接触得比较多的是GB2312(GBK)和ISO8859-1。
为什么会有“?”号
上文说过,异种语言之间的转换是通过Unicode来完成的。假设有两种不同的语言A和
B,转换的步骤为:先把A转化为Unicode,再把Unicode转化为B。
举例说明。有GB2312中有一个汉字“李”,其编码为“C0EE”,欲转化为ISO8859-1
编码。步骤为:先把“李”字转化为Unicode,得到“674E”,再把“674E”转化为ISO8859-
1字符。当然,这个映射不会成功,因为ISO8859-1中根本就没有与“674E”对应的字符。
当映射不成功时,问题就发生了!当从某语言向Unicode转化时,如果在某语言中没
有该字符,得到的将是Unicode的代码“\uffffd”(“\u”表示是Unicode编码,)。而从
Unicode向某语言转化时,如果某语言没有对应的字符,则得到的是“0x3f”(“?”)。这就
是“?”的由来。
例如:把字符流buf =“0x80 0x40 0xb0 0xa1”进行new String(buf, "gb2312")操作,得到
的结果是“\ufffd\u554a”,再println出来,得到的结果将是“?啊”,因为“0x80 0x40”是
GBK中的字符,在GB2312中没有。
再如,把字符串String="\u00d6\u00ec\u00e9\u0046\u00bb\u00f9"进行new String
(buf.getBytes("GBK"))操作,得到的结果是“3fa8aca8a6463fa8b4”,其中,“\u00d6”在
“GBK”中没有对应的字符,得到“3f”,“\u00ec”对应着“a8ac”,“\u00e9”对应着
“a8a6”,“0046”对应着“46”(因为这是ASCII字符),“\u00bb”没找到,得到“3f”,
最后,“\u00f9”对应着“a8b4”。把这个字符串println一下,得到的结果是“?ìéF?ù”。看到
没?这里并不全是问号,因为GBK与Unicode映射的内容中除了汉字外还有字符,本例就
是最好的明证。
所以,在汉字转码时,如果发生错乱,得到的不一定都是问号噢!不过,错了终究是
错了,50步和100步并没有质的差别。
或者会问:如果源字符集中有,而Unicode中没有,结果会如何?回答是不知道。因为
我手头没有能做这个测试的源字符集。但有一点是肯定的,那就是源字符集不够规范。在
Java中,如果发生这种情况,是会抛出异常的。
什么是UTF
UTF,是Unicode Text Format的缩写,意为Unicode文本格式。对于UTF,是这样定义
的:
(1)如果Unicode的16位字符的头9位是0,则用一个字节表示,这个字节的首位是
“0”,剩下的7位与原字符中的后7位相同,如“\u0034”(0000 0000 0011 0100),用
“34” (0011 0100)表示;(与源Unicode字符是相同的);
(2)如果Unicode的16位字符的头5位是0,则用2个字节表示,首字节是“110”开
头,后面的5位与源字符中除去头5个零后的最高5位相同;第二个字节以“10”开头,后
面的6位与源字符中的低6位相同。如“\u025d”(0000 0010 0101 1101),转化后为
“c99d”(1100 1001 1001 1101);
(3)如果不符合上述两个规则,则用三个字节表示。第一个字节以“1110”开头,后四
位为源字符的高四位;第二个字节以“10”开头,后六位为源字符中间的六位;第三个字节
以“10”开头,后六位为源字符的低六位;如“\u9da7”(1001 1101 1010 0111),转化为
“e9b6a7”(1110 1001 1011 0110 1010 0111);
可以这么描述JAVA程序中Unicode与UTF的关系,虽然不绝对:字符串在内存中运
行时,表现为Unicode代码,而当要保存到文件或其它介质中去时,用的是UTF。这个转化
过程是由writeUTF和readUTF来完成的。
好了,基础性的论述差不多了,下面进入正题。
先把这个问题想成是一个黑匣子。先看黑匣子的一级表示:
input(charsetA)->process(Unicode)->output(charsetB)
简单,这就是一个IPO模型,即输入、处理和输出。同样的内容要经过“从charsetA到
unicode再到charsetB”的转化。
再看二级表示:
SourceFile(jsp,java)->class->output
在这个图中,可以看出,输入的是jsp和java源文件,在处理过程中,以Class文件为
载体,然后输出。再细化到三级表示:
jsp->temp file->class->browser,os console,db
app,servlet->class->browser,os console,db
这个图就更明白了。Jsp文件先生成中间的Java文件,再生成Class。而Servlet和普通
App则直接编译生成Class。然后,从Class再输出到浏览器、控制台或数据库等。
JSP:从源文件到Class的过程
Jsp的源文件是以“.jsp”结尾的文本文件。在本节中,将阐述JSP文件的解释和编译过
程,并跟踪其中的中文变化。
1、JSP/Servlet引擎提供的JSP转换工具(jspc)搜索JSP文件中用<%@ page
contentType ="text/html; charset=<jsp-charset>"%>中指定的charset。如果在JSP文件中未指定
<jsp-charset>,则取JVM中的默认设置file.encoding,一般情况下,这个值是ISO8859-1;
2、jspc用相当于“javac –encoding <jsp-charset>”的命令解释JSP文件中出现的所有字符,
包括中文字符和ASCII字符,然后把这些字符转换成Unicode字符,再转化成UTF格式,
存为JAVA文件。ASCII码字符转化为Unicode字符时只是简单地在前面加“00”,如“A”,
转化为“\u0041”(不需要理由,Unicode的码表就是这么编的)。然后,经过到UTF的转
换,又变回“41”了!这也就是可以使用普通文本编辑器查看由JSP生成的JAVA文件的原
因;
3、引擎用相当于“javac –encoding UNICODE”的命令,把JAVA文件编译成CLASS文
件;
先看一下这些过程中中文字符的转换情况。有如下源代码:
<%@ page contentType="text/html; charset=gb2312"%>

<%
String a="中文";
out.println(a);
%>

这段代码是在UltraEdit for Windows上编写的。保存后,“中文”两个字的16进制编码
为“D6 D0 CE C4”(GB2312编码)。经查表,“中文”两字的Unicode编码为
“\u4E2D\u6587”,用 UTF表示就是“E4 B8 AD E6 96 87”。打开引擎生成的由JSP文件转
变而成的JAVA文件,发现其中的“中文”两个字确实被“E4 B8 AD E6 96 87”替代了,再
查看由JAVA文件编译生成的CLASS文件,发现结果与JAVA文件中的完全一样。
再看JSP中指定的CharSet为ISO-8859-1的情况。
<%@ page contentType="text/html; charset=ISO-8859-1"%>

<%
String a="中文";
out.println(a);
%>

同样,该文件是用UltraEdit编写的,“中文”这两个字也是存为GB2312编码“D6
D0 CE C4”。先模拟一下生成的JAVA文件和CLASS文件的过程:jspc用ISO-8859-1来解释
“中文”,并把它映射到Unicode。由于ISO-8859-1是8位的,且是拉丁语系,其映射规则
就是在每个字节前加“00”,所以,映射后的Unicode编码应为
“\u00D6\u00D0\u00CE\u00C4”,转化成UTF后应该是“C3 96 C3 90 C3 8E C3 84”。好,打
开文件看一下,JAVA文件和CLASS文件中,“中文”果然都表示为“C3 96 C3 90 C3 8E
C3 84”。
如果上述代码中不指定<jsp-charset>,即把第一行写成“<%@ page
contentType="text/html" %>”,JSPC会使用file.encoding的设置来解释JSP文件。在RedHat
6.2上,其处理结果与指定为ISO-8859-1是完全相同的。
到现在为止,已经解释了从JSP文件到CLASS文件的转变过程中中文字符的映射过程。
一句话:从“JspCharSet到Unicode再到UTF”。下表总结了这个过程:
表2 “中文”从JSP到CLASS的转化过程
Jsp-CharSet JSP文件中JAVA文件中CLASS文件中
GB2312 D6 D0 CE
C4(GB2312)
从\u4E2D\u6587(Unicode)到E4 B8 AD E6
96 87 (UTF)
E4 B8 AD E6 96 87
(UTF)
ISO-8859-1 D6 D0 CE C4
(GB2312)
从\u00D6\u00D0\u00CE\u00C4 (Unicode)到
C3 96 C3 90 C3 8E C3 84 (UTF)
C3 96 C3 90 C3 8E
C3 84 (UTF)
无(默认=
file.encoding)
同ISO-8859-1 同ISO-8859-1 同ISO-8859-1
下节先讨论Servlet从JAVA文件到CLASS文件的转化过程,然后再解释从CLASS文
件如何输出到客户端。之所以这样安排,是因为JSP和Servlet在输出时处理方法是一样的。
Servlet:从源文件到Class的过程
Servlet源文件是以“.java”结尾的文本文件。本节将讨论Servlet的编译过程并跟踪其中
的中文变化。
用“javac”编译Servlet源文件。javac可以带“-encoding <compile-charset>”参数,意思
是“用< Compile-charset >中指定的编码来解释Serlvet源文件”。
源文件在编译时,用<compile-charset>来解释所有字符,包括中文字符和ASCII字符。
然后把字符常量转变成Unicode字符,最后,把Unicode转变成UTF。
在Servlet中,还有一个地方设置输出流的CharSet。通常在输出结果前,调用
HttpServletResponse的setContentType方法来达到与在JSP中设置<jsp-charset>一样的效果,
称之为<servlet-charset>。
注意,文中一共提到了三个变量:<jsp-charset>、<compile-charset>和<servlet-charset>。
其中,JSP文件只与<jsp-charset>有关,而<compile-charset>和<servlet-charset>只与Servlet
有关。
看下例:
import javax.servlet.*;
import javax.servlet.http.*;
class testServlet extends HttpServlet
{
public void doGet(HttpServletRequest req,HttpServletResponse resp)
throws ServletException,java.io.IOException
{
resp.setContentType("text/html; charset=GB2312");
java.io.PrintWriter out=resp.getWriter();
out.println("");
out.println("#中文#");
out.println("");
}
}
该文件也是用UltraEdit for Windows编写的,其中的“中文”两个字保存为“D6 D0
CE C4”(GB2312编码)。
开始编译。下表是<compile-charset>不同时,CLASS文件中“中文”两字的十六进制
码。在编译过程中,<servlet-charset>不起任何作用。<servlet-charset>只对CLASS文件的输
出产生影响,实际上是<servlet-charset>和<compile-charset>一起,达到与JSP文件中的
<jsp-charset>相同的效果,因为<jsp-charset>对编译和CLASS文件的输出都会产生影响。
表3 “中文”从Servlet源文件到Class的转变过程
Compile-charset Servlet源文件中Class文件中等效的Unicode码
GB2312 D6 D0 CE C4
(GB2312)
E4 B8 AD E6 96 87
(UTF)
\u4E2D\u6587 (在Unicode中=“中文”)
ISO-8859-1 D6 D0 CE C4
(GB2312)
C3 96 C3 90 C3 8E C3
84 (UTF)
\u00D6 \u00D0 \u00CE \u00C4 (在D6 D0
CE C4前面各加了一个00)
无(默认) D6 D0 CE C4
(GB2312)
同ISO-8859-1 同ISO-8859-1
普通Java程序的编译过程与Servlet完全一样。
CLASS文件中的中文表示法是不是昭然若揭了?OK,接下来看看CLASS又是怎样输
出中文的呢?
Class:输出字符串
上文说过,字符串在内存中表现为Unicode编码。至于这种Unicode编码表示了什么,
那要看它是从哪种字符集映射过来的,也就是说要看它的祖先。这好比在托运行李时,外观
都是纸箱子,里面装了什么就要看寄邮件的人实际邮了什么东西。
看看上面的例子,如果给一串Unicode编码“00D6 00D0 00CE 00C4”,如果不作转换,
直接用Unicode码表来对照它时,是四个字符(而且是特殊字符);假如把它与
“ISO8859-1”进行映射,则直接去掉前面的“00”即可得到“D6 D0 CE C4”,这是ASCII码
表中的四个字符;而假如把它当作GB2312来进行映射,得到的结果很可能是一大堆乱码,
因为在GB2312中有可能没有(也有可能有)字符与00D6等字符对应(如果对应不上,将
得到0x3f,也就是问号,如果对应上了,由于00D6等字符太靠前,估计也是一些特殊符
号,真正的汉字在Unicode中的编码从4E00开始)。
各位看到了,同样的Unicode字符,可以解释成不同的样子。当然,这其中有一种是我
们期望的结果。以上例而论,“D6 D0 CE C4”应该是我们所想要的,当把“D6 D0 CE C4”
输出到IE中时,用“简体中文”方式查看,就能看到清楚的“中文”两个字了。(当然了,
如果你一定要用“西欧字符”来看,那也没办法,你将得不到任何有何时何地的东西)为
什么呢?因为“00D6 00D0 00CE 00C4”本来就是由ISO8859-1转化过去的。
给出如下结论:
在Class输出字符串前,会将Unicode的字符串按照某一种内码重新生成字
节流,然后把字节流输入,相当于进行了一步“String.getBytes(???)”操作。???代
表某一种字符集。
如果是Servlet,那么,这种内码就是在
HttpServletResponse.setContentType()方法中指定的内码,也就是上文定义的<
Servlet-charset>。
如果是JSP,那么,这种内码就是在<%@ page contentType=""%>中指定
的内码,也就是上文定义的<Jsp-charset>。
如果是Java程序,那么,这种内码就是file.encoding中指定的内码,默认
为ISO8859-1。
当输出对象是浏览器时
以流行的浏览器IE为例。IE支持多种内码。假如IE接收到了一个字节流
“D6 D0 CE C4”,你可以尝试用各种内码去查看。你会发现用“简体中文”时能
得到正确的结果。因为“D6 D0 CE C4”本来就是简体中文中“中文”两个字的编
码。
OK,完整地看一遍。
JSP:源文件为GB2312格式的文本文件,且JSP源文件中有“中文”这两
个汉字
如果指定了<Jsp-charset>为GB2312,转化过程如下表。
表4 Jsp-charset = GB2312时的变化过程
序号步骤说明结果
1 编写JSP源文件,且存为GB2312格式D6 D0 CE C4
(D6D0=中 CEC4=文)
2 jspc把JSP源文件转化为临时JAVA文件,并把字符串按照
GB2312映射到Unicode,并用UTF格式写入JAVA文件中
E4 B8 AD E6 96 87
3 把临时JAVA文件编译成CLASS文件E4 B8 AD E6 96 87
4 运行时,先从CLASS文件中用readUTF读出字符串,在内存
中的是Unicode编码
4E 2D 65 87(在Unicode
中4E2D=中 6587=文)
5 根据Jsp-charset=GB2312把Unicode转化为字节流D6 D0 CE C4
6 把字节流输出到IE中,并设置IE的编码为GB2312(作者按:
这个信息隐藏在HTTP头中)
D6 D0 CE C4
7 IE用“简体中文”查看结果“中文”(正确显示)
如果指定了<Jsp-charset>为ISO8859-1,转化过程如下表。
表5 Jsp-charset = ISO8859-1时的变化过程
序号步骤说明结果
1 编写JSP源文件,且存为GB2312格式D6 D0 CE C4
(D6D0=中 CEC4=文)
2 jspc把JSP源文件转化为临时JAVA文件,并把字符串按照
ISO8859-1映射到Unicode,并用UTF格式写入JAVA文件中
C3 96 C3 90 C3 8E C3 84
3 把临时JAVA文件编译成CLASS文件C3 96 C3 90 C3 8E C3 84
4 运行时,先从CLASS文件中用readUTF读出字符串,在内存
中的是Unicode编码
00 D6 00 D0 00 CE 00 C4
(啥都不是!!!)
5 根据Jsp-charset=ISO8859-1把Unicode转化为字节流D6 D0 CE C4
6 把字节流输出到IE中,并设置IE的编码为ISO8859-1(作者按:
这个信息隐藏在HTTP头中)
D6 D0 CE C4
7 IE用“西欧字符”查看结果乱码,其实是四个ASCII
字符,但由于大于128,
所以显示出来的怪模怪样
8 改变IE的页面编码为“简体中文” “中文”(正确显示)
奇怪了!为什么把<Jsp-charset>设成GB2312和ISO8859-1是一个样的,都能正确显
示?因为表4表5中的第2步和第5步互逆,是相互“抵消”的。只不过当指定为ISO8859-
1时,要增加第8步操作,殊为不便。
再看看不指定<Jsp-charset> 时的情况。
表6 未指定Jsp-charset 时的变化过程
序号步骤说明结果
1 编写JSP源文件,且存为GB2312格式D6 D0 CE C4
(D6D0=中 CEC4=文)
2 jspc把JSP源文件转化为临时JAVA文件,并把字符串按照
ISO8859-1映射到Unicode,并用UTF格式写入JAVA文件中
C3 96 C3 90 C3 8E C3
84
3 把临时JAVA文件编译成CLASS文件C3 96 C3 90 C3 8E C3
84
4 运行时,先从CLASS文件中用readUTF读出字符串,在内存中的
是Unicode编码
00 D6 00 D0 00 CE 00
C4
5 根据Jsp-charset=ISO8859-1把Unicode转化为字节流D6 D0 CE C4
6 把字节流输出到IE中D6 D0 CE C4
7 IE用发出请求时的页面的编码查看结果视情况而定。如果是简
体中文,则能正确显示,
否则,需执行表5中的
第8步
Servlet:源文件为JAVA文件,格式是GB2312,源文件中含有“中文”这两个汉字
如果<Compile-charset>=GB2312,<Servlet-charset>=GB2312
表7 Compile-charset=Servlet-charset=GB2312 时的变化过程


步骤说明结果
1 编写Servlet源文件,且存为GB2312格式D6 D0 CE C4
(D6D0=中 CEC4=文)
2 用javac –encoding GB2312把JAVA源文件编译成CLASS文件E4 B8 AD E6 96 87
(UTF)
3 运行时,先从CLASS文件中用readUTF读出字符串,在内存中的
是Unicode编码
4E 2D 65 87 (Unicode)
4 根据Servlet-charset=GB2312把Unicode转化为字节流D6 D0 CE C4 (GB2312)
5 把字节流输出到IE中并设置IE的编码属性为Servletcharset=
GB2312
D6 D0 CE C4 (GB2312)
6 IE用“简体中文”查看结果“中文”(正确显示)
如果<Compile-charset>=ISO8859-1,<Servlet-charset>=ISO8859-1
表8 Compile-charset=Servlet-charset=ISO8859-1时的变化过程


步骤说明结果
1 编写Servlet源文件,且存为GB2312格式D6 D0 CE C4
(D6D0=中 CEC4=文)
2 用javac –encoding ISO8859-1把JAVA源文件编译成CLASS文

C3 96 C3 90 C3 8E C3 84
(UTF)
3 运行时,先从CLASS文件中用readUTF读出字符串,在内存中
的是Unicode编码
00 D6 00 D0 00 CE 00 C4
4 根据Servlet-charset=ISO8859-1把Unicode转化为字节流D6 D0 CE C4
5 把字节流输出到IE中并设置IE的编码属性为Servletcharset=
ISO8859-1
D6 D0 CE C4 (GB2312)
6 IE用“西欧字符”查看结果乱码(原因同表5)
7 改变IE的页面编码为“简体中文” “中文”(正确显示)
如果不指定Compile-charset或Servlet-charset,其默认值均为ISO8859-1。
当Compile-charset=Servlet-charset时,第2步和第4步能互逆,“抵消”,显示结果均
能正确。读者可试着写一下Compile-charset<>Servlet-charset时的情况,肯定是不正确的。
当输出对象是数据库时
输出到数据库时,原理与输出到浏览器也是一样的。本节只是Servlet为例,JSP的情况
请读者自行推导。
假设有一个Servlet,它能接收来自客户端(IE,简体中文)的汉字字符串,然后把它
写入到内码为ISO8859-1的数据库中,然后再从数据库中取出这个字符串,显示到客户端。
表9 输出对象是数据库时的变化过程(1)
序号步骤说明结果域
1 在IE中输入“中文” D6 D0 CE C4
2 IE把字符串转变成UTF,并送入传输流中E4 B8 AD E6 96 87
IE
3 Servlet接收到输入流,用readUTF读取4E 2D 65 87(unicode)
4 编程者在Servlet中必须把字符串根据GB2312还原为字节

D6 D0 CE C4
5 编程者根据数据库内码ISO8859-1生成新的字符串00 D6 00 D0 00 CE 00
C4
6 把新生成的字符串提交给JDBC 00 D6 00 D0 00 CE 00
C4
Servlet
7 JDBC检测到数据库内码为ISO8859-1 00 D6 00 D0 00 CE 00
C4
8 JDBC把接收到的字符串按照ISO8859-1生成字节流D6 D0 CE C4
9 JDBC把字节流写入数据库中D6 D0 CE C4
10 完成数据存储工作D6 D0 CE C4 数据库
JDBC
以下是从数据库中取出数的过程
11 JDBC从数据库中取出字节流D6 D0 CE C4 JDBC
12 JDBC按照数据库的字符集ISO8859-1生成字符串,并提交
给Servlet
00 D6 00 D0 00 CE 00
C4 (Unicode)
13 Servlet获得字符串00 D6 00 D0 00 CE 00
C4 (Unicode)
Servlet
14 编程者必须根据数据库的内码ISO8859-1还原成原始字节

D6 D0 CE C4
15 编程者必须根据客户端字符集GB2312生成新的字符串4E 2D 65 87
(Unicode)
Servlet准备把字符串输出到客户端
16 Servlet根据<Servlet-charset>生成字节流D6D0 CE C4
17 Servlet把字节流输出到IE中,如果已指定<Servlet-charset
>,还会设置IE的编码为<Servlet-charset>
D6 D0 CE C4
Servlet
18 IE根据指定的编码或默认编码查看结果“中文”(正确显示) IE
解释一下,表中第4第5步和第15第16步是用红色标记的,表示要由编码者来作转
换。第4、5两步其实就是一句话:“new String(source.getBytes("GB2312"), "ISO8859-1")”。第
15、16两步也是一句话:“new String(source.getBytes("ISO8859-1"), "GB2312")”。亲爱的读
者,你在这样编写代码时是否意识到了其中的每一个细节呢?
至于客户端内码和数据库内码为其它值时的流程,和输出对象是系统控制台时的流程,
请读者自己想吧。明白了上述流程的原理,相信你可以轻松地写出来。
行文至此,已可告一段落了。终点又回到了起点,对于编程者而言,几乎是什么影响都
没有。
因为我们早就被告之要这么做了。
以下给出一个结论,作为结尾。
1、 在Jsp文件中,要指定contentType,其中,charset的值要与客户端浏览器所用的字
符集一样;对于其中的字符串常量,不需做任何内码转换;对于字符串变量,要求能根据
ContentType中指定的字符集还原成客户端能识别的字节流,简单地说,就是“字符串变量
是基于<Jsp-charset>字符集的”;
2、 在Servlet中,必须用HttpServletResponse.setContentType()设置charset,且设置成
与客户端内码一致;对于其中的字符串常量,需要在Javac编译时指定encoding,这个
encoding必须与编写源文件的平台的字符集一样,一般说来都是GB2312或GBK;对于字
符串变量,与JSP一样,必须“是基于<Servlet-charset>字符集的”。</jsp-charset></jsp-charset></compile-charset></servlet-charset></servlet-charset></servlet-charset></compile-charset></servlet-charset></compile-charset></jsp-charset></servlet-charset></compile-charset></jsp-charset></servlet-charset></jsp-charset></compile-charset></compile-charset></jsp-charset></jsp-charset></jsp-charset></jsp-charset>
分享到:
评论
1 楼 marks525 2011-04-06  
很详细,谢谢

相关推荐

    基于Python的天气预测与可视化(完整源码+说明文档+数据)

    基于Python的天气预测与可视化(完整源码+说明文档+数据),个人经导师指导并认可通过的高分设计项目,评审分99分,代码完整确保可以运行,小白也可以亲自搞定,主要针对计算机相关专业的正在做大作业的学生和需要项目实战练习的学习者,可作为毕业设计、课程设计、期末大作业,代码资料完整,下载可用。 基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基于Python的天气预测与可视化(完整源码+说明文档+数据)基

    超表面设计中MIM结构的FDTD仿真:基于磁偶极子共振的高效光束偏折实现

    内容概要:本文详细介绍了利用MIM(金属-介质-金属)结构进行梯度相位超表面的设计与仿真的全过程。首先,通过Au-MgF2-Au三明治结构,利用磁偶极子共振实现高效的相位控制。接着,通过FDTD仿真工具,编写参数扫描脚本来优化纳米柱尺寸,从而实现广泛的相位覆盖。然后,通过近远场变换计算异常反射效率,验证了高达85%以上的反射效率。此外,还探讨了宽带性能验证的方法以及梯度相位阵列的设计思路。最后,提供了实用的代码片段和注意事项,帮助读者理解和复现实验结果。 适合人群:从事超表面研究、光束控制、电磁仿真领域的科研人员和技术开发者。 使用场景及目标:适用于希望深入了解MIM结构在超表面设计中的应用,掌握FDTD仿真技巧,以及探索高效光束偏折机制的研究人员。目标是通过详细的步骤指导,使读者能够成功复现并优化类似实验。 其他说明:文章不仅提供了理论背景,还包括大量具体的代码实现和实践经验分享,有助于读者更好地理解和应用所学知识。

    基于主从博弈的MATLAB实现:共享储能与综合能源微网优化运行

    内容概要:本文探讨了利用主从博弈理论解决共享储能与综合能源微网之间的利益冲突。通过MATLAB和YALMIP+Cplex工具,构建了微网运营商、用户聚合商和共享储能服务商三者之间的博弈模型。主要内容包括系统架构介绍、核心代码解析、求解策略以及仿真结果分析。文中详细展示了如何通过Stackelberg模型实现三方利益的最大化,并提供了完整的代码实现和详细的注释。 适合人群:从事能源互联网项目的研发人员、对博弈论及其应用感兴趣的学者和技术爱好者。 使用场景及目标:适用于希望深入了解能源系统优化、主从博弈理论及其MATLAB实现的研究人员和工程师。目标是掌握如何通过编程手段解决复杂系统中的多主体利益协调问题。 其他说明:文章不仅介绍了理论背景,还提供了具体的代码实现细节,如参数初始化、目标函数构建、约束条件处理等。此外,还包括了仿真结果的可视化展示,帮助读者更好地理解模型的实际效果。

    FPGA图像处理领域的直方图统计与均衡化技术及其Matlab验证

    内容概要:本文深入探讨了基于FPGA平台实现直方图统计与均衡化的全过程,涵盖直方图统计、累积直方图计算和均衡化处理三大核心步骤。文中不仅提供了详细的Verilog代码实现,还介绍了关键的设计思路和技术难点,如双端口BRAM的应用、流水线控制、除法器资源优化等。此外,通过Matlab代码进行了结果验证,确保FPGA实现的准确性。 适合人群:从事FPGA开发、图像处理、计算机视觉等相关领域的工程师和技术爱好者。 使用场景及目标:适用于需要高性能、低延迟图像处理的应用场景,如实时视频处理、医学图像处理、卫星图像增强等。目标是掌握FPGA实现直方图均衡化的技术细节,提高图像对比度和清晰度。 其他说明:文章强调了FPGA相较于CPU和GPU在并行处理和硬件加速方面的优势,并提供了丰富的代码实例和测试结果,帮助读者更好地理解和应用这一技术。

    基于LSTM的高速公路车辆换道轨迹预测:数据处理、模型设计与性能评估

    内容概要:本文详细介绍了利用LSTM模型进行高速公路车辆换道轨迹预测的研究过程。首先,作者使用来自I-80和US-101高速公路的实际换道轨迹数据,这些数据包括横向和纵向的速度、加速度以及轨迹坐标等特征。通过对数据进行预处理,如标准化、划分训练集和测试集等步骤,确保了数据的质量。然后,设计并实现了包含两层LSTM和一层全连接层的神经网络模型,采用Adam优化器进行训练,并通过交叉熵损失函数评估模型性能。实验结果显示,模型在测试集上的准确率达到85%,表明LSTM模型能够有效捕捉车辆换道的行为模式。 适合人群:从事自动驾驶技术研发的专业人士,尤其是对深度学习应用于交通预测感兴趣的工程师和技术研究人员。 使用场景及目标:本研究旨在提高自动驾驶系统的安全性与效率,具体应用场景包括但不限于城市快速路、高速公路等复杂路况下车辆换道行为的提前预测,从而辅助驾驶员或自动驾驶系统做出更好的决策。 其他说明:尽管目前模型已经取得了较好的成绩,但仍存在改进空间,例如可以通过引入更多类型的传感器数据(如摄像头图像)、优化现有模型结构等方式进一步提升预测精度。此外,考虑到实际应用中的实时性和鲁棒性要求,后续还需针对硬件平台进行针对性优化。

    个人资料-1111相关内容

    个人资料-111相关内容

    汽车碰撞仿真CAE:基于HyperWorks与LS-DYNA的全流程解析及实战技巧

    内容概要:本文详细介绍了使用HyperWorks和LS-DYNA进行汽车碰撞仿真的方法和技术要点。从网格划分、材料属性设置、连接装配到最后的分析计算和结果处理,每个环节都配有具体的代码示例和注意事项。文中不仅涵盖了正碰、侧碰、偏置碰等多种类型的碰撞分析,还包括了座椅安全带约束等特殊部件的建模技巧。此外,作者分享了许多实践经验,如网格尺寸的选择、材料参数的设定以及求解器设置的最佳实践,帮助读者避免常见的陷阱并提高仿真效率。 适合人群:从事汽车工程领域的工程师、研究人员以及对汽车碰撞仿真感兴趣的初学者。 使用场景及目标:适用于需要掌握汽车碰撞仿真完整流程的专业人士,旨在提升其在实际项目中的应用能力,确保仿真结果的准确性和可靠性。 其他说明:附赠的源代码进一步增强了学习效果,使读者能够快速上手并在实践中不断优化自己的技能。

    MATLAB/Simulink中四分之一车被动悬架双质量模型的构建与分析

    内容概要:本文详细介绍了如何在MATLAB/Simulink环境中搭建四分之一车被动悬架双质量(二自由度)模型。该模型主要用于研究车辆悬架系统在垂直方向上的动态特性,特别是面对路面不平度时的表现。文中不仅提供了具体的建模步骤,包括输入模块、模型主体搭建和输出模块的设计,还给出了详细的参数配置方法和仿真分析技巧。此外,文章还探讨了如何通过调整悬架系统的参数(如阻尼系数)来优化车辆的乘坐舒适性和行驶安全性。 适合人群:从事汽车动力学研究的专业人士、高校相关专业的学生以及对车辆悬架系统感兴趣的工程师。 使用场景及目标:①用于教学目的,帮助学生理解车辆悬架系统的理论知识;②用于科研实验,验证不同的悬架设计方案;③为企业产品研发提供技术支持,改进现有产品的性能。 其他说明:文中提供的代码片段和建模思路有助于读者快速上手并掌握Simulink建模技能。同时,强调了实际应用中的注意事项,如选择合适的求解器、处理代数环等问题。

    MATLAB实现语音数据特征提取与分类全流程解析

    内容概要:本文详细介绍了使用MATLAB进行语音数据处理的完整流程,涵盖从音频文件读取、特征提取(特别是梅尔倒谱系数MFCC)、分类器构建(支持向量机SVM)到最后的性能评估(混淆矩阵)。作者分享了许多实用技巧,如避免常见错误、优化特征提取参数以及提高分类准确性的方法。文中提供了大量具体代码示例,帮助读者快速理解和应用相关技术。 适合人群:对语音信号处理感兴趣的初学者或有一定经验的研究人员和技术爱好者。 使用场景及目标:适用于希望深入了解语音识别系统内部机制的人群,尤其是希望通过MATLAB平台实现简单而有效的语音分类任务的学习者。主要目的是掌握如何利用MATLAB工具箱完成从原始音频到分类结果可视化的全过程。 其他说明:除了介绍基本概念外,还强调了一些实践经验,例如预处理步骤的重要性、选择合适的滤波器数目、尝试不同的分类器配置等。此外,作者鼓励读者根据实际情况调整参数设置,以获得更好的实验效果。

    基于python+yolov5和deepsort实现的行人或车辆跟踪计数系统+源码+项目文档+演示视频(毕业设计&课程设计&项目开发)

    基于python+yolov5和deepsort实现的行人或车辆跟踪计数系统+源码+项目文档+演示视频,适合毕业设计、课程设计、项目开发。项目源码已经过严格测试,可以放心参考并在此基础上延申使用,详情见md文档 项目运行环境:win10,pycharm,python3.6+ 主要需要的包:pytorch >= 1.7.0,opencv 运行main.py即可开始追踪检测,可以在控制台运行 基于python+yolov5和deepsort实现的行人或车辆跟踪计数系统+源码+项目文档+演示视频,适合毕业设计、课程设计、项目开发。项目源码已经过严格测试,可以放心参考并在此基础上延申使用,详情见md文档 项目运行环境:win10,pycharm,python3.6+ 主要需要的包:pytorch >= 1.7.0,opencv 运行main.py即可开始追踪检测,可以在控制台运行~

    超表面全息技术中MIM结构的高效几何相位与FDTD仿真解析

    内容概要:本文详细介绍了金-氟化镁-金(MIM)结构在超表面全息领域的应用及其高效性能。首先探讨了MIM结构中磁偶极子模式的优势,特别是其低辐射损耗的特点。接着讨论了几何相位的应用,展示了纳米柱旋转角度与相位延迟之间的线性关系,并解决了相位误差的问题。随后介绍了改进的GS算法,提高了迭代收敛速度。最后,通过FDTD仿真验证了MIM结构的高效率,提供了详细的仿真参数设置和优化技巧。 适合人群:从事超表面研究、光学工程、纳米技术和FDTD仿真的研究人员和技术人员。 使用场景及目标:适用于希望深入了解MIM结构在超表面全息中的应用,以及希望通过FDTD仿真进行相关研究的专业人士。目标是提高超表面全息的转换效率,探索新的应用场景如涡旋光生成和偏振加密全息。 其他说明:文中提供了大量具体的代码片段和参数设置,帮助读者更好地理解和复现实验结果。此外,还提到了一些常见的仿真陷阱和解决方案,有助于避免常见错误并提升仿真准确性。

    【金融科技领域】信用飞利用大数据与AI实现用户信用成长及资产增值:个性化金融解决方案设计

    内容概要:文章介绍了金融科技公司信用飞如何通过关注用户信用成长,利用先进技术和专业服务为用户量身定制金融解决方案,从而实现用户资产的稳健增值。首先,信用飞通过多维度数据分析,全面了解用户的信用状况和需求,为不同信用水平的用户提供个性化服务。其次,建立了动态信用评估体系,实时监测并调整用户信用服务策略,帮助用户持续提升信用。再者,根据不同用户的需求,提供包括信用消费、理财投资、融资借贷等在内的多样化金融服务。最后,借助大数据、人工智能、区块链等技术手段,确保金融服务的安全可靠和高效便捷,持续陪伴用户实现信用与财富的双重增长。 适合人群:对个人信用管理有一定需求,希望通过科学金融规划实现资产稳健增值的个人及小微企业主。 使用场景及目标:①希望提升个人或企业信用评级的用户;②寻求合适金融产品和服务以优化财务管理的人群;③需要安全可靠的融资渠道支持业务发展的创业者和中小企业。 阅读建议:本文详细阐述了信用飞如何通过技术创新和个性化服务助力用户信用成长及资产增值,建议读者重点关注文中提到的技术应用和服务特色,结合自身情况思考如何更好地利用此类金融科技服务来优化个人或企业的财务状况。

    少儿编程scratch项目源代码文件案例素材-AI战争.zip

    少儿编程scratch项目源代码文件案例素材-AI战争.zip

    工业自动化中出口设备1200线体程序的PLC通讯与V90-FB284协同控制开源指南

    内容概要:本文详细介绍了出口设备1200线体程序的配置与优化方法,涵盖PLC通讯控制、V90模块配置以及工艺对象与FB284的协同控制。文章强调了开源特性的优势,使得用户可以自由扩展和优化控制系统。主要内容包括:1) 出口设备1200线体程序的核心地位及其复杂控制逻辑;2) 多个PLC设备的通讯协作,确保数据可靠传输;3) V90模块的具体配置步骤,确保各模块稳定运行;4) 工艺对象与FB284的协同控制,避免逻辑冲突;5) 开源带来的便利性,便于用户进行功能扩展和学习;6) 实际应用中的优化措施,提高系统的运行效率。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是那些希望深入了解PLC通讯控制和V90伺服配置的人。 使用场景及目标:适用于需要配置和优化出口设备1200线体程序的实际工程项目,帮助用户掌握PLC通讯、V90配置及工艺对象与FB284协同控制的方法,从而提升生产线的效率和稳定性。 其他说明:文章提供了大量实用的代码片段和调试技巧,有助于读者更好地理解和实施相关配置。同时,文中提到的一些具体案例和经验分享也为实际操作提供了宝贵的参考。

    前端面试与vue源码讲解

    前端面试与vue源码讲解

    少儿编程scratch项目源代码文件案例素材-green vs blue.zip

    少儿编程scratch项目源代码文件案例素材-green vs blue.zip

    博世汽车电驱仿真模型:同步与异步电机FOC控制及弱磁优化

    内容概要:本文详细介绍了博世汽车电驱仿真模型中同步电机和异步电机的FOC(磁场定向控制)技术及其优化方法。主要内容涵盖相电流波形生成、弱磁控制、正反转切换、滑差补偿以及铁损计算等方面的技术细节。通过MATLAB、Python和C等多种编程语言实现了对电机控制的精确模拟,展示了如何通过数学方法和智能算法提高电机性能,减少电流畸变和转矩脉动。文中特别强调了弱磁控制在高速区的应用,通过动态查表法自动调整d轴电流分量,有效解决了电压极限椭圆的问题。此外,还提到了一些创新性的技术应用,如相位预判机制、动态滑差补偿和自适应耦合系数计算等。 适合人群:从事电机控制、电动汽车研究及相关领域的工程师和技术人员。 使用场景及目标:适用于希望深入了解同步电机和异步电机FOC控制原理及其实现方法的研究人员和工程师。目标是掌握先进的电机控制技术和优化方法,应用于实际项目中,提高系统性能和可靠性。 其他说明:文章不仅提供了详细的理论解释,还附有具体的代码实现,便于读者理解和实践。同时,文中提到的一些创新性技术可以为相关领域的研究提供新的思路和方法。

    少儿编程scratch项目源代码文件案例素材-RPG游戏引擎5.5c.zip

    少儿编程scratch项目源代码文件案例素材-RPG游戏引擎5.5c.zip

    2025年6G近场技术白皮书2.0.pdf

    2025年6G近场技术白皮书2.0.pdf

    少儿编程scratch项目源代码文件案例素材-scratch 通关游戏.zip

    少儿编程scratch项目源代码文件案例素材-scratch 通关游戏.zip

Global site tag (gtag.js) - Google Analytics