jsp中国語問題解決策（完全版）

==================================
Java アプリケーションを開発するときに文字化けが発生するのはよくあることですが、gb2312 (gbk 簡体字と big5 繁体字を含む) を使用するシステムでは、

中国語表示と文字化けを正しく実装することが最も基本的な要件となります

データベースストレージ。

==============================
1. まず、開発者は、なぜ文字化けしたコードに遭遇するのか、またどのような種類の文字化けコード (意味のない記号、疑問符の列、またはその他) に遭遇するのかを理解する必要があります。
初心者は、乱雑な文字の束に遭遇すると通常、途方に暮れます。最も直接的な反応は、Google を開いて「Java Chinese」を検索し (この文字列は検索エンジンで頻繁にクエリされます)、

他の人の文字を 1 つずつ確認すること

解決策。これを行うことに問題はありませんが、以下に示す理由により、目標を達成するのは困難です。
つまり、文字化けの原因はさまざまであり、解決策はまったく異なります。問題を解決するには、まず自分の「文脈」を分析する必要があります。

============================
2. 具体的には、プロジェクト内の文字化けしたコードのソースを特定するためにどのような情報が必要か。
a. 開発者が使用するオペレーティング システム
b、j2eeコンテナの名前とバージョン
c、データベース名、バージョン (正確なバージョン)、および JDBC ドライバーのバージョン
d. ソース コードが文字化けしている (たとえば、システム出力からのもの、または JSP ページ内にあります。JSP 内にある場合は、ヘッダー宣言も非常に重要です)

========== === =============================================
3. 文字化けの原因を最初に解析する方法。
上記の情報があれば、基本的に Javaworld などのフォーラムに投稿すれば、専門家が効果的な解決策をすぐに見つけてくれると思います。
もちろん、常に投稿に頼って助けを求めることはできませんが、自分で問題を解決するよう努めるべきです。どうやって始めればいいですか？
a. 「文字化けしたコード」がどのようなエンコーディングであるかを分析します。これは実際には難しくありません。たとえば、
System.out.println(testString);
この段落には文字化けしたコードがあるため、徹底的な方法を使用して実際のエンコード形式を推測することをお勧めします。
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"));
待ってください。上記のコードは、指定されたエンコード形式を使用して testString の「文字化けコード」を読み取り、それを gb2312 に変換することを意味します (ここでは例として中国語のみが使用されています)。
次に、どの変換結果が適切であるかを確認します。それだけです。 。 。

b. 上記の手順を使用して正しい中国語を取得できた場合、データは確かに存在しますが、インターフェイスに正しく表示されないだけです。次に、2 番目のステップは、ビュー部分を修正することです

。通常、確認する必要があるのは、JSP で正しいページ エンコーディングが選択されているかどうかです。

content="text"

であることを指摘したいと思います。

/html; charset= gb2312''>この 2 つの違い。通常、インターネット上の多くの記事で中国語の問題について言及すると、データベース内での Unicode または gb2312 ストレージの選択は、jsp のページ ディレクティブを

使用してエンコーディングを宣言することで

しかし、この発言は非常に無責任だと思いますし、私はそのせいで、そもそも存在しないコードの文字化けについて落ち込んで多くの時間を費やすことになりました。実際、page の役割は

、

JSP が HTML にコンパイルされるプロセス中に式内の String を「読み取る」ためのコーディング メソッドを Java に提供することであり (上記の 3 番目のステートメントの役割と多少似ています)、

メタはよく知られています。最終データを「表示」するために使用される、IE ブラウザーのエンコード オプションを提供します。しかし、これを私に思い出させてくれる人は見たことがありません。私は常に page をメタとして使用していました。

