コード理解
2900 ワード
一般的な符号化はiso 8859−1,GB 2312/GBK,unicode,utfであることが知られている.1 iso 8859-1単バイト、英語シリーズに適用され、最大表示可能な文字範囲は0-255 である.2 GB 2312/GBK男の国標コードは、漢字を表すために使用され、2バイトコードであり、英語コードはiso 8859-1と同じである.gbkはgb 2312と互換性がある. unicodeこれは最も統一的な符号化であり、すべての言語の文字を表すことができ、英字を含む定長2バイト(4バイトもある)符号化である.したがってiso 8859−1符号化にも符号化にも互換性がないと言える.しかし、iso 8859−1符号化に対してuniocode符号化は、アルファベット「a」が「0061」であるなどの0ワード節を前に追加しただけである.JAva内部はunicode符号化 を用いる.4 utfは、unicode符号化がiso 8859−1符号化に互換性がなく、より多くの空間を占有しやすいことを考慮している.英語のアルファベットについては、unicodeも2バイトで表す必要があるからである.そのためunicodeは転送とストレージに不便です.従ってutf符号化が生成され、utf符号化はiso 8859−1符号化と互換性があり、同時にすべての言語の文字を表すためにも用いられるが、utf符号化は不定長符号化であり、各文字の長さは1〜6バイトから等しくない.またutf符号化には簡単な検証機能が付属している.一般的に、英語のアルファベットは1バイトで表され、漢字は3バイトの を用いる.は、b==sリクエスト中にコミットされたフォームのformに文字セットの符号化が指定されている場合によく使用され、そうでなければページ符号化コミットが使用される.urlに直接入力したら?後のパラメータ文字セットはオペレーティングシステムの符号化 として符号化される. webServerが取得したバイトストリームはデフォルトでiso 8859-1で処理されるため、一般的にフィルタ設定サーバ処理符号化(request.setCharacterEncoding() である.システムが文字を出力すると、指定された符号化で出力されます.中国語windowsでresponse(ブラウザ)の場合、jspファイルヘッダで指定されたcontentTypeを使用するか、responseに直接符号化を指定できます.また、browserページのエンコードも教えてくれます.指定されていない場合はiso 8859-1符号化が使用されます.中国語の場合、browserに出力文字列の符号化を指定する必要があります. ブラウザでWebページを表示する場合は、まずresponseで指定するエンコーディング(jspファイルヘッダで指定されたcontentTypeも最終的にresponseに反映される)を使用し、指定されていない場合は、Webページのmeta項目指定のcontentType を使用します.
jspファイルの場合 1:<%@page pageEncoding="GBK"%>はコンパイル時の符号化を指し、要求時の文字セットはこれを基準として である.2:<%@page contentType="text/html;charset=GBK"%>はページ表示時のコードとresponseを指す.setCharacterEncoding(「GBK」)は同等です. 3:静的ページに対してmetaを用いて符号化を指定し、jspページに対してヘッダーで を優先する.
url符号化の場合
中国語IEの場合、拡張オプションでUTF-8での送信がすべてキャンセルされた場合、PathInfoおよびQueryStringは、URL encodeであり、GBKに従って符号化される(他にもffのように).
実際にコミットは
UTF-8で送信する場合、PathInfoはutf-8符号化、QueryStringはgbk符号化
前回実際に提出したのは
したがって,クライアント設定によって同じリンクがサーバ上で異なる結果を得た.この問題は多くの人が直面しているが,なかなか解決策がない.そのため、UTF-8オプションをオフにすることをお勧めするサイトもあります.しかし、一つの解決策は、自分のプログラムをよりスマートにすることです.内容に基づいてコードを分析することです.
たとえば、
jspファイルの場合
url符号化の場合
中国語IEの場合、拡張オプションでUTF-8での送信がすべてキャンセルされた場合、PathInfoおよびQueryStringは、URL encodeであり、GBKに従って符号化される(他にもffのように).
.html?a=
実際にコミットは
GET %B1%B1%BE%A9?a=%B1%B1%BE%A9
UTF-8で送信する場合、PathInfoはutf-8符号化、QueryStringはgbk符号化
前回実際に提出したのは
GET %E5%8C%97%E4%BA%AC?a=%B1%B1%BE%A9
したがって,クライアント設定によって同じリンクがサーバ上で異なる結果を得た.この問題は多くの人が直面しているが,なかなか解決策がない.そのため、UTF-8オプションをオフにすることをお勧めするサイトもあります.しかし、一つの解決策は、自分のプログラムをよりスマートにすることです.内容に基づいてコードを分析することです.
たとえば、
if(uri.toUpperCase().startsWith("/%E5%8C%97%E4%BA%AC")){// utf8
// url, UTF-8
cnuri = java.net.URLDecoder.decode(uri,"UTF-8");
}
if(uri.toUpperCase().startsWith("/%B1%B1%BE%A9")){// gbk
// url, UTF-8
cnuri = java.net.URLDecoder.decode(uri,"GBK");
}
if(uri.matches(".*(%u[\\w]{4}).*")){
cnuri=uri.replace("%u", "\\u");
cnuri =StringUtils.loadConvert(cnuri);
//System.out.println(" :"+cnuri+", ");
}