jsp Chinese problem solution (full version)

===================================
It is very common for garbled characters to appear when developing Java applications. After all, Unicode is not widely used now. In a system using gb2312 (including gbk simplified and big5 traditional),

it is the most basic requirement to correctly implement Chinese display and database storage. .

==============================
1. First, the developer must understand why he encounters garbled code and what kind of garbled code he encounters (meaningless symbols, a string of question marks, or something else).
Novices are usually at a loss when they encounter a bunch of messy characters. The most direct reaction is to open Google and search for "java Chinese" (this string is frequently queried on search engines),

and then look at other people's characters one by one. Solution. There is nothing wrong with doing this, but it is difficult to achieve the goal, for the reasons mentioned below.
In short, there are many reasons for garbled characters, and the solutions are completely different. To solve the problem, you must first analyze your own "context".

============================
2. Specifically, what information is needed to determine the source of the garbled code in the project.
a. The operating system used by the developer
b, the name and version of the j2ee container
c, database name, version (exact version) and jdbc driver version
d. There is garbled source code (for example, it comes from system out, or it is in a jsp page. If it is in a jsp, the header declaration is also very important)

============= ==============================================
3. How to initially analyze the causes of garbled characters.
With the above information, you can basically post for help. I believe if you put it on forums such as Javaworld, experts will soon come up with effective solutions for you.
Of course, you can’t always rely on posting for help, but you should also try to solve the problem yourself. How to start?
a. Analyze what encoding your "garbled code" is. This is actually not difficult, for example
System.out.println(testString);
There is garbled code in this paragraph, so you might as well use the exhaustive method to guess its actual encoding format.
System.out.println(new String(testString.getBytes(”ISO-8859-1″),”gb2312″));
System.out.println(new String(testString.getBytes(”UTF8″),”gb2312″));
System.out.println(new String(testString.getBytes(”GB2312″),”gb2312″));
System.out.println(new String(testString.getBytes("GBK"),"gb2312"));
System.out.println(new String(testString.getBytes("BIG5"),"gb2312"));
Wait, the above code means to use the specified encoding format to read the "garbled code" of testString and convert it into gb2312 (only Chinese is used as an example here)
Then you see which converted result is ok, that's it. . .

b. If you can get the correct Chinese using the above steps, it means that your data is definitely there, but it is just not displayed correctly in the interface. Then the second step is to correct your view part

. What usually needs to be checked is whether the correct page encoding is selected in the jsp.

I would like to point out something that has been misunderstood by many people, that is the <%@ page contentType="text/html; charset=GB2312″ %> directive and <META http-equiv=Content-Type

content="text/html; charset= gb2312″>The difference between the two. Usually when many articles on the Internet mention Chinese problems, they say that choosing unicode or gb2312 storage in the database can be solved

by using

But I think this statement is very irresponsible, and it caused me to spend a lot of time being depressed about garbled codes that didn't exist in the first place. In fact, the role of page

is to provide a coding method for Java to "read" the String in the expression during the process of JSP being compiled into HTML (somewhat similar to the role of the third statement above), and the

role of meta is well known Provides encoding options for IE browsers, which are used to "display" the final data. But I haven’t seen anyone remind me of this. I have always used page as meta,