その結果、元々 iso-8859 だったデータが page コマンドによって gb2312 として読み込まれ、文字化けしてしまいました。そこで、コーディングを追加しました。すべての文字列データを変換する変換関数。すべて iso8859 から gb2312 に変更しました (

なぜ

================================================= =============
4. データベースにはどのエンコーディングが適していますか?
現在人気のある DB には、SQL Server、mysql、oracle、DB2 などが含まれます。その中でも、mysql は、そのパフォーマンスと機能が認められており、インストールと設定が比較的簡単で、

対応する

。 mysql を例として取り上げます。

個人的には、ストレージに mysql のデフォルトのエンコーディングである iso-8859-1 (mysql オプションの latin-1 に対応) を使用することをお勧めします。主な理由はいくつかあります。第 1 に、iso-8859-1 は

中国語

マルチエンコーディングのサポートが提供されるため、安定性も向上します。

他の DB との互換性がないことは言うまでもなく、バージョンが異なる場合でも互換性の問題が発生する可能性があります。

たとえば、mysql 4.0 より前の製品では、多くの中国語ソリューションは、gb2312 などのエンコーディングを設定するために接続のcharacterEncoding フィールドを使用します。

元のデータは ISO8859_1 でエンコードされており、jdbc ドライバーは指定されたものを使用するため、

URL内の文字セットはエンコードに使用され、resultSet.getString(*)はエンコードされた

文字列を取り出します。このようにして、gb2312 のデータを直接取得できます。

ただし、mysql 4.1 のリリースは、多くのデータベース管理者に多くの問題をもたらしました。mysql 4.1 では、各テーブルと列でエンコーディングを指定できるため

、指定しない場合は ISO8895_1 になります。データの場合、すべてのデータを取得するためにグローバル パラメーターを使用するのではなく、文字セットがエンコードに使用されます。

このことは、文字化けの問題が実に複雑で、原因が多すぎることを別の側面から示しています。私が遭遇した実際の状況に対するいくつかの解決策を提供するだけです。

間違いが

内部使用のみ。
ご質問がございましたら、 [email protected]までお問い合わせください。
================================================= ==============

ついに中国問題に対する最も完璧な解決策を見つけた。 。 。このオンライン記事の著者に感謝します。 。 。
私のオリジナルの記事は私自身の経験に基づいています。何も問題はありませんでしたが、問題の最終的な根本原因は見つかりませんでした。この記事を読んで、ふと気づきました（笑）
————————————————————————————————————————————————— —————-

Java プログラミングにおける中国語の問題はありふれた問題であるため、Java の中国語の問題に対する多くの解決策を読んだ後、著者のプログラミングの実践と組み合わせると、過去に議論した方法の多くでは問題を明確に説明できないことがわかりました。問題を解決し、特にクロスプラットフォームでの中国語の問題を解決します。
そこで私は、コンソール上で実行されているクラス、サーブレット、JSP、および EJB クラスにおける中国語の問題に対する私の分析と提案された解決策を含むこの記事を提供しました。アドバイスをいただければ幸いです。

要約: この記事では、Java プログラミングにおける Java コンパイラによる Java ソース ファイルと JVM によるクラス ファイルのエンコード/デコード プロセスを詳細に分析し、このプロセスの分析を通じて、Java プログラミングにおける中国語の問題の根本原因を明らかにします。 Java 中国語の問題を解決するために提案された最適な方法。

1. 中国語の問題の原因

コンピュータの元のオペレーティング システムでサポートされているエンコーディングは 1 バイト文字エンコーディングであったため、コンピュータ内のすべての処理プログラムは最初は 1 バイト エンコーディングで処理されていました。

コンピュータの発展に伴い、世界の他の国の言語（もちろん我が国の漢字も含む）に適応するために、2バイトエンコードを使用し、英語の文字と互換性のあるUNICODEエンコードが提案されました。したがって、現在、ほとんどの国際的なソフトウェアは、ソフトウェアの実行時に、ローカルのサポート システム (ほとんどの場合、オペレーティング システム) によってサポートされているエンコード形式を内部的に使用します。 ) を実行し、ソフトウェア内の UNICODE をローカル システムがデフォルトでサポートするエンコード形式に変換して表示します。

