0

サポートを支援している Web アプリの設計上の欠陥を回避する最善の方法を見つけようとしています。サービスの一部は、パラメーター (「myparam」) を .jsp ページに渡します。次に、パス パラメーターとして myparam を含む REST サービスを呼び出します。設計上の欠陥は、myparam が自由なテキストである可能性があるため、フォーム パラメーターとして渡す必要があることです。ただし、.jsp の最後には他の関係者が関与しているため、実装を変更することはできません。

私の解決策は、16 進エンコーディングを使用して myparam をエンコードすることでした (REST の org.restlet 実装がパス パラメータで見たくない "%" などになるため、url エンコーディングだけでは機能しません)。Apache コーデック ライブラリを使用すると、次のようなものがあります。

オプション 1 (16 進数のみ):

String decodedParam = new String(Hex.decodeHex(myparam.toCharArray()));

これは私たちの目的のために機能します。私が本当にやりたかったのは、すべての可能性をカバーできるように、URL と 16 進数のエンコードを組み合わせることでした。

オプション 2 (16 進数 + URL デコード):

パラメータの準備:

String workText = URLEncoder.encode(inText, encoding); // a
char[] encodedBytes = Hex.encodeHex(workText.getBytes()); // b
String myparam = new String(encodedBytes);

デコード (REST):

String decodedParam = new String(Hex.decodeHex(myparam.toCharArray())); // c
String doubleDecodedParam = URLDecoder.decode(decodedParam, "UTF-8"); // d

2 つの質問があります。

  1. 2番目のオプションが機能しないのはなぜですか? (d で文字列を URL デコードしようとするたびに) java.lang.IllegalArgumentException が発生します)。http://ostermiller.org/calc/encode.htmlで、パラメータ値の二重エンコードとデコードを問題なくテストしました。

  2. RESTでパスパラメータをエンコードするより良い方法はありますか?

4

1 に答える 1

1

文字セットに関する上記のコードには、私にはまったく正しくないように見えるものがたくさんあります。エンコーディングのステップでは、Hex クラスが行うこと (フレームワークはどのフレームワークですか?) は、JVM が実行されているエンコーディングで文字列として解釈できるバイトを返していると想定していますHex.encodeHex()。それ。

それから反対側があります。まず、UTF-8 を使用して 16 進文字列をデコードしています。new String()Hex.decodeHex() からの char 配列が JVM が現在実行されているエンコーディングにあると想定しているa の結果を渡しているため、JVM が UTF-8 で実行されていると暗黙のうちに想定しました。そのようにデコードする場合は、UTF-8 のみにしてください。また、その URL エンコーディング パスのポイントもわかりません。完全に冗長なようです。

これはどれも本当に核心的な問題ではないと思います。中間 JSP で正確に何が起こっているかという別の問題があります。取得したものをデコードして再エンコードする可能性があります。それは透過的であるべきですが、このデータでどのレベルを取っているのかわかりません. パラメータとしてデコードされる前にそれを見ると、間違った解釈が生じる可能性があります。

于 2009-09-28T10:03:29.970 に答える