which resulted in the data that was originally iso-8859 being read as gb2312 by the page command, so it was garbled, so I added a coding conversion function to convert all the string data. They all changed from iso8859 to gb2312 (

why

================================================== =============
4. What encoding is better for the database?
Currently popular DBs mainly include sql server, mysql, oracle, DB2, etc. Among them, mysql is the leader among free DBs. Its performance and functions are recognized. It is relatively convenient to install and configure, and the

corresponding

OK. So take mysql as an example.

I personally recommend using the default encoding of mysql for storage, which is iso-8859-1 (corresponding to latin-1 in the mysql options). There are several main reasons. First, iso-8859-1 has good support for

Chinese

The stability is also better, because multi-encoding

support is provided by specific DB products, not to mention incompatibility with other DBs, even different versions of themselves may have compatibility issues.

For example, in products before mysql 4.0, many Chinese solutions use the characterEncoding field in the connection to set the encoding, such as gb2312 or something. This is OK

because the original data is ISO8859_1 encoded, and the jdbc driver will use the one specified in the url. Character set is used for encoding, and resultSet.getString(*) takes out the encoded

string. In this way, you can directly get the data of gb2312.

However, the launch of mysql 4.1 has brought a lot of trouble to many dbadmins, because mysql 4.1 supports column level character set. Each table and column can specify the encoding

. If not specified, it will be ISO8895_1, so after jdbc takes out the data, it will be based on the column. The character set is used for encoding, instead of using a global parameter to get all the data.

This also shows from another aspect that the problem of garbled characters is really complicated and has too many reasons. I just provide some solutions to the actual situation I encountered. If there are any

mistakes

Internel Use Only.
Any Question,please reffer to [email protected]
================================================== ==============

Finally found the most perfect solution to the Chinese problem. . . Thank you to the author of this article online. . .
My original article is based on my own experience. Although there was nothing wrong, the final root cause of the problem was never found. After reading this article, I suddenly realized, haha,
—————————————————————————————————————————————— ——————————-

Since the Chinese problem in Java programming is a commonplace problem, after reading many solutions to Java Chinese problems, combined with the author’s programming practice, I found that many of the methods discussed in the past cannot Clearly explain the problem and solve the problem, especially the Chinese problem when cross-platform.
So I gave this article, which includes my analysis and suggested solutions to Chinese problems in classes, Servelets, JSP and EJB classes running on the console. I hope you can give me some advice.

Abstract: This article deeply analyzes the encoding/decoding process of Java source files by Java compiler and class files by JVM in Java programming. Through the analysis of this process, the root cause of Chinese problems in Java programming is revealed. Finally, it is given The proposed optimal method to solve Java Chinese problems.

1. The source of the Chinese problem

. The encoding supported by the original operating system of the computer was single-byte character encoding. Therefore, all processing programs in the computer were initially processed in English with single-byte encoding.

With the development of computers, in order to adapt to the languages ​​​​of other nations in the world (including of course our Chinese characters), people have proposed UNICODE encoding, which uses double-byte encoding and is compatible with English characters and double-byte character encodings of other nations. Therefore, currently , most international software uses UNICODE encoding internally. When the software is running, it obtains the encoding format supported by default by the local support system (most of the time, the operating system), and then converts the UNICODE within the software into the encoding format supported by the local system by default. The format is displayed.

This is the case for Java's JDK and JVM. The JDK I am talking about here refers to the international version of JDK. Most of our programmers use the internationalized JDK version. All the following JDKs refer to the internationalized JDK version. Our Chinese characters are a double-byte encoding language. In order to allow computers to process Chinese, we have developed our own standards such as gb2312, GBK, and GBK2K to meet the needs of computer processing.

Therefore, in order to adapt to our needs for processing Chinese, most operating systems have customized Chinese operating systems. They use GBK and GB2312 encoding formats to correctly display our Chinese characters. For example: Chinese Windows uses GBK encoding for display by default. When saving files in Chinese Windows 2000, the encoding format used by default to save files is also GBK. That is, the internal encoding of all files saved in Chinese Windows 2000 uses GBK encoding by default. Note: GBK is expanded on the basis of GB2312.

Since the Java language uses UNICODE encoding internally, when the Java program is running, there is a problem of converting input and output from UNICODE encoding and the corresponding encoding format supported by the operating system and browser. This conversion process has a series of steps. If there is an error in any of the steps, the displayed Chinese characters will be garbled. This is our common Java Chinese problem.

At the same time, Java is a cross-platform programming language, which means that the programs we write can not only run on Chinese windows, but also on Chinese Linux and other systems. It is also required to run on English and other systems (we often see Someone transplanted a Java program written on Chinese Windows 2000 to run on English Linux). This transplant operation will also bring Chinese problems.

Also, some people use English operating systems and English browsers such as IE to run programs with Chinese characters and browse Chinese web pages. They do not support Chinese themselves and will also cause Chinese problems.

Almost all browsers pass parameters in UTF-8 encoding format by default instead of Chinese encoding. Therefore, there will also be problems when passing Chinese parameters, resulting in garbled characters.

In short, the above aspects are the main sources of Chinese problems in Java. We call the problems caused by the program not running correctly due to the above reasons: Java Chinese problems.

2. Detailed process of Java encoding conversion.

Our common Java programs include the following categories:

*Classes that run directly on the console (including visual interface classes)

*JSP code classes (Note: JSP is a variant of the Servlets class)

*Servelets class

* EJB class

* other support classes that cannot be run directly.

These class files may contain Chinese strings, and we often use the first three types of Java programs to directly interact with users for output and input characters, such as: we use JSP and The Servlet gets the characters sent by the client, and these characters also include Chinese characters. Regardless of the role of these Java classes, the life cycle of these Java programs is like this:

*Programmers choose a suitable editing software on a certain operating system to implement the source program code and save it in the operating system with the .Java extension. , for example, we use Notepad to edit a Java source program in Chinese Windows 2000.

*Programmers use Javac.exe in JDK to compile these source codes to form .class classes (JSP files are compiled by the container calling JDK).

*Run these classes directly or deploy these classes to the WEB container to run and output the results.

So, during these processes, how do the JDK and JVM encode, decode and run these files?

Here, we take the Chinese Windows 2000 operating system as an example to illustrate how Java classes are encoded and decoded.

The first step is to use editing software such as Notepad to write a Java source program file (including the above five types of Java programs) in Chinese Windows 2000. When saving the program file, the program file uses the GBK encoding format supported by the operating system by default (supported by the operating system by default). The format is file.encoding format) forming a .Java file, that is, before the Java program is compiled, our Java source program file is saved in the file.encoding encoding format supported by the operating system by default. In the Java source program Contains Chinese information characters and English program codes; to view the system's file.encoding parameter, you can use the following code:

