文字化け対策についてこんにちはゲストさん。「Java側でUTF-8の文字コードを指定してあげなければ、画面遷移した画面遷移先で文字化けが起こってしまう。文字コード「UTF-8で指定」しています。//コード変換という2点をコード変換として記述しています。%>画面状況:文字化けしている。画面1のリクエストをゲットする際に、java(servlet)での、文字の受け取り方の記述を変更しました。付与してやることで、回避でききました。これで解決策としては妥当でしょうか?(正しいでしょうか?)気にかかっているところが、どうもこのやり方が強引に文字を変換しているようにしか思えませんでして(実際のところは正しいのかもしれませんが・・・)このまま値を渡してやっていいのか判別が付かずに困っています。「UTF-8の文字が、UTF-16の文字に正しくマッピングされて、「あ」が「あ」として扱われるようになった」です。Javaでは元の文字コードが何であろうと、文字のバイトの並びがなんであろうと、Stringは常にそのバイトの並びを、UTF-16として処理するので。元のバイトの並びがutf-8で、「0xa1、0x00」、文字としては2文字の「A、null」を意味していたときに、UTF-16でも2文字の「A、null」であるということです。正しくないとは、これが、1文字の「A」としてだけ認識されるような状態です。本当に変な例なので、あくまでも例として考えてください。要するには意味が異なってしまった状態のことです。後、2-1と、2-2は一連の流れで1セットです。02:37:24お礼ありがとうございます。本当に変な例としてはutf-8の文字をutf-16にしたとき「A、null」が「A、null」でなく「A」とだけ認識ということがあるのですね。そこのところ不思議におもっていたところで「utf-8なのにutf-16にして何か問題ないのだろうか」と想っていたところだったんです。内部的な動きというものをよくわかっていないのでイメージではありますが、javaが上手いこと内部的に処理してくれてそうですね。なんだか長い事すみません(--;ご回答いただいた内容とても参考になりました。回答(4)ANo.3ecogilis>調べてみたらこれってASCIIコードのことだったのですね。エンコーディングは、asciiと互換性を持たせる符号化方式をとっています。utf-8(次の画面)>>という流れで、>正常に文字化けなく表示される「“あ”が表示される」、となる、ということでしょうか?や、こんな感じだと思います。JSPJSPにかかれたものは、実行時UTF-16になる(Javaコードになるから)。ソースがShift_JISで書いてあっても、実行時にUTF-16。%>」によって、response.setCharacterEncoding("UTF-8");みたいなコードが生成され、実行される。);として実行される。このときはUTF-16。先のresponse.setCharacterEncodingが指定されているので、出力が、フラッシュされるときには、UTF-16は、UTF-8に変換されてブラウザに送られる。23:06:02お礼ありがとうございます。(0)通報するANo.2ecogilis>「UTF-8」であったものを「iso-2022-jp」で再度文字を変換してしまうためすいません。間違えました、仮定する文字コードは「iso-8859-1」でした。一から話すと、次のとおりです。Javaの中では文字はUnicode(UTF-16)ですが、Javaの外では文字はリソースによって様々な文字コードで表現されます。よって、外からの文字をJavaの中で同様に文字として扱えるようにするためには、その文字をUTF-16に変換する必要があるのですが、この時コンテナやフィルタで、元の文字コードを「iso-8859-1」と仮定してしまっているので、元の文字とは異なる文字に置き換えられてしまい、文字が化けることになります。HTTPにリクエストパラメータの元の文字コードを指定する決められた方法が無いのでこの様になっているのではないかと思います。」を付与し、コード変換する対象としては、現在文字化けが発生しているのは「日本語文字だけ」ですので、>「日本語文字のみを対象とし、英数字については付与は不要」と考えているのですが、特に問題ありませんでしょうか?1バイトの英数字だけなら大丈夫です。正確に言えば、先の理屈から言えば、UTF-8とiso-8859-1とで、バイト値が変わらない文字(特に0x00~0x7f)ならどの文字も大丈夫です。暗黙的にiso-8859-1としてUTF16に自動変換されていても元のバイト値が表す文字がUTF-8と一緒なので、結果的に同じ文字に変換してくれます。22:03:41お礼ありがとうございます。文字コードについて、段々と分かってきました。>外からの文字をJavaの中で同様に文字として扱えるようにするためには、その文字をUTF-16に変換する必要があるのですがこれに驚きました。(無知なだけかもしれませんが^^;)UTF-8ではなくUTF-16をJavaでは使用しているのですね。>バイト値が変わらない文字(特に0x00~0x7f)http://www.ie.u-ryukyu.ac.jp/~e075739/3/Report/Report/Programming1/Programming_3.pdf調べてみたらこれってASCIIコードのことだったのですね。>暗黙的にiso-8859-1としてUTF16に自動変換されていても元のバイト値が表す文字がUTF-8と一緒なので、結果的に同じ文字に変換してくれます。(0)通報するANo.1ecogilisこんにちわ。間違えてないと思います。うろ覚えですが、サーブレットコンテナかフィルタが、リクエストパラメータの文字コードをiso-2022-jpであると仮定してUnicodeに変換するために文字化けがおきると記憶しています。Unicodeの文字列を元のバイナリに戻して、再度コンバートするのはそのためです。スマートではないんですが、結構一般的なやり方だと思います。15:29:35お礼ありがとうございます。回答いただきました内容の方、とても助かります。「基準なるべく基準」というものが、ちょっとわかっていなかった矢先なので、助かりました。>サーブレットコンテナかフィルタが、リクエストパラメータの文字コードをiso-2022-jpであると仮定してUnicodeに変換するために文字化けがおきると記憶しています。リクエストパラメーターについては、リクエスト時に「サーブレットコンテナ側、もしくはフィルタと呼ばれるもの」の規定?で「UTF-8」であったものを「iso-2022-jp」で再度文字を変換してしまうため、再度「UTF-8」のコードを指定する必要がある。今JAVAを勉強中でJSPファイルを作成しています。いつもお世話になっております。prototype.jsを用い、ajaxでservletにリクエス...プログラミング初心者です。プログラミング初心者です。jspの昇順、降順がうまくいきません。標記につき勉強中ですが素人です。何とか道筋を教えて下さい。JPS作成でコンパイルエラーがおこっています。考えたのですがどこがわるいのかわかりません。Javaの初心者です。してもわからないことがあります。Reserved.掲載情報の著作権は提供元企業等に帰属します。