原因JavaWebプログラミングは化け
ネットワーク上の文字のさまざまを送信するために、0と1のみを既知のコンピュータが符号化される必要があるため。様々な不確実性のエンコーディング、伝送および復号化プロセスがあるためと、頻繁にゴミ問題につながることは初心者のための大きな問題となっています。この記事では、最も簡単な例では、ゴミ問題を説明しようとします。
1.なぜゴミ問題が？そこにされて
復号することができない、これは送信機であれば、これを復号するための別のパスワードの受信側は確かに同じにつながる一方で、パスワードを使用して送信機など電報のよう。コンピュータネットワークにおけるデータ伝送が符号化および送信側の端部を受ける場合、問題に上昇する使用矛盾しています。
：2.コーディングの多様認識する
ASCIIを：
ASCII（情報交換、情報交換用米国標準コードのための米国標準コード）は、現代英語や他の西ヨーロッパ言語を表示するために使用されるラテンアルファベットに基づいて、コンピュータ符号化システムのセットです。今では、最も一般的なシングルバイト符号化方式であり、国際標準ISO / IEC 646に相当します。
ISO-8859-1：
ASCIIはアメリカの標準であるので、それは英語を使用するスペースと十分な94「印刷可能文字」が含まれています。しかし、他の言語は、ラテンアルファベット（ヨーロッパ諸国の主言語）を使用する追加の記号文字の特定の番号を持って、我々は保存して表現するASCIIおよび制御文字以外の領域を使用する必要があります。
この問題を解決するために、国際標準化機構（ISO）と国際電気標準会議（IEC）の規格は共同で、今15文字の集合を定義する、ISO / IEC 8859の略で、ISO-8859の8ビット文字セットのシリーズを開発しました。ラテン語以外の言語の使用、キリル文字、東ヨーロッパ言語、ギリシャ語、タイ語、現代アラビア語、ヘブライ語、などに加えて、あなたは、店舗との表現には、このフォームを使用することができます。
GBK / GB2312：
1980年に中国の国家管理は、標準GB2312基準を公表した中国の表示と編集の問題を解決するために、それは「中国の符号化文字集合との情報交換」の略で、標準数が2312から1980 GBです。GB2312エンコーディングは漢字処理、漢字通信システム、中国本土へのアクセスとの間の情報交換に適用されます。また、シンガポールは、このエンコーディングを使用しています。ほとんどすべての中国のシステムおよび中国本土のソフトウェアサポートGB 2312年の国際化。文字の基本セット6763総収入と非グラフィック文字682の文字。GB 2312は、基本的に登場漢字のコンピュータ処理のニーズを満たす、漢字は中国本土、使用の99.75パーセントの頻度でその適用範囲に含まれています。しかし、言葉ほとんど使用されない側面名、古代中国や新興他のために、GB 2312は、GBKとGB 18030中国語の文字セットのその後の出現につながった、処理することはできません。
1995年に中国国家標準化管理は「漢字コーディング拡張仕様」（GBK）を公布しました。GBK国家標準GB 2312-1980と準拠対応する内側コード、一方語彙サポート全てISO / IEC10646-1及びGB 13000から1、日本語および韓国語（CJK）の文字、20902文字の合計。
国家標準GB18030-2005「情報技術 - 中国の符号化文字集合」であり、中国の二番目に重要なGB2312-1980後とGB13000.1-1993中国の文字エンコーディング標準が従わなければならないコンピュータシステムの基本的な基準の一つです。GB18030-2000とGB18030-2005：GB18030は、2つのバージョンがあります。GBK GB18030-2000は、その主な特徴は、GBKの基礎でCJK統合漢拡張A文字が追加され、バージョンを代入します。主な機能はGB18030-2005文字の追加はGB18030-2000拡張Bごとに漢字を統一CJKです。GB18030-2005は独立して中国の漢字が開発し、大規模な中国の符号化文字が必須の基準を設定するの、漢字の収入（例えばチベット、モンゴル、大、李、韓国語、ウイグル語など）少数民族言語の多様性を含んでいています70,000以上。中国のWindowsオペレーティングシステムでは、デフォルトでエンコードGBK / GB2312を使用します。
ユニコード：
多くの伝統的なコーディング方法は、（通常、母国語だけでなく、ラテン文字を使用して）バイリンガルコンピュータ処理を可能にするために、つまり、共通の問題を持っていますが、同時に（混合複数言語の同時取り扱いを参照）多言語環境をサポートすることはできません。伝統的なユニコードの制限に対処するには生成された文字符号化方式で、例えば、広くさまざまな国で使用されるが、状況は互換性が、多くの場合、さまざまな国ではないが、ISO 8859で定義された文字。Unicodeは、クロスランゲージ、クロスプラットフォームのテキスト変換して処理を実現するためにコンピュータを有効にするには、表示されます。
UTF-8：
Unicodeエンコーディングは、1つの文字を格納するために2つのバイトを使用しているため。事実は彼に役に立たないため、高バイトのASCII 0ながら、2倍の大きさよりも理由UnicodeのASCIIスペース効率的ではないUnicode文字の使用はASCIIで表現できることを証明しています。この問題を解決するために、いくつかの文字セットの中間形式があった、彼らは、ユニバーサル変換フォーマット、すなわちUTF（Unicodeの変換フォーマット）と呼ばれています。
UTF-8（8ビットユニコード変換フォーマット）は、Unicode文字エンコーディングのための可変長です。1992年にケン・トンプソンによって作成されます。今、RFC 3629として標準化。1-4 Unicode文字エンコーディングとUTF-8バイト。Webページ上の同じページで簡体字中国語繁体字と（例えば、英語、日本語、韓国語など）他の言語を表示することができます。
UTF-16：
文字コード表（文字エンコード形式とも呼ばれる「保存形式」）一の実施態様では：UTF-16は、第3の層のUnicode文字エンコーディング5層モデルです。すなわち、抽象コードビットユニコード文字セットは、データ記憶または転送のために16ビット長の整数（すなわち、シンボル）シーケンスにマッピングされます。Unicode文字コード・ビット、示される16ビットまたは二つのシンボルを必要とするので、これは固定長図です。デフォルトとしてUTF-16文字のメモリ・ストレージ・フォーマットを使用してJava言語。
第二に、扱う様々な歪みの
ため、処理の異なる方法を使用する必要の異なる原因の歪みの処理の問題は、次のように述べた様々な問題に提示されています。
1.応答処理歪み
使用されるバイトのA.応答出力ストリーム：
=「キーChuanポッドキャスト」文字列データ。
。response.getOutputStream（）書き（data.getBytes（））;
GetBytesメソッドの文字列（）メソッドは、バイト配列のデフォルトに文字列を変換するためのネイティブプラットフォームのデフォルトのエンコーディングを使用し、当社の中国WindowsオペレーティングシステムはデフォルトGBKのコーディングを使用しているため。ゴミ問題によって測定発生しません。クライアントでは、ブラウザのデフォルトでは、ページを解析し、オペレーティングシステムのデフォルトのエンコーディングを使用し、デフォルトではWindowsシステムでGBKです。端と受信端を送信することは、一貫した符号化されていないので、何の文字化け。
UTF-8エンコーディングに国際的に共通の符号化であるので、我々は通常、UTF-8エンコーディングを使用して、Web開発を行っています。GetBytesメソッドは、（「UTF-8」）は、クライアントに送信されたバイト配列を与える場合でも、問題は文字化けします。GetBytesメソッド（「UTF-8」）が実際にUTF-8バイト配列に文字列をコードで指定されているためです。この時点でデフォルトのブラウザは、まだゴミ問題が発生しますデコードするネイティブプラットフォームのデフォルトのエンコーディングを使用しています。
次のようにこの時点での表示は次のようになります。
この時点で、あなたはゴミ問題を解決するには、次の方法を使用することができます。
方法1：手動でブラウザのエンコーディングを調整します
マウスの右ボタン、ポップアップメニュー、選択エンコーディングをクリックして、UTF-8エンコーディングを選択します。
方法2：HTMLのmetaタグセット仕様を使用して
通常のテキスト表示にコードを追加した後。
方法3：のsetHeader応答オブジェクト（）メソッドを使用すると、Content-Typeヘッダを設定します
另外，按照HTTP协议的规定，如果指定了消息正文的MIME类型后，浏览器就必须按照MIME类型解析，所以可以通过设置响应消息头Content-Type的值为text/html，并指定参数charset=UTF-8来使浏览器使用UTF-8解析页面。
方法四：使用Response对象的setContentType()方法设置MIME类型及编码
由于方法三的使用频率比较高，所以在制定Servlet规范时，JCP组织抽取了一个比较简单的方法，此方法与方法三的原理相同，只是更简单，在实际工作中，我们通常使用此方法指定MIME类型。
B. 使用字符输出流输出响应：
Response对象的getWriter()方法可以返回一个PrintWriter对象，输出的内容会暂存在缓冲区中。当响应结束时，Tomcat使用默认编码ISO-8859-1将Response对象的响应消息正文转换为二进制数据输出给客户端，而浏览器使用本地平台默认编码进行解码，从而导致乱码。
处理方式：使用response.setCharacterEncoding("UTF-8")方法告知Tomcat使用UTF-8而不是ISO-8859-1对响应消息正文进行编码。另外，还需要使用response.setContentType("text/html;charset=UTF-8")告知浏览器使用UTF-8编码解码传递过来的数据。
修改后的显示效果如下：
2. 请求中的乱码处理
在用户提交表单时，浏览器会按照当前页面的编码设置对中文字符进行编码，并将内容生成请求消息发送给服务器进行解析。Tomcat服务器得到请求消息后，会依据表单数据的位置不同，做不同的处理。
提出方法（メソッド）がPOSTである場合、フォームデータは、この場合Request.setCharacterEncoding（「UTF-8」）が通知に必要なISO-8859-1復号のこの部分のためのデフォルトを使用して要求メッセージのTomcatの身体上に配置されますサーバは、要求メッセージのボディ復号のUTF-8エンコーディングを使用します。
提出方法（メソッド）がGETである場合、フォームデータは、ライン要求メッセージに入れ、URLエンコードされた二次符号化規格を使用しています。このTomcatを得られたデータの一部の後、最初のISO-8859-1した後、第2の復号化デフォルトを使用して、URLデコード標準を使用します。歪みの問題が発生するように、この時点で、文字列を取得するために使用される場合Request.getParamater（）メソッドは、ISO-8859-1デコードされた文字列を介して得られます。この場合、文字列はISO-8859-1の前に再びデコードし、バイト配列を再生に合わせて再取得する必要があります。
3.クッキー処理ごみ;
各クッキーは、クッキーとのSet-Cookieヘッダのメッセージと要求メッセージのヘッダに応答して送信し、HTTPプロトコルを使用されるように、メッセージおよび応答メッセージは、英語の文字だけを要求することができ、漢字直接使用することはできません安全ではありません。そのため、クッキーは中国語で保存した場合、符号化処理の必要性。我々は、読み取りにデコード（）メソッドURLDecoderのツールを使用して復号化のURLEncoder（）メソッド中国語符号を符号化するためのツールを使用することができます。
使用URLEncoder.encode（ユーザ名文字列の）方法エンコードされ、次いで、クッキーオブジェクトを作成しているが、以下に示す：
以下に示すように、ユーザ名の文字列をデコードする使用URLDecoder.decode（）メソッド：
第三に、要約
上記の例のみ限り、我々が把握できるように、開始します重要な問題は、雲のように何文字化け、文字化けの本質を理解し、住んでいます。