ASP.NETでGET処理の日本語扱いについて

hoge.htmlなどからformのGetで日本語をhoge1.aspxなどに送るとうまく取得できない？現象に見舞われます。

これはサーバーサイドの文字コードの扱いによりこの問題が発生します。基本的に.NETはutf-8がDefualtなのでhtmlから送るとutf-8扱いになってしまいます。しかし中身はWindowsからの場合、shift-jisなので変換時にコケて空白扱いとなります。

解決方法は以下の２つです。（ほかにもあったら教えてちょ）

１．hoge.htmlをhoge.aspxにする

２．web.configの「responseEncoding」でサーバーサイドの文字コードを設定しているので、ここを「shift-jis」に変えてあげる

こんな感じかな（＾ ＾）

ネタとしては古いが（苦笑）管理人の覚書としてIIS6のセッション変数機能がパワーアップされているので記述しておく。従来のWeb機能ではセッション内容を他に簡単に移動させておけなかったので、IISが止まるとセッション内容も一緒に死んじゃってましたが、別プロセス（別空間）に保存できるようになったのでIISの再起動をしても、なんと！セッション情報が消えないのである！！！エッヘン（笑）なおかつこの機能を使うと別のマシン上にセッション情報を置けるので負荷分散でWebサーバーを複数台動かす時にも役立ちます。ちなみにTomcatも最近この機能が出来るようになったみたい。管理人としてはこの機能をパワーアップしてセッション内容をXMLファイルとしても保存、読込みできるメソッドを追加してほしいと思う今日この頃です。ん？なんでファイルか？だって！それはSession変数の場合タイムアウトを気にしないといけないのに対してファイルは気にしないで情報を取っておけるメリットがあるのですね。SQLServerには保存できるらしい・・・

　通常、セッション情報はASP.NETアプリケーションを実行するワーカー・プロセス（IIS本体ではなく、実際にアプリケーションを処理するプロセス）内部に保存されているが、より高レベルなサービスを提供するために、ステートサーバと呼ばれる、プロセス外にセッション情報を保存する手段が提供されている。

　ステートサーバを利用するメリットは、信頼性の向上にある。ステートサーバはIISから独立したプロセスとして実行されるため、ワーカー・プロセスが誤動作したり、IISを再起動したりしても、ステートサーバに保存されたセッション情報が失われることはない。もちろん、その瞬間にアプリケーションが起動されていたセッションは正しいレスポンスを返すことはできないだろうが、ユーザーからのポストバックを待っていたセッションは、IISさえ正常に戻れば、そのまま何食わぬ顔で処理を継続できる。

　また、IISとステートサーバは、ネットワーク接続さえされていれば、同一マシン上に存在していなくても構わない。従って、Webファーム（クラスタ化されたWebサーバ群）に対して、独立したステートサーバを1台用意する構成を取れば、1台のWebサーバに障害が発生しても、残りのWebサーバがセッションを継続できる（ステートサーバがウイークポイントとなってしまうが）。

　パフォーマンスでは通常のインプロセス・モードに分があるが、信頼性を優先させるならば、ステートサーバ・モードの利用を検討するとよいだろう。

　ステートサーバ・モードを利用するにあたって必要な作業は、ステートサーバを起動し、以下に示すweb.configファイルを用意することだけだ。アプリケーション・コードに修正は必要ない。web.configファイルでは、sessionState要素のmode属性に”StateServer”を、stateConnectionString属性に「tcpip=＜ステートサーバ・マシンのIPアドレス＞:42424」を設定すればよい。

<configuration>
   <system.web>
    <sessionState mode="StateServer"
      stateConnectionString="tcpip=127.0.0.1:42424" />
   </system.web>
</configuration>


　ステートサーバは「ASP.NET State Service」の名前でサービスとして登録されているので、サービス・マネージャで起動する。

　なおここでは割愛するが、セッションの情報はSQL Serverによりデータベースで管理することも可能だ。

詳しくはここ