JSP中国語文字化けしの研究
5748 ワード
Javaのカーネルとclassファイルはunicodeに基づいており、Javaプログラムはプラットフォーム間で良好な機能を持っているが、中国語の文字化けし問題のトラブルをもたらしている.理由は主に2つの側面があり,JavaとJSPファイル自体のコンパイル時に発生する文字化けし問題とJavaプログラムが他のメディアで対話して発生する文字化けし問題である. まずJava(JSPを含む)のソースファイルには中国語が含まれている可能性が高いが、JavaとJSPのソースファイルの保存方式はバイトストリームに基づいており、JavaとJSPがclassファイルにコンパイルされる過程で使用される符号化方式がソースファイルの符号化と一致しないと、文字化けが発生する.JSPでは、ファイルヘッダに加えたり、基本的にこのような文字化けし問題を解決することができます. 私たちのこの文章は主にJSPページのTomcatへの導入に関する研究です.
まずIDEを開きます.ここではEclipseを使用しています.まずwebプロジェクトTestを新規作成し、次にJSPページを新規作成します.
ここで注意したいのは、JSPページは保存時にも符号化されていて、EclipseなどのIDEにファイル符号化を専門に設定する構成があるので、ここではあまり言わないことです.ここではJSPファイルはutf-8で保存するのがデフォルトです.
その後、プロジェクトをTomcatに配置し、http://localhost:8080/Test/ index.jspにアクセスすると、ページ(index.jsp)が文字化けして表示されます.
JSPをTomcatに配備して実行すると、JSPは2回の「コード」を経て、第1段階はpageEncoding、第2段階はutf-8からutf-8、第3段階はTomcatから出たページでcontentTypeを使用します.
第1段階はjspが.javaにコンパイルされ、pageEncodingの設定に従ってjspが読み出され、その結果、指定された符号化スキームによって統一されたUTF-8 JAVAソース(すなわち.java)に翻訳される.
第2段階はJAVACのJAVAソースから.classへのコンパイルであり、JSP作成時にどのような符号化スキームを用いたかにかかわらず、この段階を経た結果はすべてUTF-8のencodingのjavaソースである.
JAVACはUTF-8のencodingでjavaソースコードを読み出し、UTF-8 encodingのバイナリコード(すなわち.class)にコンパイルする.これはJVM対定数文字列がバイナリコード(java encoding)内で表現される仕様である.
第3段階はTomcat(またはそのアプリケーションcontainer)が段階2のJAVAバイナリコードを読み込み実行し、出力した結果、つまりクライアントで見たものであり、このときパラメータcontentTypeが機能する.
ここでは、上記の3つの段階について詳しく説明します.
第1段階はjspから.javaにコンパイルされ、ソースJspページをメモリに読み込み、サーブレットクラスファイルを何らかの符号化で生成する必要があります.この読み取りの過程は、どのような符号化方式で読み取るかの問題に関連しますか?ページに設定されているように PageEncoding="XX"では、サーバはJspページを読み込む際に、上に設定したXXを使用して読み取り、設定していない場合はcontentType="text/html;charset=XXX"が設定されているかどうかを見て、設定した場合はcharsetで指定した符号化方式で読み取ります.どちらも指定されていない場合は、デフォルトの符号化方式ISO 8859-1で読み出し、Jspページをメモリに読み込んだ後、メモリにUnicode符号化で存在し、UTF-8符号化方式で出力される.javaファイルである.
次のコードで検証します.
上記のコードを実行するとindex.javaファイルが生成されます.その後、Tomcatの本物の.javaファイルと比較します.このファイルの場所は%TOMCAT_です.HOME%workCatalinalocalhostTestorgapachejspの下で、開くと中の漢字の文字化けしが同じであることがわかります.今、最初の段階の大まかな過程と、その中の符号化の変換がわかります.
第2段階では、JAVAソースから.classへのコンパイルプロセスであり、UTF-8からUTF-8を採用しているため、変換後も符号化フォーマットは変化しません.
第3段階では、ここで<%@page contentType="text/html;charset=iso 8859-1"%>を使用します.このとき、第2段階で生成されたservletバイトコードを見ると、 response.setContentType("text/html;charset=iso8859-1");この言葉は
<%@page contentType="text/html;charset=iso 8859-1"%>がservletバイトコードにコンパイルされた様子.ユーザーのブラウザはJSP対応のサーブレットを要求して、Webコンテナは1つのスレッドからサーブレットを実行して、データをクライアントのブラウザに返して、iso 8859-1で表示して、以上の過程は以下のコードと類似しています:
以上はjspページの表示の全体の過程で、個人がネット上の資料を参照する個人の体得だけで、もし間違いがあれば、みんなに指摘して、ありがとうございます!
まずIDEを開きます.ここではEclipseを使用しています.まずwebプロジェクトTestを新規作成し、次にJSPページを新規作成します.
<%@ page language="java" pageEncoding="gbk"%>
<%@ page contentType="text/html;charset=iso8859-1"%>
<html>
<head>
<title>JSP</title>
<meta http-equiv="Content-Type" content="text/html charset=gb2312"/>
</head>
<body>
JSP
</body>
</html>ここで注意したいのは、JSPページは保存時にも符号化されていて、EclipseなどのIDEにファイル符号化を専門に設定する構成があるので、ここではあまり言わないことです.ここではJSPファイルはutf-8で保存するのがデフォルトです.
その後、プロジェクトをTomcatに配置し、http://localhost:8080/Test/ index.jspにアクセスすると、ページ(index.jsp)が文字化けして表示されます.
JSPをTomcatに配備して実行すると、JSPは2回の「コード」を経て、第1段階はpageEncoding、第2段階はutf-8からutf-8、第3段階はTomcatから出たページでcontentTypeを使用します.
第1段階はjspが.javaにコンパイルされ、pageEncodingの設定に従ってjspが読み出され、その結果、指定された符号化スキームによって統一されたUTF-8 JAVAソース(すなわち.java)に翻訳される.
第2段階はJAVACのJAVAソースから.classへのコンパイルであり、JSP作成時にどのような符号化スキームを用いたかにかかわらず、この段階を経た結果はすべてUTF-8のencodingのjavaソースである.
JAVACはUTF-8のencodingでjavaソースコードを読み出し、UTF-8 encodingのバイナリコード(すなわち.class)にコンパイルする.これはJVM対定数文字列がバイナリコード(java encoding)内で表現される仕様である.
第3段階はTomcat(またはそのアプリケーションcontainer)が段階2のJAVAバイナリコードを読み込み実行し、出力した結果、つまりクライアントで見たものであり、このときパラメータcontentTypeが機能する.
ここでは、上記の3つの段階について詳しく説明します.
第1段階はjspから.javaにコンパイルされ、ソースJspページをメモリに読み込み、サーブレットクラスファイルを何らかの符号化で生成する必要があります.この読み取りの過程は、どのような符号化方式で読み取るかの問題に関連しますか?ページに設定されているように PageEncoding="XX"では、サーバはJspページを読み込む際に、上に設定したXXを使用して読み取り、設定していない場合はcontentType="text/html;charset=XXX"が設定されているかどうかを見て、設定した場合はcharsetで指定した符号化方式で読み取ります.どちらも指定されていない場合は、デフォルトの符号化方式ISO 8859-1で読み出し、Jspページをメモリに読み込んだ後、メモリにUnicode符号化で存在し、UTF-8符号化方式で出力される.javaファイルである.
次のコードで検証します.
String fileName = "D:/Program Files/DevelopMent/Apache Software Foundation/Tomcat 6.0/webapps/ServletTest/index.jsp"; //JSP Tomcat
PrintWriter pw = new PrintWriter(new OutputStreamWriter(new FileOutputStream("d:/index.java"), "UTF-8"));
BufferedReader br = new BufferedReader(new InputStreamReader(
new FileInputStream(fileName), "gbk"));//jap utf-8 ， gbk
String readContent = null;
while ((readContent = br.readLine()) != null) {
pw.write(readContent+"/r/n");
pw.flush();
}
pw.close(); 上記のコードを実行するとindex.javaファイルが生成されます.その後、Tomcatの本物の.javaファイルと比較します.このファイルの場所は%TOMCAT_です.HOME%workCatalinalocalhostTestorgapachejspの下で、開くと中の漢字の文字化けしが同じであることがわかります.今、最初の段階の大まかな過程と、その中の符号化の変換がわかります.
第2段階では、JAVAソースから.classへのコンパイルプロセスであり、UTF-8からUTF-8を採用しているため、変換後も符号化フォーマットは変化しません.
第3段階では、ここで<%@page contentType="text/html;charset=iso 8859-1"%>を使用します.このとき、第2段階で生成されたservletバイトコードを見ると、 response.setContentType("text/html;charset=iso8859-1");この言葉は
<%@page contentType="text/html;charset=iso 8859-1"%>がservletバイトコードにコンパイルされた様子.ユーザーのブラウザはJSP対応のサーブレットを要求して、Webコンテナは1つのスレッドからサーブレットを実行して、データをクライアントのブラウザに返して、iso 8859-1で表示して、以上の過程は以下のコードと類似しています:
String fileName = "d:/index.java"; //
PrintWriter pw = new PrintWriter(new OutputStreamWriter(new FileOutputStream("d:/index1.java"), "iso8859-1"));
BufferedReader br = new BufferedReader(new InputStreamReader(
new FileInputStream(fileName), "utf-8"));
String readContent = null;
while ((readContent = br.readLine()) != null) {
pw.write(readContent+"/r/n");
pw.flush();
}
pw.close(); 以上はjspページの表示の全体の過程で、個人がネット上の資料を参照する個人の体得だけで、もし間違いがあれば、みんなに指摘して、ありがとうございます!