JSP は 2 回「エンコード」する必要があります。最初の段階では pageEncoding を使用し、2 番目の段階では utf-8 から utf-8 を使用します。3 番目の段階では、ContentType を使用して Tomcat によって生成された Web ページです。
JSP ページの pageEncoding 属性と contentType 属性の違いについては、次のとおりです。
pageEncoding は、jsp ファイル自体のエンコーディングです。
contentType の文字セットは、サーバーがクライアントにコンテンツを送信するときのコンテンツのエンコードを参照します。
JSP は 2 回「エンコード」する必要があります。最初の段階では pageEncoding を使用し、2 番目の段階では utf-8 から utf-8 を使用します。3 番目の段階では、ContentType を使用して Tomcat によって生成された Web ページです。
最初の段階では、jsp を .java にコンパイルします。その結果、指定されたエンコーディング スキームが統一された UTF-8 JAVA ソース コード (つまり、pageEncoding の場合) に変換されます。設定が間違っている、もしくは設定が無い、出てくるのは中国語の文字化けです。
2 番目の段階は、JAVAC の JAVA ソース コードから Java byteCode へのコンパイルです。JSP を作成するときにどのようなエンコード スキームが使用されたとしても、この段階の結果はすべて UTF-8 でエンコードされた Java ソース コードになります。
JAVAC は、UTF-8 エンコーディングを使用して Java ソース コードを読み取り、それを UTF-8 エンコーディング バイナリ コード (つまり、.class) にコンパイルします。これは、バイナリ コード (Java エンコーディング) での定数文字列の表現に関する JVM の仕様です。
3 番目のステージでは、Tomcat (またはそのアプリケーション コンテナ) がステージ 2 の JAVA バイナリ コードをロードして実行します。この時点で、ステージ 1 と 2 で隠されていたパラメータ contentType が出力結果として表示されます。
contentType の設定。
pageEncoding と contentType のデフォルトはどちらも ISO8859-1 です。一方を適当に設定すると、もう一方も同じになります (これは TOMCAT4.1.27 の場合です)。ただし、これは絶対的なものではなく、その処理方法に依存します。各 JSPC では、pageEncoding が contentType と等しくないため、アジアでの CJKV テキスト JSP Web ページの開発と表示がより容易になります (たとえば、pageEncoding=GB2312 は contentType=utf-8 と等しくありません)。
jsp ファイルは .java とは異なります。コンパイラによって .java が読み取られると、オペレーティング システムによって設定されたロケールに対応するエンコーディングがデフォルトになります。一般に、メモ帳でコードを記述しても、ue でコードを記述しても、特別なトランスコーディングがない場合、記述される内容はローカル エンコード形式のコンテンツになります。したがって、コンパイラが採用する方法は、仮想マシンが正しいデータを取得できるようにするだけです。
ただし、jsp ファイルにはこのようなデフォルトのトランスコーディング プロセスはありませんが、pageEncoding を指定することで正しいトランスコーディングを実現できます。
例えば：
<%@ ページ contentType="text/html;charset=utf-8" %>
私が入力した「お元気ですか」はgbkのものであるため、ほとんどの場合文字化けが出力されますが、サーバーが「お元気ですか」を正しくキャプチャしたかどうかは不明です。
以下の内容に変更するだけです
<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>