public class ShowSystemDefaultEncoding
{
public static void main(String[] args)
{
String encoding =
System.getProperty("file.encoding");
System.out.println(encoding);
}
}

In the second step, we use the Javac.exe file of JDK to compile our Java source program. Since JDK is an international version, when compiling, if we do not use the -encoding parameter to specify the encoding format of our Java source program, then Javac.exe first obtains the encoding format used by our operating system by default. That is, when compiling a Java program, if we do not specify the encoding format of the source program file, JDK first obtains the file.encoding parameter of the operating system (which saves the The default encoding format, such as Windows2000, its value is GBK), and then JDK converts our Java source program from the file.encoding encoding format to Java's internal default UNICODE format and puts it into memory.

Then, Javac compiles the converted unicode format file into a .class class file. At this time, the .class file is UNICODE encoded, and it is temporarily placed in the memory. Then, JDK compiles the compiled class in UNICODE encoding. The file is saved to our operating system to form the .class file we see.

For us, the .class file we finally obtained is a class file whose content is saved in UNICODE encoding format. It contains the Chinese string in our source program, but at this time it has been converted to UNICODE format through file.encoding format. .

In this step, the JSP source program file is different. For JSP, the process is like this: that is, the WEB container calls the JSP compiler. The JSP compiler first checks whether the file encoding format is set in the JSP file. If there is no file encoding format in the JSP file, To set the encoding format of the JSP file, the JSP compiler calls JDK to first convert the JSP file into a temporary Servlet class using the JVM's default character encoding format (that is, the default file.encoding of the operating system where the WEB container is located), and then It is compiled into a UNICODE format class and saved in a temporary folder.

For example: On Chinese Windows 2000, the WEB container converts the JSP file from the GBK encoding format to the UNICODE format, and then compiles it into a temporarily saved Servlet class to respond to the user's request.

The third step is to run the class compiled in the second step, which is divided into three situations:
A. Classes that run directly on the console

B. EJB classes and support classes that cannot be run directly (such as JavaBean classes)

C. JSP code and Servlet classes

D. Between Java programs and databases

Let's look at these four situations below .

A. In the case of a class that runs directly on the console

, running this class first requires JVM support, that is, JRE must be installed in the operating system. The running process is like this: First, Java starts the JVM. At this time, the JVM reads out the class file saved in the operating system and reads the content into the memory. At this time, the memory is a UNICODE format class, and then the JVM runs it. If at this time If this class needs to receive user input, the class will use the file.encoding encoding format by default to encode the string input by the user and convert it into unicode and save it into memory (the user can set the encoding format of the input stream).

After the program runs, the generated string (UNICODE encoded) is returned to the JVM. Finally, the JRE converts the string into file.encoding format (the user can set the encoding format of the output stream) and passes it to the operating system display interface and outputs it. to the interface. Each of the above conversion steps requires correct encoding format conversion so that garbled characters will not appear in the end. B. EJB classes and support classes that cannot be run directly (such as JavaBean classes)

