■ JSP.文字コード

この文字列がPOSTのボディ部分
( POST は Body に組み込まれる )
 



  日本語の場合は歴史的な経過から文字エンコーディングが複数存在する
  現在はMicrosoftが開発しWindows系で一般的に採用されている 
  Shift_JIS と呼ばれるもの

  POINT
    win32 環境では SJIS が一般的

    Linux系で一般的に採用されてい る
    EUC-JP の2つのエンコーディング双方が利用

    WebSphere はShift_JIS がデフォルト

WTE のサーブレット・エンジンもクライアントから
    URLエンコードで送られてきたパラメタ（バイト列）を

    Shift_JISの文字コード列だと見なしてこれをJavaのUnicodeに変換する

    WTE の環境では
    クライアントがEUC-JPで要求パケットを送ってくると問題


    WebSphere のアプリケーション・サーバでは設定ファイルの
    デフォルトの
    クライアント・エンコーディングを変更してこれに対応することになる

    これ以外にもPOST要求でHTTP要求のボディ部分に
    クライアントからのパラメタを書き込ませ

    これをバイトごとに読み出してEUC-JPとしてUnicodeに変換する手段もあるが一般的ではない
     WTEの環境ではクライアントから必ず
      Shift_JISでエンコードされた要求が到来するようにすることが推奨される

      サーバに情報を送信するためのフォームを含む HTML ドキュメントが表示され
      ユーザがその画面の送信ボタンをクリックして必要な情報をサーバに送信する際


  POINT
     IE, Netscapeのブラウザは
     HTML文書の文字コードを使ってバイト列を作成し、URLエンコードする


  クライアントに渡すフォームを含む
  HTMLドキュメントには以下の要素を含めることが必要

  これは SJIS でかかれてまよ ! と宣言する
  そして SJIS として URLEncode される
  < META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=Shift_JIS" >


  更にサーブレットからそのような画面をクライアントに返すときは
  エンジンに変換する文字エンコーディングを明示的に指示するだけでなく
  クライアントに
  HTTP 応答パケットのヘッダ行で使用文字エンコーディングをはっきり通知すべき

  response.setContentType("text/html; charset=Shift_JIS");  // 応答ヘッダContent-Type行追加



  Websphere のエンジンはShift_JISでエンコードされた要求パラメタは正しくUnicodeに変換してくれている

  Tomcat のエンジンはそれほど親切ではない

  このサーブレットは
  Tomcat のコンテナで走らせると漢字は正しく表示されない

  
  変換する前の文字コードは ISO8859_1(Latin-1) であると仮定して
  8859_1 から Unicode への変換テーブルを用いて
  String 型 のオブジェクトにしてしまう

  ここが Java の Default の操作


  POINT
    JAVA は URL を decode するときに "8859-1" として仮定していること -> それを UNICODE に変換する

  Byte --> 8859_1 --> request.getParameter( "xxx" )  
  --->   getBytes( "8859-1" ); ---> 指定した文字コードに変換しろ  となる

      ( Java の勝手な解釈 )                         もう一度 バイトコードをくれ getBytes( "8859-1" ) これをもとに  

Shift_JIS や EUC-JP の文字列が URLエンコード されてくると
対応した 正しい Unicode の文字列が得られない

 
String correctName = new String(name.getBytes("8859_1"), "Shift_JIS");






// 指定文字コードに対応した Byte 列をかえす
getBytes(String charsetName) 
指定された文字セットを使用してこの String をバイトシーケンスに符号化し
結果を新規バイト配列に格納します



  // HttpRequestDumpの要求パラメタの出力部分を
  // Tomcat用に変更する

  out.println();

  out.println("要求パラメタ:");

  // すべての Parameter を列挙する
  Enumeration paramNames = request.getParameterNames();

  while ( paramNames.hasMoreElements() ) {

    String name = (String) paramNames.nextElement();

    String[] values = request.getParameterValues( name );

//  out.println("    " + name + ":");

//  Tomcatの場合は上の1行は以下の2行のように変更し
    日本語の文字化けに対応すること

    // TomcatはURLエンコードされているパラメタのコードが
    // 標準のISO8859_1(Latin-1)であると仮定し
    // それを単にStringに(つまりUnicodeで)格納して
    // 各サーブレットにわたす

    //  そのためパラメタ文字列を取得するときに 
    // ISO8859_1から自分が期待する

  WARNING 
    短いデータではJISAutoDetectは正しく機能しない

    String correctName = new String(name.getBytes("8859_1"), "Shift_JIS");

    out.println("    " + correctName + ":");

    for (int i = 0; i <  values.length; i++) {

        try{

//          out.println("      " + values[i]);

//  Tomcatの場合は上の1行も同様に以下の2行のように変更すること

            String correctValue = new String(values[i].getBytes("8859_1"), "Shift_JIS");

            out.println("      " + correctValue);

        }catch(Exception e){

            System.out.println("URL Decoding Error");

        }

    }

  }



// これは失敗する
8859_1 という文字セットは8ビット単位なので

Unicodeの1文字は確実に8859_1の1バイト

（null(%00)も含めた256文字）に1対1で対応しており問題が生じなかった

WTE の SJISコンバータは
変換できないバイトは無視してしまうので
そのような逆操作をしても元には戻らない