jspのcontentTypeとpageEncodingの違いと役割【jspの文字化けしを解決するのに役立ち、フロントからバックグラウンドまたはバックグラウンドからフロントへ】
2020 ワード
<%@page pageEncoding="utf-8"contentType="text/html;charset=utf-8"%>pageEncodingは、jspファイル自体の符号化contentTypeのcharsetであり、サーバがクライアントに送信する際のコンテンツ符号化である
JSPページのpageEncodingとcontentTypeの2つの属性の違いについて:
PageEncodingはjspファイル自体の符号化です
contentTypeのcharsetとは,サーバがクライアントに送信する際のコンテンツ符号化である.
JSPは2回の「コード」を経て、第1段階はpageEncoding、第2段階はutf-8からutf-8、第3段階はTomcatから出たページでcontentTypeを使う.
第1段階はjspのコンパイルである.JAvaは、pageEncodingの設定に従ってjspを読み出し、その結果、指定された符号化スキームによって統一されたUTF-8 JAVAソースコード(すなわち.java)に翻訳され、pageEncodingの設定が間違っていたり、設定されていなかったりした場合、中国語の文字化けが発生します.
第2段階はJAVACのJAVAソースからjava byteCodeへのコンパイルであり、JSP作成時にどのような符号化スキームを用いたかにかかわらず、この段階を経た結果はすべてUTF-8のencodingのjavaソースである.
JAVACはUTF-8のencodingでjavaソースコードを読み出し、UTF-8 encodingのバイナリコード(すなわち.class)にコンパイルする.これはJVM対定数文字列がバイナリコード(java encoding)内で表現される仕様である.
第3段階はTomcat(またはそのアプリケーションcontainer)がフェーズ2のJAVAバイナリコードを読み込み実行し、出力した結果、つまりクライアントで見たものであり、このときフェーズ1とフェーズ2に隠されたパラメータcontentTypeが機能する
contentTypeの設定
PageEncodingとcontentTypeのプリセットはISO 8859-1である.一方を適当に設定と、もう一方は同じになる(TOMCAT 4.1.27はそうである).しかし、これは絶対的なものではありません.これはそれぞれのJSPCの処理方法次第です.一方、pageEncodingはcontentTypeに等しくなく、アジア地域の文字CJKV系JSPページの開発と展示に有利である(例pageEncoding=GB 2312はcontentType=utf-8に等しくない).
jspファイルは似ていません.java,.JAvaは、コンパイラに読み込まれたときにデフォルトでオペレーティングシステムが設定したlocaleに対応する符号化を採用しています.例えば、中国大陸はGBK、台湾はBIG 5またはMS 950です.一般的に私たちは手帳にもueにもコードを書いていますが、特別なトランスコードがなければ、ローカルコードフォーマットの内容が書かれています.そのため、コンパイラが採用した方法は、仮想マシンに正しい資料を得ることができます.
しかしjspファイルはそうではありません.このデフォルトのトランスコードプロセスはありませんが、pageEncodingを指定すると正しいトランスコードが実現します.
例を挙げます.
私が入力した「こんにちは」はgbkですが、サーバーが「こんにちは」を正しく捕まえたかどうかは分かりません.
ただし、
これでサーバーは必ず「こんにちは」を正しく捕まえます.
参照先:
http://duqiangcise.iteye.com/category/49059?show_full=true
http://www.233.com/Java/jichu/20080318/115037554.html
JSPページのpageEncodingとcontentTypeの2つの属性の違いについて:
PageEncodingはjspファイル自体の符号化です
contentTypeのcharsetとは,サーバがクライアントに送信する際のコンテンツ符号化である.
JSPは2回の「コード」を経て、第1段階はpageEncoding、第2段階はutf-8からutf-8、第3段階はTomcatから出たページでcontentTypeを使う.
第1段階はjspのコンパイルである.JAvaは、pageEncodingの設定に従ってjspを読み出し、その結果、指定された符号化スキームによって統一されたUTF-8 JAVAソースコード(すなわち.java)に翻訳され、pageEncodingの設定が間違っていたり、設定されていなかったりした場合、中国語の文字化けが発生します.
第2段階はJAVACのJAVAソースからjava byteCodeへのコンパイルであり、JSP作成時にどのような符号化スキームを用いたかにかかわらず、この段階を経た結果はすべてUTF-8のencodingのjavaソースである.
JAVACはUTF-8のencodingでjavaソースコードを読み出し、UTF-8 encodingのバイナリコード(すなわち.class)にコンパイルする.これはJVM対定数文字列がバイナリコード(java encoding)内で表現される仕様である.
第3段階はTomcat(またはそのアプリケーションcontainer)がフェーズ2のJAVAバイナリコードを読み込み実行し、出力した結果、つまりクライアントで見たものであり、このときフェーズ1とフェーズ2に隠されたパラメータcontentTypeが機能する
contentTypeの設定
PageEncodingとcontentTypeのプリセットはISO 8859-1である.一方を適当に設定と、もう一方は同じになる(TOMCAT 4.1.27はそうである).しかし、これは絶対的なものではありません.これはそれぞれのJSPCの処理方法次第です.一方、pageEncodingはcontentTypeに等しくなく、アジア地域の文字CJKV系JSPページの開発と展示に有利である(例pageEncoding=GB 2312はcontentType=utf-8に等しくない).
jspファイルは似ていません.java,.JAvaは、コンパイラに読み込まれたときにデフォルトでオペレーティングシステムが設定したlocaleに対応する符号化を採用しています.例えば、中国大陸はGBK、台湾はBIG 5またはMS 950です.一般的に私たちは手帳にもueにもコードを書いていますが、特別なトランスコードがなければ、ローカルコードフォーマットの内容が書かれています.そのため、コンパイラが採用した方法は、仮想マシンに正しい資料を得ることができます.
しかしjspファイルはそうではありません.このデフォルトのトランスコードプロセスはありませんが、pageEncodingを指定すると正しいトランスコードが実現します.
例を挙げます.
<%@ page contentType="text/html;charset=utf-8" %>私が入力した「こんにちは」はgbkですが、サーバーが「こんにちは」を正しく捕まえたかどうかは分かりません.
ただし、
<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>これでサーバーは必ず「こんにちは」を正しく捕まえます.
参照先:
http://duqiangcise.iteye.com/category/49059?show_full=true
http://www.233.com/Java/jichu/20080318/115037554.html