. Because EJB classes and support classes that cannot be run directly, they generally do not interact directly with users for input and output. They often interact with other classes for input and output. output, so after they are compiled in the second step, they form a class whose content is UNICODE encoding and are saved in the operating system. In the future, as long as the interaction between it and other classes is not lost during the parameter passing process, it will will run correctly.

C.

After the second step of the JSP code and Servlet class, the JSP file is also converted into a Servlets class file, but it does not exist in the classes directory like the standard Servlets. It exists in the temporary directory of the WEB container, so In this step we also look at it as Servlets.

For Servlets, when the client requests it, the WEB container calls its JVM to run the Servlet. First, the JVM reads the Servlet class from the system and loads it into the memory. In the memory is the code of the Servlet class encoded in UNICODE. Then the JVM runs the Servlet class in the memory. If the Servlet is running, it needs to accept characters from the client, such as the values ​​entered in the form and the values ​​passed in the URL. At this time, if the program is not set to accept If the encoding format is used as the parameter, the WEB container will use the ISO-8859-1 encoding format by default to accept the incoming value and convert it into UNICODE format in the JVM and save it in the memory of the WEB container.

After the Servlet is run, it generates output, and the output string is in UNICODE format. Then, the container directly sends the UNICODE format string (such as HTML syntax, user output string, etc.) generated by the Servlet run to the client browser and outputs it to If the user specifies the encoding format for output when sending at this time, it will be output to the browser in the specified encoding format. If not specified, it will be sent to the customer's browser in ISO-8859-1 encoding by default.

D. Between Java program and database

For almost all database JDBC drivers, the default encoding format for transferring data between Java program and database is ISO-8859-1. Therefore, our program is transmitting data to the database. When storing data containing Chinese in the program, JDBC first converts the data in the UNICODE encoding format inside the program into the ISO-8859-1 format, and then passes it to the database. When the database saves the data, it defaults to ISO-8859- 1 save, so this is why the Chinese data we often read out in the database is garbled.

3. Several principles that must be understood when analyzing common Java Chinese problems

. First, after the above detailed analysis, we can clearly see that in the life cycle of any Java program, the key process of encoding conversion is: initially compiled into a class file The transcoding and final transcoding process output to the user.

Secondly, we must understand that the following commonly used encoding formats supported by Java at compile time are:

*ISO-8859-1, 8-bit, the same as 8859_1, ISO-8859-1, ISO_8859_1 and other encodings

*Cp1252, American English encoding , the same as ANSI standard encoding

*UTF-8, the same as unicode encoding

*GB2312, the same as gb2312-80, gb2312-1980 and other encodings

*GBK, the same as MS936, it is an expansion of gb2312 and other encodings, such as Korean, Japanese, Traditional Chinese, etc. . At the same time, we should pay attention to the compatibility relationship between these encodings as follows:

Unicode and UTF-8 encoding have a one-to-one correspondence. GB2312 can be considered a subset of GBK, that is, GBK encoding is expanded on gb2312. At the same time, GBK encoding contains 20902 Chinese characters, and the encoding range is: 0×8140-0xfefe. All characters can be mapped to UNICODE2.0 one-to-one.

Thirdly, for the .Java source program file placed in the operating system, during compilation, we can specify the encoding format of its content, specifically using -encoding. Note: If the source program contains Chinese characters and you use -encoding to specify other encoding characters, an error will obviously occur.

Use -encoding to specify the encoding method of the source file as GBK or gb2312. No matter what system we compile the Java source program containing Chinese characters on, there will be no problem. It will correctly convert Chinese into UNICODE and store it in the class file.

Then, we must be clear that the default character encoding format of almost all WEB containers uses ISO-8859-1 as the default value. At the same time, almost all browsers use UTF-8 by default when passing parameters. way to pass parameters.

Therefore, although our Java source file specifies the correct encoding method at the entry and exit, it is still processed as ISO-8859-1 when running inside the container.

4. Classification of Chinese problems and their recommended optimal solutions.