これは Java の JDK と JVM の場合に当てはまります。ここで説明する JDK は、JDK の国際化バージョンを指します。以下の JDK はすべて、国際化された JDK バージョンを指します。当社の中国語文字は、コンピュータで中国語を処理できるようにするために、コンピュータ処理のニーズを満たす独自の規格 (gb2312、GBK、GBK2K) を開発しました。

したがって、中国語処理のニーズに適応するために、ほとんどのオペレーティング システムは、中国語の文字を正しく表示するために GBK および GB2312 エンコード形式を使用してカスタマイズされています。例: 中国語 Windows では、デフォルトで表示に GBK エンコードが使用されます。中国語 Windows 2000 でファイルを保存する場合、ファイルの保存にデフォルトで使用されるエンコード形式も GBK になります。つまり、中国語 Windows 2000 で保存されるすべてのファイルの内部エンコードは GBK を使用します。注: GBK は GB2312 に基づいて拡張されます。

Java 言語は内部で UNICODE エンコーディングを使用するため、Java プログラムの実行時に、入力と出力を UNICODE エンコーディングと、オペレーティング システムとブラウザでサポートされている対応するエンコーディング形式に変換するという問題が発生します。この変換プロセスには一連の手順があります。いずれかの手順にエラーがあると、表示される中国語の文字が文字化けします。これは、Java 中国語でよく発生する問題です。

同時に、Java はクロスプラットフォームのプログラミング言語です。つまり、私たちが作成したプログラムは中国語の Windows だけでなく、中国語の Linux やその他のシステムでも動作する必要があります。誰かが中国語版 Windows 2000 で書かれた Java プログラムを英語版 Linux 上で動作するように移植したのをよく見かけます)。この移植手術は中国にも問題をもたらすだろう。

また、英語のオペレーティング システムや IE などの英語のブラウザを使用して、中国語の文字を含むプログラムを実行したり、中国語の Web ページを閲覧したりする人もいます。それらは中国語自体をサポートしていないため、中国語の問題も発生します。

ほとんどすべてのブラウザはデフォルトで中国語のエンコードではなく UTF-8 エンコード形式でパラメータを渡します。そのため、中国語のパラメータを渡すときに文字化けが発生する問題も発生します。

つまり、上記の側面は Java における中国語の問題の主な原因であり、上記の理由によりプログラムが正しく動作しないことによって引き起こされる問題を Java 中国語問題と呼びます。

2. Java エンコード変換の詳細なプロセス。

一般的な Java プログラムには次のカテゴリが含まれます:

* コンソール上で直接実行されるクラス (ビジュアル インターフェイス クラスを含む)

* JSP コード クラス (注: JSP はサーブレット クラスのバリアントです)

* サーブレットクラス

* EJB クラス

* 直接実行できないその他のサポート クラス

これらのクラス ファイルには中国語の文字列が含まれている場合があり、多くの場合、最初の 3 種類の Java プログラムを使用して、次のような出力文字と入力文字をユーザーと直接対話します。サーブレットはクライアントから送信された文字を取得します。これらの文字には漢字も含まれます。これらの Java クラスの役割に関係なく、これらの Java プログラムのライフ サイクルは次のようになります。

*プログラマは、特定のオペレーティング システム上で適切な編集ソフトウェアを選択して、ソース プログラム コードを実装し、.Java 拡張子を付けてオペレーティング システムに保存します。たとえば、中国語の Windows 2000 で Java ソース プログラムを編集するにはメモ帳を使用します。

*プログラマは、JDK の Javac.exe を使用して、これらのソース コードをコンパイルして .class クラスを形成します (JSP ファイルは、JDK を呼び出すコンテナによってコンパイルされます)。

※これらのクラスを直接実行するか、WEBコンテナにデプロイして実行し、結果を出力します。

では、これらのプロセス中に、JDK と JVM はどのようにしてこれらのファイルをエンコード、デコード、実行するのでしょうか?

ここでは、中国の Windows 2000 オペレーティング システムを例として、Java クラスがどのようにエンコードおよびデコードされるかを説明します。

