jspファイルにおけるcharsetとpageEncodingの違い

jspファイルにおけるcharsetとpageEncodingの違い
<%@ page language="java"contentType="text/html; charset=UTF-8"pageEncoding="GBK"%>  
pageEncoding="GBK"は、JVMというjsp自体が採用する"GBK"符号化をJVMに伝え、JVMのデフォルトiso-8559.
contentTypeのcharset=utf-8はページを示す出力方式utf-8です
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"%>

これでサーバは必ず「こんにちは」を正しく捕まえます.