After understanding the above principles of Java file processing, we can put forward a set of suggested optimal solutions to Chinese character problems. Our goal is: the Java source programs containing Chinese strings or Chinese processing that we edit in the Chinese system can be migrated to any other operating system to run correctly after compilation, or can be compiled in other operating systems. It runs correctly, can correctly pass Chinese and English parameters, and can correctly communicate Chinese and English strings with the database. Our specific idea is to restrict the encoding method to make it correct at the entrance and exit of the Java program transcoding and where the Java program has input and output conversion with the user.

The specific solutions are as follows:

1. For classes that run directly on the console

, in this case, we recommend that when writing a program, if you need to receive input from the user that may contain Chinese or output that may contain Chinese, the program should use Character streams are used to handle input and output. Specifically, the following character-oriented node stream types are applied:

For files: FileReader, FileWrieter,

its byte-oriented node stream types are: FileInputStream, FileOutputStream

For memory (array): CharArrayReader,

CharArrayWriter

node stream types are: ByteArrayInputStream, ByteArrayOutputStream.

Memory (string): StringReader, StringWriter.

Pipes: PipedReader, PipedWriter.

The byte node stream types are: PipedInputStream, PipedOutputStream.

At the same time, the following character-oriented processing streams should be used. Input and output:

BufferedWriter, BufferedReader,

its byte-type processing streams are: BufferedInputeStream, BufferedOutputStream

InputStreamReader, OutputStreamWriter,

its byte-type processing streams are: DataInputStream, DataOutputStream.

InputStreamReader and InputStreamWriter are used to convert the byte stream according to the specified character encoding set. Convert to a character stream, such as:

InputStreamReader in = new InputStreamReader(System.in, "GB2312"); OutputStreamWriter out = new OutputStreamWriter (System.out, "GB2312"); For example: the following sample Java encoding can meet the requirements:

//Read.Java
import Java.io.*;
public class Read
{
public static void main(String[] args)
throwsIOException
{
String str =
"nChinese test, this is the internal hard-coded string "+"ntest english character";
String string = "";
BufferedReader stdin =
new BufferedReader(new
InputStreamReader(System.in,”gb2312″));
//Set the input interface to be encoded in Chinese
BufferedWriter stdout =
new BufferedWriter(new
OutputStreamWriter(System.out,”gb2312″));
//Set the output interface to be encoded in Chinese
stdout.write("Please enter:");
stdout.flush();
strin = stdin.readLine();
stdout.write("This is the string input from the user:"+strin);
stdout.write(str);
stdout.flush();
}}

At the same time, when compiling the program, we use the following method:

Javac -encoding gb2312 Read.Java

2. For EJB classes and support classes that cannot be run directly (such as the JavaBean class),

because these classes themselves are used by other classes The call does not directly interact with the user, so for this type, our recommended processing method is that the internal program should use character streams to process the Chinese strings inside the program (specifically as in the above section), and at the same time, in When compiling the class, use the -encoding gb2312 parameter to indicate that the source file is encoded in Chinese format.

3. For the Servlet class

, we recommend the following method:

When compiling the source program of the Servlet class, use -encoding to specify the encoding as GBK or GB2312, and use the setContentType("text" of the response object in the encoding part when outputting to the user /html;charset=GBK”); or gb2312 to set the output encoding format. Similarly when receiving user input, we use request.setCharacterEncoding(”GB2312″); in this way, no matter what operating system our servlet class is transplanted to, only the client If your browser supports Chinese display, it will be displayed correctly. Here is a correct example:

//HelloWorld.Java
package hello;
import Java.io.*;
import Javax.servlet.*;
import Javax.servlet.http.*;
public class HelloWorld
extends HttpServlet
{
public void init()
throws ServletException
{
}
public void doGet
(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Set input encoding format
response.setContentType
("text/html;charset=GB2312");
//Set the output encoding format
PrintWriter out = response.getWriter();
//It is recommended to use PrintWriter output
out.println(”<hr>”);
out.println("Hello World!
This is created by Servlet!Test Chinese!");
out.println(”<hr>”);
}
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Set input encoding format
response.setContentType
("text/html;charset=GB2312");
//Set the output encoding format
String name = request.getParameter("name");
String id = request.getParameter("id");
if(name==null) name="";
if(id==null) id="";
PrintWriter out = response.getWriter();
//It is recommended to use PrintWriter output
out.println(”<hr>”);
out.println("The Chinese string you passed in is: " + name);
out.println("<hr>The id you entered is: " + id);
out.println(”<hr>”);
}
public void destroy()
{
}
}