まず、メモ帳などの編集ソフトウェアを使用して、中国語 Windows 2000 で Java ソース プログラム ファイル (上記 5 種類の Java プログラムを含む) を作成します。プログラム ファイルを保存するとき、プログラム ファイルは、Windows 2000 でサポートされている GBK エンコード形式を使用します。デフォルトではオペレーティング システム (デフォルトではオペレーティング システムによってサポートされています) で .Java ファイルを形成します (形式は file.encoding 形式です)。つまり、Java プログラムがコンパイルされる前に、Java ソース プログラム ファイルが file.encoding に保存されます。オペレーティング システムによってデフォルトでサポートされているエンコード形式。中国語の情報文字と英語のプログラム コードが含まれています。システムの file.encoding パラメータを表示するには、次のコードを使用します

。
{
public static void main(String[] args)
{
文字列エンコーディング =
System.getProperty("file.encoding");
System.out.println(エンコーディング);
}

、

JDK の Javac.exe ファイルを使用して Java ソース プログラムをコンパイルします。JDK は国際バージョンであるため、コンパイル時に -encoding パラメータを使用して Java ソースのエンコード形式を指定しません。つまり、Java プログラムをコンパイルするときに、ソース プログラム ファイルのエンコード形式を指定しない場合、JDK は最初に file.encoding パラメータを取得します。オペレーティング システムのデフォルトのエンコード形式 (Windows2000 など、その値は GBK が保存されます) を保存し、JDK は Java ソース プログラムを file.encoding エンコード形式から Java の内部デフォルト UNICODE 形式に変換し、メモリに置きます。

次に、Javac は変換された Unicode 形式のファイルを .class クラス ファイルにコンパイルします。このとき、.class ファイルは UNICODE エンコードされ、JDK はコンパイルされたクラスを UNICODE エンコードでコンパイルします。オペレーティング システムに保存され、表示される .class ファイルが形成されます。

最終的に取得した .class ファイルは、内容が UNICODE エンコード形式で保存されたクラス ファイルです。ソース プログラムには中国語の文字列が含まれていますが、この時点では file.encoding 形式によって UNICODE 形式に変換されています。 。

このステップでは、JSP ソース プログラム ファイルが異なります。JSP の場合は、Web コンテナが JSP コンパイラを呼び出し、JSP ファイルにファイル エンコーディング形式が設定されているかどうかを確認します。 JSP ファイルにはファイル エンコード形式がありません。JSP ファイルのエンコード形式を設定するために、JSP コンパイラは JDK を呼び出し、まず JVM のデフォルトの文字エンコード形式 (つまり、デフォルトのWEB コンテナが配置されているオペレーティング システムの file.encoding) を取得し、UNICODE 形式のクラスにコンパイルされ、一時フォルダーに保存されます。

例: 中国版 Windows 2000 では、WEB コンテナは JSP ファイルを GBK エンコード形式から UNICODE 形式に変換し、それを一時的に保存されたサーブレット クラスにコンパイルしてユーザーの要求に応答します。

3 番目のステップでは、2 番目のステップでコンパイルしたクラスを実行します。これは 3 つの状況に分けられます。
A. コンソール上で直接実行されるクラス

B. 直接実行できない EJB クラスとサポート クラス (JavaBean クラスなど)

C. JSP コードとサーブレット クラス

D. Java プログラムとデータベースの間

以下でこれら 4 つの状況を見てみましょう。

A. コンソール上で直接実行されるクラスの場合

、このクラスを実行するには、まず JVM サポートが必要です。つまり、オペレーティング システムに JRE がインストールされている必要があります。実行プロセスは次のとおりです。 まず、Java が JVM を起動します。このとき、JVM はオペレーティング システムに保存されているクラス ファイルを読み出し、その内容をメモリに読み込みます。このとき、メモリは UNICODE 形式のクラスです。この時点でこのクラスがユーザー入力を受け取る必要がある場合、クラスはデフォルトで file.encoding エンコード形式を使用してユーザーが入力した文字列をエンコードし、Unicode に変換してメモリに保存します。 (ユーザーは入力ストリームのエンコード形式を設定できます)。

プログラムの実行後、生成された文字列 (UNICODE エンコード) が JVM に返され、最後に、JRE はその文字列を file.encoding 形式に変換し (ユーザーは出力ストリームのエンコード形式を設定できます)、それをオペレーティング システムに渡します。インターフェースを表示し、インターフェースに出力します。上記の各変換手順では、最終的に文字化けが発生しないように、正しいエンコード形式の変換が必要です。 B. 直接実行できない EJB クラスおよびサポート クラス (JavaBean クラスなど)

EJB クラスおよびサポート クラスは直接実行できないため、通常、入出力のためにユーザーと直接対話しません。入力と出力に使用されるため、2 番目のステップでコンパイルされた後、その内容が UNICODE エンコーディングのクラスが形成され、他のクラスとの対話が行われない限り、将来的にはオペレーティング システムに保存されます。パラメータの受け渡しプロセス中に失われた場合でも、正しく実行されます。

C.

JSP コードとサーブレット クラスの 2 番目のステップの後、JSP ファイルもサーブレット クラス ファイルに変換されますが、標準のサーブレットのようにクラス ディレクトリには存在せず、WEB コンテナの一時ディレクトリに存在します。したがって、このステップではサーブレットとしても見ます。

サーブレットの場合、クライアントが要求すると、WEB コンテナはその JVM を呼び出してサーブレットを実行します。まず、JVM はシステムからサーブレット クラスを読み取り、エンコードされたサーブレット クラスのコードをメモリにロードします。 UNICODE。その後、JVM はメモリ内でサーブレット クラスを実行します。サーブレットが実行されている場合、フォームに入力された値や URL に渡された値などの文字を受け入れる必要があります。エンコーディング形式がパラメータとして使用される場合、WEB コンテナはデフォルトで ISO-8859-1 エンコーディング形式を使用して受信値を受け入れ、それを JVM で UNICODE 形式に変換します。 WEBコンテナのメモリに保存します。

サーブレットが実行されると出力が生成され、出力文字列は UNICODE 形式になります。その後、コンテナはサーブレットの実行によって生成された UNICODE 形式の文字列 (HTML 構文、ユーザー出力文字列など) をクライアントに直接送信します。このとき、ユーザーが出力のエンコード形式を指定した場合は、指定したエンコード形式でブラウザに出力されます。指定しない場合は、ISO-8859-でお客様のブラウザに送信されます。デフォルトでは 1 エンコーディング。

D. Java プログラムとデータベースの間

ほとんどすべてのデータベース JDBC ドライバーでは、Java プログラムとデータベースの間でデータを転送するためのデフォルトのエンコード形式は ISO-8859-1 です。そのため、プログラムは中国語を含むデータをデータベースに送信します。プログラムでは、JDBC はまずプログラム内の UNICODE エンコード形式のデータを ISO-8859-1 形式に変換してから、データベースにデータを渡します。データはデフォルトで ISO-8859-1 形式で保存されます。私たちがデータベースから読み出す中国語のデータが文字化けするのはこのためです。

3. 一般的な Java 中国語の問題を分析する際に理解する必要があるいくつかの原則

まず、上記の詳細な分析の後、Java プログラムのライフサイクルにおいて、エンコード変換の重要なプロセスは次のとおりであることが明確にわかります。ファイル ユーザーに出力されるトランスコーディングおよび最終的なトランスコーディング プロセス。

次に、コンパイル時に Java でサポートされる一般的に使用されるエンコード形式は次のとおりであることを理解する必要があります。

*ISO-8859-1、8 ビット、8859_1、ISO-8859-1、ISO_8859_1 および他のエンコーディングと同じ

*Cp1252、American英語エンコーディング、ANSI 標準エンコーディングと同じ

*UTF-8、Unicode エンコーディングと同じ

*GB2312、gb2312-80、gb2312-1980 およびその他のエンコーディング

と同じ *GBK、MS936 と同じ、gb2312 の拡張です。韓国語、日本語、繁体字中国語などの他のエンコーディング。同時に、次のようなこれらのエンコーディング間の互換性関係にも注意する必要があります。Unicode

と UTF-8 エンコーディングは 1 対 1 に対応します。 GB2312 は GBK のサブセットと考えることができます。つまり、GBK エンコードは gb2312 で拡張されています。同時に、GBK エンコードには 20902 個の漢字が含まれており、エンコード範囲は 0x8140 ～ 0xfefe です。すべての文字は UNICODE2.0 に 1 対 1 でマッピングできます。

3 番目に、オペレーティング システムに配置された .Java ソース プログラム ファイルの場合、コンパイル中に、特に -encoding を使用して、そのコンテンツのエンコード形式を指定できます。注: ソース プログラムに中国語の文字が含まれている場合に、-encoding を使用して他のエンコード文字を指定すると、当然エラーが発生します。

-encoding を使用して、ソース ファイルのエンコード方式を GBK または gb2312 として指定します。中国語の文字を含む Java ソース プログラムをどのシステムでコンパイルしても、問題なく中国語が UNICODE に変換されます。クラスファイル。

次に、ほとんどすべての WEB コンテナのデフォルトの文字エンコード形式がデフォルト値として ISO-8859-1 を使用すると同時に、ほとんどすべてのブラウザがパラメータを渡すときにデフォルトで UTF-8 を使用することを明確にする必要があります。 。

したがって、Java ソース ファイルは入口と出口で正しいエンコード方式を指定していますが、コンテナ内での実行時には ISO-8859-1 として処理されます。

4. 中国語の問題の分類とその推奨される最適な解決策

Java ファイル処理の上記の原則を理解した後、漢字の問題に対して推奨される一連の最適な解決策を提案できます。私たちの目標は、中国語の文字列や中国語の処理を含む Java ソース プログラムを中国語のシステムで編集し、コンパイル後に他のオペレーティング システムに移行して正しく実行できるか、他のオペレーティング システムでコンパイルしても正しく実行できることです。中国語と英語のパラメータを渡し、中国語と英語の文字列をデータベースと正しく通信できます。私たちの具体的なアイデアは、Java プログラムのトランスコーディングの入り口と出口、および Java プログラムがユーザーと入出力変換を行う部分で正しくエンコード方法を制限することです。

具体的な解決策は次のとおりです。

1. コンソール上で直接実行されるクラスの場合

、この場合、プログラムを作成するときに、中国語を含む可能性のあるユーザーからの入力、または中国語を含む可能性のある出力を受け取る必要がある場合、次のようにすることをお勧めします。プログラムは使用する必要があります。 文字ストリームは入力と出力を処理するために使用されます。具体的には、次の文字指向のノード ストリーム タイプが適用されます。

ファイルの場合: FileReader、FileWrieter、

そのバイト指向のノード ストリーム タイプは次のとおりです: FileInputStream、FileOutputStream

メモリの場合 (配列) ): CharArrayReader、

