はじめに

JMeterには長年Shift-JISの文字化けの問題があり、Proxyを使ってHTTP Requestを記録する際に、フォームから入力した値などが文字化けして記録されることがあります。

そのため、これまで独自にソースコードを修正したり、以下のような手段で回避されてきたと思います。

今回Shift-JISの問題をJMeterコミュニティに報告し、Shift-JISの文字化けの修正パッチがJMeter5.2としてリリースされます。

Shift-JISの文字化けの問題

次のように、テキストフォームに入力した文字列をサーバ内で処理して返すアプリケーションで、ブラウザでアクセスすると正しく文字列を返すことができるページが、JMeterのプロキシを介すと次のように文字化けすることがあります。

今回の修正では、HTTP Request記録時のデフォルトの文字コードを設定画面から指定できるようになりました。

「Recording's default encoding」の欄に、文字コードを設定するとデフォルトのエンコーディングを指定できます。

今回、デフォルトエンコーディングに Shift-JIS を指定すると、初回アクセスから文字化けをしなくなることが確認できます。

JMeterの HTTP Requestの文字コードの解釈は以下の通りです。

フォーム中の文字列は、ターゲットページの文字コードでエンコードしようとします。
ターゲットページの文字コードの判別は、JMeterのプロキシで一度レスポンスのファイルを読み込む必要があり、最初にアクセスした段階ではターゲットページの文字コードを取得することができません。
このためデフォルトの文字コード(V5.1まではUTF-8に固定）が使われ、Shift-JISの文字列が文字化けします。
JMeter Proxyがレスポンスとしてターゲットページを読み込むことで、page1の文字コードを判別することができます。
JMeter内部ではMap構造でターゲットページとエンコーディングの組み合わせ情報を保持します。
2回目以降、同ページにアクセスした場合は、正しく文字コードを取得でき、文字化けが発生しなくなります。

以上の理由から、初回アクセス時には文字コードが正しく設定されていても、文字化けを起こすことがあります。

今回の修正では、デフォルトのエンコーディングを指定することができるようになりましたが、ページごとに文字コードが異なる場合には対応できていません。

HTTP Proxyの仕組みを使う限り、文字コードの解釈には一度ファイルを読み込む必要があり、初回アクセス時に文字コードが判別できない問題は残っています。

あらかじめページごとに文字コードを指定する、または、記録時に動的に文字コードを設定する仕組みが必要かもしれません。