Please use Javac -encoding gb2312 HelloWorld.Java to compile this program.

The program to test this Servlet is as follows:

< %@page contentType="text/html;
charset=gb2312″%>
<%request.setCharacterEncoding("GB2312");%>
<html><head><title></title>
<Script language="JavaScript">
function Submit()
{
//Pass the Chinese string value to the Servlet through the URL
document.base.action =
"./HelloWorld?name=中文";
document.base.method = “POST”;
document.base.submit();
}
</Script>
</head>

<body bgcolor=”#FFFFFF”
text=”#000000″ topmargin=”5″>
<form name="base" method =
“POST” target=”_self”>
<input name="id" type="text"
value=”” size=”30″>
<a href = “JavaScript:Submit()">
Pass to Servlet</a>
</form></body></html>

4.

In order to avoid garbled data in the data transfer between the Java program and the database, we recommend the following optimal methods to handle it:

1. The Java program should be processed according to the method specified by us.

2. Change the encoding format supported by the database by default to GBK or GB2312.

For example: in mysql, we can add the following statement to the configuration file my.ini to achieve this:

default-character-set=gbk

in the [mysqld] area

and add:

[client]
default-character-set=gbk

In SQL Server2K, we can set the default language of the database to Simplified Chinese to achieve the purpose.

5. For JSP code,

since JSP is dynamically compiled by the WEB container at runtime, if we do not specify the encoding format of the JSP source file, the JSP compiler will obtain the file.encoding value of the server operating system to compile the JSP file. Yes, it is most likely to cause problems when transplanting. For example, a jsp file that can run well in Chinese Windows 2000 will not work in English Linux, even though the clients are the same. That is because the container obtains the JSP file when compiling it. Caused by different encodings of operating systems (file.encoding in Chinese wink is different from file.encoding in English Linux, and file.encoding in English Linux does not support Chinese, so there will be problems with the compiled JSP class ).

Most of the problems discussed on the Internet are such problems, mostly because the JSP file cannot be displayed correctly when transplanted to the platform. For this kind of problem, we understand the principle of program encoding conversion in Java, and it is much easier to solve it. Our suggested solutions are as follows:

1. We must ensure that the JSP is output in Chinese encoding when output to the client, that is, no matter what, we first add the following line to our JSP source code:

< %@page contentType=” text/html;
charset=gb2312″%>

2. In order to allow JSP to correctly obtain the incoming parameters, we add the following sentence to the JSP source file header:

<%request.setCharacterEncoding(”GB2312″);
%>

3. In order for the JSP compiler to correctly decode our JSP files containing Chinese characters, we need to specify the encoding format of our JSP source files in the JSP source files. Specifically, we need to specify the encoding format of our JSP source files in the JSP source file header. Just add the following sentence:

< %@page pageEncoding=”GB2312″%>
Or < %@page pageEncoding="GBK"%>

This is a newly added instruction in JSP specification 2.0.

We recommend using this method to solve Chinese problems in JSP files. The following code is a correct test program for JSP files:

//testchinese.jsp
< %@page pageEncoding=”GB2312″%>
< %@page contentType="text/html;
charset=gb2312″%>
<%request.setCharacterEncoding("GB2312");
%>
<%
String action = request.getParameter("ACTION");
String name = "";
String str = "";
if(action!=null && action.equals("SENT"))
{
name = request.getParameter("name");
str = request.getParameter("str");
}
%>
<html>
<head>
<title></title>
<Script language="JavaScript">
function Submit()
{
document.base.action =
"?ACTION=SENT&str=Incoming Chinese";
document.base.method = “POST”;
document.base.submit();
}
</Script>
</head>
<body bgcolor=”#FFFFFF”
text=”#000000″ topmargin=”5″>
<form name="base" method =
“POST” target=”_self”>
<input type=”text” name=”name”
value=”” size=”30″>
<a href = “JavaScript:Submit()">Submit</a>
</form>
<%
if(action!=null && action.equals("SENT"))
{
out.println("<br>The characters you entered are: "+name);
out.println("<br>The characters you passed in through the URL are: "+str);
}
%>
</body>
</html>