はじめに
JMeterには長年Shift-JISの文字化けの問題があり、Proxyを使ってHTTP Requestを記録する際に、フォームから入力した値などが文字化けして記録されることがあります。
そのため、これまで独自にソースコードを修正したり、以下のような手段で回避されてきたと思います。
- JMeter の Request パラメータの文字化けをソースコードを修正せずに解消する方法
- JMeter の Proxy で Shift_JIS が化ける場合は delegate で文字コード変換リバースプロキシを構成する
今回Shift-JISの問題をJMeterコミュニティに報告し、Shift-JISの文字化けの修正パッチがJMeter5.2としてリリースされます。
Shift-JISの文字化けの問題
次のように、テキストフォームに入力した文字列をサーバ内で処理して返すアプリケーションで、ブラウザでアクセスすると正しく文字列を返すことができるページが、JMeterのプロキシを介すと次のように文字化けすることがあります。
修正内容
今回の修正では、HTTP Request記録時のデフォルトの文字コードを設定画面から指定できるようになりました。
「Recording's default encoding」の欄に、文字コードを設定するとデフォルトのエンコーディングを指定できます。
今回、デフォルトエンコーディングに Shift-JIS を指定すると、初回アクセスから文字化けをしなくなることが確認できます。
JMeterのHTTP Requestの文字コード解釈の仕様
JMeterの HTTP Requestの文字コードの解釈は以下の通りです。
- フォーム中の文字列は、ターゲットページの文字コードでエンコードしようとします。
- ターゲットページの文字コードの判別は、JMeterのプロキシで一度レスポンスのファイルを読み込む必要があり、最初にアクセスした段階ではターゲットページの文字コードを取得することができません。
- このためデフォルトの文字コード(V5.1まではUTF-8に固定)が使われ、Shift-JISの文字列が文字化けします。
- JMeter Proxyがレスポンスとしてターゲットページを読み込むことで、page1の文字コードを判別することができます。
JMeter内部ではMap構造でターゲットページとエンコーディングの組み合わせ情報を保持します。 - 2回目以降、同ページにアクセスした場合は、正しく文字コードを取得でき、文字化けが発生しなくなります。
以上の理由から、初回アクセス時には文字コードが正しく設定されていても、文字化けを起こすことがあります。
残課題
今回の修正では、デフォルトのエンコーディングを指定することができるようになりましたが、ページごとに文字コードが異なる場合には対応できていません。
HTTP Proxyの仕組みを使う限り、文字コードの解釈には一度ファイルを読み込む必要があり、初回アクセス時に文字コードが判別できない問題は残っています。
あらかじめページごとに文字コードを指定する、または、記録時に動的に文字コードを設定する仕組みが必要かもしれません。