CharArrayWriter ノード ストリーム タイプ: ByteArrayInputStream、ByteArrayOutputStream

メモリ

(文字列): StringReader、StringWriter

パイプ: PipedReader、PipedWriter

同時に、次の文字

指向の処理ストリームを使用する必要があります:

BufferedWriter、BufferedReader、

そのバイト型処理ストリームは: BufferedInputeStream、BufferedOutputStream

InputStreamReader、OutputStreamWriter、

そのバイト型処理ストリームは: DataInputStream、DataOutputStream

、InputStreamWriter を使用して変換します

た

文字エンコーディング セットに従って、次のような文字ストリームに変換します。

例: 次のサンプル Java エンコーディングは要件を満たすことができます:

//Read.Java
Java.io.* をインポートします。
パブリッククラス読み取り
{
public static void main(String[] args)
throwsIOException
{
文字列 str =
"n中国語のテスト、これは内部ハードコーディングされた文字列「+」ですn英語の文字をテストします";
文字列文字列 = "";
BufferedReader の標準入力 =
新しい BufferedReader(新しい
InputStreamReader(System.in,”gb2312″));
//入力インターフェースを中国語でエンコードするように設定します
BufferedWriter の標準出力 =
新しい BufferedWriter(新しい
OutputStreamWriter(System.out,”gb2312″));
//出力インターフェースを中国語でエンコードするように設定します
stdout.write("入力してください:");
stdout.flush();
文字列 = stdin.readLine();
stdout.write("これはユーザーから入力された文字列です:"+strin);
stdout.write(str);
stdout.flush();
同時に

、プログラムをコンパイルするときに、次のメソッドを使用します:

Javac -encoding gb2312 Read.Java

2. EJB クラスおよび直接実行できないサポート クラス (JavaBean クラスなど) については、

これらのクラス自体が他のクラスによって使用される呼び出しはユーザーと直接対話しないため、このタイプの場合、推奨される処理方法は、内部プログラムが文字ストリームを使用してプログラム内の中国語文字列を処理することです (具体的には上記のセクションのように)。同時に、「クラスのコンパイル時」で -encoding gb2312 パラメーターを使用して、ソース ファイルが中国語形式でエンコードされていることを示します。

3. Servlet クラスの場合

、以下の方法を推奨します。

Servlet クラスのソースプログラムをコンパイルするときに、-encoding でエンコーディングを GBK または GB2312 に指定し、エンコーディングに応答オブジェクトの setContentType("text" を使用する) を使用します。ユーザーに出力するときは /html;charset=GBK”); または gb2312 を使用して、ユーザー入力を受け取るときに、オペレーティング システムに関係なく、このように request.setCharacterEncoding(”GB2312″); を使用します。サーブレットクラスはクライアントのみに移植されています。お使いのブラウザが中国語表示をサポートしている場合は、正しく表示されます。正しい例は次のとおりです:

//HelloWorld.Java
パッケージこんにちは。
Java.io.* をインポートします。
Javax.servlet.* をインポートします。
Javax.servlet.http.* をインポートします。
パブリック クラス HelloWorld
HttpServlet を拡張します
{
パブリック void init()
サーブレット例外をスローします
{
}
public void doGet
(HttpServletRequest リクエスト、
HttpServletResponse 応答)
IOException、ServletExceptionをスローします
{
request.setCharacterEncoding("GB2312");
//入力エンコード形式を設定する
応答.setContentType
("text/html;charset=GB2312");
//出力エンコード形式を設定する
PrintWriter 出力 = response.getWriter();
//PrintWriter出力を使用することをお勧めします
out.println(”<hr>”);
out.println("ハローワールド!
これはサーブレットによって作成されました!Test Chinese!");
out.println(”<hr>”);
}
public void doPost(HttpServletRequest リクエスト,
HttpServletResponse 応答)
IOException、ServletExceptionをスローします
{
request.setCharacterEncoding("GB2312");
//入力エンコード形式を設定する
応答.setContentType
("text/html;charset=GB2312");
//出力エンコード形式を設定する
文字列名 = request.getParameter("名前");
文字列 id = request.getParameter("id");
if(name==null) name="";
if(id==null) id="";
PrintWriter 出力 = response.getWriter();
//PrintWriter出力を使用することをお勧めします
out.println(”<hr>”);
out.println("渡した中国語の文字列は次のとおりです: " + 名前);
out.println("<hr>入力した ID は次のとおりです: " + id);
out.println(”<hr>”);
}
パブリック void destroy()
{
}
}

このプログラムをコンパイルするには、Javac -encoding gb2312 HelloWorld.Java を使用してください。

を

テストするプログラムは次のとおりです。

charset=gb2312″%>
<%request.setCharacterEncoding("GB2312");%>
<html><ヘッド><タイトル></タイトル>
<スクリプト言語="JavaScript">
関数送信()
{
//中国語の文字列値を URL 経由でサーブレットに渡します
document.base.action =
"./HelloWorld?name=中文";
document.base.method = “POST”;
document.base.submit();
}
</スクリプト>
</head>

<body bgcolor=”#FFFFFF”
text=”#000000″ topmargin=”5″>
<フォーム名="ベース" メソッド =
「POST」ターゲット=”_self”>
<input name="id" type="text"
値=”” サイズ=”30″>
<a href = “JavaScript:Submit()">
サーブレットに渡す</a>
</form></body></html>

4.

Java プログラムとデータベース間のデータ転送におけるデータ化けを回避するため、以下の最適な処理方法を推奨します。

1. Java プログラムは当社が指定する方法に従って処理すること。

2. データベースでデフォルトでサポートされているエンコード形式を GBK または GB2312 に変更します。

たとえば、mysql では、次のステートメントを設定ファイル my.ini に追加して、これを実現できます:

default-character-set=gbk

in the [mysqld] area

and add:

[client]
default-character-set=gbk

SQL Server2K では、目的を達成するためにデータベースのデフォルト言語を簡体字中国語に設定できます。

5. JSP コードの場合、

JSP は実行時に WEB コンテナによって動的にコンパイルされるため、JSP ソース ファイルのエンコード形式を指定しない場合、JSP コンパイラはサーバー オペレーティング システムの file.encoding 値を取得してコンパイルします。はい、移植時に問題が発生する可能性が高いのは、たとえクライアントが同じであっても、中国語の Windows 2000 では正常に動作する JSP ファイルが動作しないためです。オペレーティング システムのエンコーディングの違いが原因です (中国語の wink の file.encoding は英語 Linux の file.encoding とは異なり、英語 Linux は中国語をサポートしていないため、問題が発生します)。コンパイルされた JSP クラス)。

インターネットで議論されている問題のほとんどはこのような問題であり、主に JSP ファイルをプラットフォームに移植するときに正しく表示できないことが原因です。この種の問題については、Java のプログラム エンコード変換の原理を理解しているため、その方がはるかに簡単です。それを解決してください。推奨される解決策は次のとおりです。

1. クライアントに出力するときに、JSP が中国語エンコーディングで出力されることを確認する必要があります。つまり、何はともあれ、最初に次の行を JSP ソース コードに追加します。

< %@page contentType =” テキスト/html;
charset=gb2312″%>

が

受信パラメータを正しく取得できるようにするために、JSP ソース ファイルのヘッダーに次の文を追加します。

％>

3。JSPコンパイラが漢字を含むJSPファイルを正しくデコードするために、JSPソースファイルにJSPソースファイルのエンコード形式を指定する必要があります。 JSPソースファイルヘッダーのソース

ファイル
または< ％@page pageEncoding = "gbk"％>

これは、JSP仕様2.0に新しく追加された命令です。

JSP

ファイルで中国の問題を解決することをお勧めします。

< ％@page pageencoding =” gb2312″％>
< ％@page contentType = "text/html;
charset = gb2312″％>
<％request.setcharacterencoding（ "gb2312"）;
%>
<%
文字列Action = request.getParameter（ "action"）;
文字列name = "";
文字列str = "";
if（action！= null && action.equals（ "sent"）））
{
name = request.getParameter（ "name"）;
str = request.getParameter（ "str"）;
}
%>
<html>
<頭>
<タイトル></タイトル>
<スクリプト言語= "javascript">
function submit（）
{
document.base.action =
"？action = sent＆str = centoming binish";
document.base.method =“ post”;
document.base.submit（）;
}
</スクリプト>
</head>
<body bgcolor =”＃ffffff”
text =”＃000000″ topmargin =” 5″>
<form name = "base" method =
「投稿」ターゲット=” _ self”>
<入力タイプ=” text” name =” name”
value =”” size =” 30″>
<a href =“ javascript：submit（） "> submit </a>
</form>
<%
if（action！= null && action.equals（ "sent"）））
{
out.println（ "<br>入力した文字は："+name）;
out.println（ "<br> URLを介して渡した文字は次のとおりです。"+str）;
}
%>
</body>
</html>